fullstack-development

Files (10)

• SKILL.md
• api-design-patterns.md · references/
• caching-strategy.md · references/
• component-architecture.md · references/
• dashboard-ux-patterns.md · references/
• database-migration-guide.md · references/
• error-handling-patterns.md · references/
• multi-tenancy-patterns.md · references/
• responsive-design-checklist.md · references/
• state-management-guide.md · references/

SKILL.md (first lines)

# Fullstack Development

You handle both frontend and backend development tasks. This is a merged skill covering component architecture, state management, API design, database patterns, migrations, error handling, caching, and responsive design.

## When this skill triggers

This skill activates when a developer asks about building UI components, setting up API routes, designing database schemas, managing state, handling forms, implementing caching, or any other frontend/backend development topic.

## Read project context first

Before responding, check `.claude/shipwise-state.json` for:
- `project.stack` — framework, database, ORM, hosting
- `experience_level` — beginner, intermediate, senior
- `expected_scale` — user count bracket

Tailor code examples to the detected stack (e.g., Prisma if ORM is prisma, Next.js App Router `route.ts` if framework is nextjs). If no state file exists, ask what framework and database they're using before generating schema or API code.

### Persist stack context discovered in conversation

If the developer mentions their stack in conversation (e.g., "I'm using Next.js with Prisma and Postgres") and `.claude/shipwise-state.json` exists but `project.stack` fields are null, update the state file with the discovered values before responding. Use the same format as skill 04's state update procedure. This ensures downstream skills benefit from context gathered in any skill.

---

## Frontend Coverage

### Project structure — feature-based

Organize code by feature, not by file type. Each feature is a self-contained folder.

```
src/
  features/
    auth/
      components/
      hooks/
      api/
      utils/
      types.ts
      index.ts
    dashboard/
      components/
      hooks/
      api/
      utils/
      types.ts
      index.ts
  shared/
    components/    # Reusable atoms/molecules
    hooks/
    utils/
    types/
  app/             # App shell, routing, providers
  styles/          # Global styles, tokens
```

<!-- beginner -->
**Why feature-based?** When all components live in one folder and all hooks in another, a single feature's code is scattered across the entire tree. Feature folders keep related code together so you can find everything about "auth" in one place.

<!-- intermediate -->
Feature folders reduce cross-cutting imports. Each feature exposes a public API via `index.ts` — other features import from the barrel, never reach into internals.

<!-- senior -->
Feature-based. Barrel exports. No cross-feature internal imports. Enforce with ESLint `boundaries` plugin.

### Component architecture — atomic design

Reference: `references/component-architecture.md`

Use atomic design to categorize components:

| Level | Examples | Rules |
|-------|----------|-------|
| **Atoms** | Button, Input, Badge, Avatar | No business logic. Accept props + render. |
| **Molecules** | SearchBar, FormField, UserCard | Compose 2-3 atoms. Minimal local state. |
| **Organisms** | Header, InvoiceTable, Sidebar | Compose molecules. May connect to state. |
| **Templates** | DashboardLayout, AuthLayout | Structural only. No data fetching. |
| **Pages** | DashboardPage, SettingsPage | Data fetching + orchestration. Wire organisms to data. |

Use compound components for complex UI that shares implicit state (Tabs, Accordion, Select).

### Design token implementation

Define tokens in a central file. Consume via CSS custom properties or your framework's theme system.

```ts
// tokens.ts
export const tokens = {
  color: {
    primary: { 50: '#eff6ff', 500: '#3b82f6', 900: '#1e3a8a' },
    neutral: { 50: '#f9fafb', 500: '#6b7280', 900: '#111827' },
    error: { 500: '#ef4444' },
    success: { 500: '#22c55e' },
  },
  spacing: { xs: '0.25rem', sm: '0.5rem', md: '1rem', lg: '1.5rem', xl: '2rem' },
  radius: { sm: '0.25rem', md: '0.5rem', lg: '1rem', full: '9999px' },
  font: {
    sans: 'Inter, system-ui, sans-serif',
    mono: 'JetBrains Mono, monospace',
  },
} as const;
```

### State management decision tree

Reference: `references/state-management-guide.md`

Pick the simplest tool that solves the problem:

```
Is the state used by only one component?
  → YES: useState / useReducer
  → NO: Is it shared by a parent and 1-2 children?
    → YES: Lift state up + props
    → NO: Is it server/async data?
      → YES: TanStack Query (React Query)
      → NO: Is it used across 3-5 components in one subtree?
        → YES: React Context
        → NO: Is it global app state?
          → YES, simple: Zustand

From harmansidhudev/shipwise, MIT.

More from harmansidhudev/shipwise