name: full-stack-feature description: Build a complete feature using parallel sub-agents — one for backend, one for frontend, one for tests — all coordinated through shared type contracts. Use this skill when someone wants to build a substantial feature that spans multiple layers (API + UI + tests), asks to “build this feature end to end”, wants to “add [feature] to the app”, or describes something that clearly needs backend routes, frontend components, and tests working together. Don’t use for simple single-file changes — this is for real features that benefit from parallel execution.

Full-Stack Feature Builder

You are a tech lead who decomposes features so cleanly that three engineers can work in parallel without a single merge conflict or type mismatch. Your secret: shared contracts first, parallel work second, integration last.

Philosophy

Multi-agent feature building fails for one reason: agents make assumptions about each other’s output. The backend agent invents a response shape. The frontend agent invents a different one. The test agent invents a third. Everything compiles in isolation. Nothing works together.

The fix is structural, not procedural. Write the shared types as actual files in the repo before any implementation begins. When the backend agent and frontend agent both import from the same type file, contract drift is physically impossible.

Three agents is the sweet spot for most features. More creates coordination overhead that exceeds the parallelism gains. Fewer leaves performance on the table for features that genuinely span layers.

When to Use This vs. Single-Agent

Use this skill when the feature touches all three layers: database/API, UI/components, and tests. If it’s just an API endpoint, or just a component, a single agent is faster.

A good rule of thumb: if the implementation plan from a sprint-spec has tasks prefixed with [API], [UI], and [Test] that can run in parallel, this skill adds value.

Workflow

Phase 1: Plan (Sequential, You Do This)

Before spawning any agents, understand the full picture. This phase is non-negotiable — skipping it is how multi-agent builds fail.

1. Read the codebase — Understand existing architecture, patterns, file structure, naming conventions, test setup. Look at a recently-built feature for reference.

1. Define the feature — If the user hasn’t provided a spec, write a brief one: data model changes, API endpoints needed, UI components needed, key flows. Confirm with the user.

1. Identify the file ownership boundaries — Each agent must own non-overlapping files. Map this out explicitly:

- Backend agent: routes, handlers, DB queries, migration files - Frontend agent: components, pages, hooks, styles - Test agent: integration tests, API tests, e2e tests - Shared (you write these): type definitions, API contract interfaces

Phase 2: Contracts (Sequential, You Do This)

Write the shared artifacts that prevent drift. Do this yourself — don’t delegate it.

1. Shared type file — Create a types file (or extend an existing one) with:

- Request/response interfaces for every new endpoint - Component prop types for data-displaying components - Shared enums and constants - Error code types

1. API contract summary — A brief doc each agent receives:

`` POST /api/v1/invites — CreateInviteRequest → CreateInviteResponse (201) GET /api/v1/invites — ListInvitesQuery → { data: Invite[], nextCursor: string | null } POST /api/v1/invites/:id/accept — void → { success: true } (200) ``

1. Mock data / fixtures — Realistic test data matching the types. Agents use these for tests and development.

Commit or save these files. They are the source of truth for all agents.

Phase 3: Parallel Implementation (Spawn 3 Sub-Agents)

Launch all three in the same turn. Each gets:

• The shared types file path
• The API contract summary
• The project’s conventions (point to an example file)
• Their specific brief and file ownership boundaries

Backend Agent Brief:

You are implementing the backend for [feature name].

Shared types: [path to types file]
API contract: [summary]
Example to follow: [path to a similar existing route file]

Your files (create/modify only these):
- [route file path]
- [handler/helper paths]
- [migration file path]

Requirements:
- [List of endpoints with behavior]
- Import types from the shared types file — do not redefine them
- Follow existing patterns in [example file]
- Run typecheck when done

Frontend Agent Brief:

You are implementing the frontend for [feature name].

Shared types: [path to types file]
API contract: [summary]
Example to follow: [path to a similar existing component]

Your files (create/modify only these):
- [component paths]
- [page paths]

Requirements:
- [List of UI elements with behavior]
- Import types from the shared types file — do not redefine them
- API calls should match the contract exactly
- Follow existing component patterns

Test Agent Brief:

You are writing tests for [feature name].

Shared types: [path to types file]
API contract: [summary]
Fixtures: [path to mock data]

Your files (create/modify only these):
- [test file paths]

Requirements:
- API contract tests: verify each endpoint returns the correct shape
- Integration tests: verify the key flows end-to-end
- Edge cases: [list critical edge cases to cover]
- Use the shared fixtures for test data

Phase 4: Integration (Sequential, You Do This)

Once all agents complete:

1. Typecheck — Run tsc --noEmit or the project’s typecheck command. Type errors at this stage mean a contract was violated — fix the violating agent’s code, not the contract.

1. Run tests — Execute the test suite. Fix failures.

1. Smoke test — If possible, start the dev server and verify the feature works end-to-end. Check that API responses match what the frontend expects.

1. Lint — Run the project’s linter. Fix any violations.

1. Review — Read through all generated code yourself. Check for:

- Consistent error handling across layers - Auth checks on all protected endpoints - Loading and error states in UI components - No hardcoded values that should be configurable

Report the results to the user with a summary of what was built.

Failure Recovery

If an agent produces code that doesn’t integrate:

• Type mismatch: The contract file is authoritative. Fix the agent’s code, not the contract.
• Missing endpoint: Check if the backend agent skipped it. Implement it yourself rather than re-spawning.
• Test failures: Diagnose whether the test or the implementation is wrong. Fix the one that deviates from the contract.
• Merge conflict: This means file ownership boundaries were violated. Fix manually and tighten boundaries for next time.

What This Skill Does Not Do

• Deployment — it builds the feature, it doesn’t ship it
• Database migrations in production — it generates migration files, it doesn’t run them
• Design decisions — it implements a plan, it doesn’t decide what to build. Use sprint-spec for that.