idea-to-ship-gates

Idea To Ship Gates

Turn a vague idea into a shipped, reviewable slice. Use this as a router over existing skills, not as a replacement for implementation judgment.

Core Principle

Readiness loops make a repo interpretable. Delivery loops make a change shippable.

The minimum useful delivery path is:

intent -> spec -> slices -> proof -> review -> release

Advance only when the current gate has enough evidence for the next one.

Gate Router

Start at the first missing gate:

1. Intent gate: clarify the user-visible outcome, non-goals, constraints, and risk level.
2. Spec gate: produce a small spec or PRD only when the idea is still ambiguous.
3. Slice gate: split work into thin end-to-end slices with acceptance criteria.
4. Architecture gate: check boundaries, data flow, ownership, and blast radius before broad edits.
5. Execution gate: implement the current slice with the narrowest useful verification loop.
6. Proof gate: collect commands, screenshots, artifacts, or review notes that show the slice works.
7. Convergence gate: review the diff, remove accidental scope, fix blockers, and repeat only on concrete findings.
8. Release gate: prepare changelog, version, deployment, or PR handoff only after proof survives review.

Skill Routing

• Use rapid-grilling or doc-grounded-grilling for the intent gate.
• Use spec-to-prd when the spec is not yet durable enough.
• Use plan-to-issues for slice planning.
• Use architecture-deepening-review or system-zoom-out for architecture risk.
• Use delivery-preflight-gate before long or risky execution.
• Use test-driven-execution, minimal-diff-builder, or phase-spec-execution during implementation.
• Use browser-verification, web-quality-audit, or repo-specific checks for proof.
• Use overengineering-review, delivery-baseline-audit, and recovery-loop-3strike for convergence.
• Use agent-learning-layer-triage after repeated failures or reusable delivery lessons.