Feature Shipper

Turn "I want to build a feature" into a fast execution chain.

Input (Pass Paths Only)

feature.md

Requirements description (acceptance criteria + non-goals)

repo_root

run_dir

Optional flags (recommended inside

feature.md

)

mode

:

plan-only

|

execute

(default:

execute

)

feature_slug

short slug for artifact naming (default: derived from title + timestamp)

quality_bar

:

demo-ready

|

functional-only

(default:

demo-ready

for user-facing UI features)

Output (Persisted)

evidence/features/-plan.md

(checklist plan: tasks + verification)

evidence/parallel/features//

(if implementation is split)

evidence/features/-summary.md

Process

Hooks doctor (required check; non-blocking): Run

tool-hooks-doctor

once at the start of the session to verify

skill-evolution

hooks are enabled. If missing, offer to install project-level hooks; continue either way.

Read

feature.md

, normalize into: acceptance criteria, boundaries, risks, rollback.

Prototype UI rule (default)

if this feature affects user-facing UI and

quality_bar

isn’t

functional-only

, propose 1 “demo moment” (animation/micro-interaction) and add it to acceptance criteria. Must respect

prefers-reduced-motion

.

Produce 2 options (A: minimal; B: cleaner but slower), default to A. If user cares about “demo feel”, offer A-demo-ready vs A-functional-only as explicit sub-options.

Split into PR-sized small steps (each independently runnable + rollback-able).

Write plan to

evidence/features/-plan.md

.

If

mode: plan-only

, stop here and ask for confirmation before implementing.

Implement (batch execution + checkpoints):

UI visual/layout/animation changes → First call

tool-design-style-selector

to load the project’s

design-system.md

, then strictly follow it. If

tool-ui-ux-pro-max

is installed, use it to ground motion/UX constraints (search “animation” + “accessibility”). For complex visual/animation/responsive design, delegate to

/gemini

frontend UI/UX senior design agent.

Business logic/data flow/integration → Implement directly.

Default batch rhythm

3 small tasks per batch → run verification → report and wait for feedback; stop immediately for help when blocked/verification fails.

After each batch (or before merge), recommend using

review-quality

for a conclusive review + verdict.

review-quality

is the single entry point and will auto-triage: if React/Next.js performance risk is detected, it will also run

review-react-best-practices

.

If the user explicitly wants

only

a React/Next.js perf audit, run

review-react-best-practices

directly.

Verification: can run, can build (and existing tests pass).

If verification fails (tests/build/runtime error): run

tool-systematic-debugging

before attempting more fixes.

Persist debugging artifacts to:

evidence/features/-debug.md

(repro steps, hypotheses, root cause, fix + re-verify)

Write

evidence/features/-summary.md

what was done, how verified, next steps. Wrap up: Do a skill-evolution Evolution checkpoint (3 questions); if user chooses "want to optimize", run skill-improver based on this run_dir to produce minimal patch suggestions Delivery Requirements No "big bang" refactoring Don't introduce new complexity (unless it significantly reduces future cost, and user confirms)