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

CODEBLOCK0

---

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.

CODEBLOCK1

---

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 → INLINECODE3

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 → INLINECODE5

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 → INLINECODE7

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 → INLINECODE9

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 → INLINECODE11

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 → INLINECODE13

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 → INLINECODE15

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

---

Skill Routing Table

Stage	Primary Skill	Command	Agent
1. Persona Research	INLINECODE16	INLINECODE17	—
2. Feature Spec

feature-specification | — | — |
| 3. UX/UI Design | UI/UX skill | — | — |
| 4. API Design | api-design-principles | /create-api-route | ai/agents/api/ |
| 5. Frontend | Framework skill (Next.js, React, etc.) | /create-component | — |
| 6. Backend | api-development, database-migration-patterns | /new-feature | ai/agents/migration/ |
| 7. Testing | testing-workflow, e2e-testing-patterns | /test-feature | ai/agents/testing/ |
| 8. Documentation | — | /generate-docs | — |

---

Stage Gate Checks

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

Gate	Required Before	Criteria	Blocking?
Persona defined	Stage 2	Target user identified with goals and pain points	Yes
Spec approved

Stage 3 | Acceptance criteria written, scope defined, edge cases listed | Yes |
| Design reviewed | Stage 4 | Component hierarchy defined, responsive plan in place | Yes |
| API contract locked | Stage 5 + 6 | Endpoints defined, request/response types agreed, error codes set | Yes |
| Frontend renders | Stage 6 | UI components display with mock data, loading/error states work | No (parallel OK) |
| Backend passes tests | Stage 7 | All API routes return expected responses, validations enforced | Yes |
| Tests pass | Stage 8 | Unit + integration + E2E tests green, acceptance criteria verified | Yes |
| Docs complete | Deploy | API documented, user-facing docs updated, changelog entry added | Yes |

---

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.

CODEBLOCK2

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.

Feature Size	Examples	Stages to Include	Estimated Time
Trivial	Rename a label, fix copy, adjust spacing	5 only	< 1 hour
Small

Add a filter, new form field, simple toggle | 4 → 5 → 6 → 7 | 2-4 hours |
| Medium | New CRUD entity, dashboard widget, search feature | 2 → 3 → 4 → 5 → 6 → 7 | 1-3 days |
| Large | New user-facing feature area, multi-page flow | All 8 stages | 1-2 weeks |
| Epic | New product vertical, major redesign, platform migration | All 8 + ADR + phased rollout | 2-6 weeks |

How to Assess Complexity

1. 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. 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