Full Stack Feature

Full-Stack Feature Orchestration (Meta-Skill)

Coordinate the entire lifecycle of a feature — from understanding who it's for, through design, implementation, testing, and documentation. This meta-skill routes to the right skill, command, or agent at each stage and enforces stage gates so nothing ships half-baked.

Installation

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install full-stack-feature

---

When to Use

• Building a new feature end-to-end — you need the full pipeline from research to production
• Frontend + backend work together — the feature spans UI, API, and data layers
• User research should inform implementation — you want personas and specs before writing code
• Coordinating multiple skills — you're unsure which skill or command to invoke at each step
• Onboarding a new feature area — you need a structured approach, not ad hoc implementation
• Teaching a junior developer — walk through the complete feature development process

---

Orchestration Flow

Every feature moves through eight stages. Small features skip stages (see Complexity Assessment below); large features complete all of them.

 1. Persona Research
        ↓
 2. Feature Specification
        ↓
 3. UX/UI Design
        ↓
 4. API Design
        ↓
 5. Frontend Implementation
        ↓
 6. Backend Implementation
        ↓
 7. Testing
        ↓
 8. Documentation

---

Stage Details

Stage 1 — Persona Research

Understand who the feature is for before designing anything. Define the target user, their goals, pain points, and the journey this feature supports.

Invoke: /create-persona command → ai/commands/docs/create-persona.md Skill: persona-docs → ai/skills/writing/persona-docs/SKILL.md

Output: Persona document describing the target user, their context, and success criteria for this feature.

Stage 2 — Feature Specification

Translate persona insights into a concrete feature spec — scope, acceptance criteria, edge cases, and technical constraints.

Invoke: feature-specification skill → ai/skills/meta/feature-specification/SKILL.md

Output: Feature spec with user stories, acceptance criteria, out-of-scope items, and technical notes.

Stage 3 — UX/UI Design

Design the interface informed by the persona and spec. Choose the right visual style, layout, and interaction patterns.

Output: Component hierarchy, layout decisions, style selections, and responsive behavior plan.

Stage 4 — API Design

Define the contract between frontend and backend. Design endpoints, request/response shapes, error codes, and authentication requirements.

Command: /create-api-route → ai/commands/development/create-api-route.md

Output: API contract (OpenAPI spec or typed route definitions) with validation rules and error handling.

Stage 5 — Frontend Implementation

Build the UI components, pages, and client-side logic. Use the appropriate framework skill for the project's stack.

Command: /create-component → ai/commands/development/create-component.md

Output: Working UI components wired to the API contract, with loading/error states and responsive layout.

Stage 6 — Backend Implementation

Build the API routes, business logic, data access layer, and background jobs.

Command: /new-feature → ai/commands/development/new-feature.md

Output: Implemented API routes, data models, migrations, and business logic passing unit tests.

Stage 7 — Testing

Validate the feature across unit, integration, and end-to-end layers. Verify acceptance criteria from Stage 2.

Command: /test-feature → ai/commands/development/test-feature.md

Output: Passing test suite covering happy paths, edge cases, and error scenarios from the spec.

Stage 8 — Documentation

Generate user-facing docs, API references, and internal technical documentation.

Command: /generate-docs → ai/commands/documentation/generate-docs.md

Output: Updated README, API docs, component storybook entries, and changelog.

---

Skill Routing Table

---

Stage Gate Checks

Each stage must pass its gate before proceeding. Gates prevent wasted work by catching gaps early.

---

Vertical Slice Strategy

Start with the thinnest possible end-to-end slice, then widen.

Phase 1 — Thin Slice Build one happy path through all layers: a single user action from UI click to database write and back. This proves the architecture works and gives stakeholders something to demo.

Example: "User can create a new project"
  UI:      One form with a name field and submit button
  API:     POST /api/projects { name: string }
  DB:      INSERT INTO projects (name) VALUES ($1)
  Test:    E2E test: fill form → submit → see project in list

Phase 2 — Widen Add validation, error handling, edge cases, and secondary flows. Each addition follows the same vertical path — never build an entire layer in isolation.

Phase 3 — Polish Loading states, optimistic updates, animations, accessibility, performance optimization, and comprehensive error messages.

---

Complexity Assessment

Not every feature needs all eight stages. Use this table to determine which stages to include.

How to Assess Complexity

1. Count the layers touched — UI only (trivial), UI + API (small), UI + API + DB (medium+)
2. Count the user flows — one path (small), 2-3 paths (medium), many paths with branching (large)
3. Check for unknowns — known patterns (smaller), new integrations or unfamiliar tech (bump up one size)
4. Consider blast radius — isolated change (smaller), cross-cutting concern (bump up one size)

---

Coordination Patterns

Frontend and Backend in Parallel

Once the API contract is locked (Stage 4 gate), frontend and backend can proceed simultaneously:

• Frontend uses mock data matching the API contract types
• Backend implements against the same contract with unit tests
• Integration happens when both sides are ready — contract guarantees compatibility

Handoff Points

Use the /handoff-and-resume command when:

• Switching between frontend and backend work
• Pausing mid-feature and resuming later
• Passing work to another developer or agent

Progress Tracking

Use the /progress command to check which stage you're in and what remains.

---

NEVER Do

1. NEVER skip persona research for user-facing features — building without understanding the user leads to features nobody wants
2. NEVER start coding before the API contract is defined — frontend and backend will diverge, causing costly rework at integration
3. NEVER build an entire layer before connecting it end-to-end — always use vertical slices to prove the architecture first
4. NEVER skip stage gates to move faster — gates exist to catch problems when they're cheap to fix, not after they've compounded
5. NEVER treat testing as a separate phase you can cut — tests are part of implementation, not an afterthought bolted on at the end
6. NEVER ship without documentation — undocumented features become maintenance burdens that slow down every future change