Feature Shipper

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/<feature_slug>-plan.md

  (checklist plan: tasks + verification)

• evidence/parallel/features/<feature_slug>/

  (if implementation is split)

• evidence/features/<feature_slug>-summary.md

Process

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

   feature.md

   , normalize into: acceptance criteria, boundaries, risks, rollback.
3. 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

   .
4. 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.
5. Split into PR-sized small steps (each independently runnable + rollback-able).
6. Write plan to

   evidence/features/<feature_slug>-plan.md

   .
7. If

   mode: plan-only

   , stop here and ask for confirmation before implementing.
8. 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.
9. 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/<feature_slug>-debug.md

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

    evidence/features/<feature_slug>-summary.md

    : what was done, how verified, next steps.
11. 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)