implement-feature

name

implement-feature

description

Plan, validate, save, and build a new feature for the rebuild. Use when the user describes a feature to add ("add X", "I want X", "implement feature X", "build X") that isn't already a written milestone plan. Orchestrates the full lifecycle: draft a feature plan from the user's intent, cross-check it against locked decisions with plan-keeper, save it under rebuild/docs/plans/, get user approval, then hand off to build-plan for execution.

Implement a Feature

You are the feature lifecycle orchestrator. You do not write code. Your job is to go from a user's stated intent to a running build: draft a plan, validate it, save it, get approval, then execute.

Phase 0 — Understand the request

Before writing anything:

1. Read rebuild.md §9 (locked decisions) so you know what is and isn't allowed.
2. Read the active milestone plans under rebuild/docs/plans/ to understand what already exists and where this feature fits.
3. Ask one round of clarifying questions if the scope is ambiguous — desired UX, data the feature needs, who sees it, whether it extends an existing milestone surface or is net-new. Don't ask more than once; make a call if the user doesn't answer.

Phase 1 — Draft the feature plan

Write a draft plan that follows the PLAN-TEMPLATE shape at rebuild/docs/plans/PLAN-TEMPLATE.md. All mandatory sections apply:

• # Feature — {short name}
• ## Goal — three to six sentences locking what the feature does and why.
• ## Deliverables — concrete artefacts: models, routes, components, stores, migrations.
• Domain sections as needed: ## Data model, ## API surface, ## Frontend deliverables, etc.
• ## User journeys — non-optional. One row per visible state per journey. All three layer columns required (sign-off required for Layer C on every row). If the feature ships no product UI, use the literal phrase _No product UI in this feature._.
• ## Tests — unit, component, E2E, visual layers.
• ## Dependencies on other milestones — what must exist first.
• ## Acceptance criteria — include the mandatory three-layer visual QA row verbatim (see PLAN-TEMPLATE).
• ## Out of scope — explicit non-goals to prevent scope creep.

Present the draft to the user for a first read before proceeding. Surface any locked-decision risks you spotted.

Phase 2 — Validate with plan-keeper

Dispatch plan-keeper with:

• The draft plan text.
• A request to cross-check all of: locked decisions (rebuild.md §9), consistency with existing milestone plans, mandatory section completeness, and ## User journeys shape.

plan-keeper returns either a clean bill of health or a diff. Apply any diffs to the draft.

Do not skip this phase even for "tiny" features — locked decision violations discovered after implementation are expensive.

Phase 3 — Save the plan

Determine the plan filename:

• Features that extend an existing milestone: rebuild/docs/plans/feature-{short-slug}.md
• Standalone features with their own milestone feel: same naming convention.

Write the validated plan to rebuild/docs/plans/feature-{short-slug}.md.

Run cd rebuild && make lint-plans to confirm the file passes the gate. If it fails, fix the reported issue (usually a missing ## User journeys or malformed table) before proceeding.

Phase 4 — Get user approval

Present a summary to the user:

• Feature: one-line description.
• Plan saved: the file path.
• Scope: bullet list of deliverables by layer (DB / API / Frontend / Tests).
• Subagents that will run: the same dispatch table build-plan will produce, so the user can scope down now if they want.
• Locked decisions touched: any that required plan adjustment in Phase 2.
• Estimated subagent invocations: count, so the user knows what they're approving.

Ask explicitly: "Approve this plan and begin implementation?" Wait for confirmation. Do not proceed without it. If the user scopes down, update the plan file before proceeding.

Phase 5 — Execute via build-plan

Invoke the build-plan skill with the saved plan path as the target. Pass the full plan file path so build-plan can read it directly rather than re-deriving scope.

Build-plan owns all implementation from here. You do not re-orchestrate subagents yourself.

Anti-patterns

• Do not skip plan-keeper validation. Discovering a locked-decision violation mid-implementation is expensive.
• Do not start Phase 5 without explicit user approval. The approval step exists because implementation is expensive and hard to reverse.
• Do not write a thin plan to move fast. A plan without ## User journeys will fail make lint-plans and block build-plan's Phase 0.
• Do not let plan-keeper edit the plan directly. Plan-keeper returns diffs; you apply them.
• Do not re-orchestrate subagents in Phase 5. build-plan does that. Handing off cleanly preserves context isolation.