Feature Spec Delivery Pipeline
Convert an idea into a buildable, reviewable plan before implementation.
When To Use
Use this before multi-file implementation, cross-layer changes, migrations, or user-flow changes.
Do not use this for a read-only health snapshot; use project-status-dashboard. Do not use it for a narrow contract mismatch review; use cross-layer-contract-audit.
Workflow
- Clarify the request:
- Goal.
- In-scope and out-of-scope behavior.
- Product decisions that need user approval.
- Map existing contracts:
- Relevant UI, API, database, jobs, integrations, tests, and docs.
- Identify risk:
- Auth, payments, sessions, migrations, data loss, compatibility, and user-facing workflow changes.
- Write the spec:
- Problem.
- Current behavior.
- Proposed behavior.
- Affected files/components.
- Contract changes.
- Implementation phases.
- Acceptance criteria.
- Verification plan.
- Rollout and rollback notes when relevant.
- Ask for approval before implementation when behavior, layout, copy, or data contracts are not settled.
For sample prompts and spec shape, see references/examples.md.
For a reusable spec skeleton, see references/spec-template.md.
Input Signals
Use source evidence before proposing a plan: changed files, current behavior, failing tests, issue text, screenshots, logs, schemas, route handlers, migrations, and prior specs. If the request is vague, ask for the missing product decision only after mapping what the repo already proves.
Output
Use this structure:
- Summary
- Current Evidence
- Decisions Needed
- Proposed Contract
- Implementation Plan
- Acceptance Criteria
- Verification
- Risks and Rollback
Guardrails
- Do not invent requirements when evidence is ambiguous.
- Do not make product, UI, or layout decisions without approval.
- Do not edit implementation code unless the user explicitly asks you to proceed.
- Keep the plan narrow enough to review.
Avoid
- Do not turn the spec into a broad roadmap unless the user asked for one.
- Do not hide unresolved decisions inside acceptance criteria.
- Do not propose implementation phases that cannot be verified independently.
Final Checks
- The spec separates evidence from assumptions.
- Every decision that needs user approval is explicit.
- Acceptance criteria are testable.
- Verification covers the highest-risk changed contracts.
1---2name: feature-spec-delivery-pipeline3description: Turn a feature request or bug cluster into a source-backed spec, impact map, acceptance criteria, and delivery plan before coding.4---56# Feature Spec Delivery Pipeline78Convert an idea into a buildable, reviewable plan before implementation.910## When To Use1112Use this before multi-file implementation, cross-layer changes, migrations, or user-flow changes.1314Do not use this for a read-only health snapshot; use `project-status-dashboard`. Do not use it for a narrow contract mismatch review; use `cross-layer-contract-audit`.1516## Workflow17181. Clarify the request:19 - Goal.20 - In-scope and out-of-scope behavior.21 - Product decisions that need user approval.222. Map existing contracts:23 - Relevant UI, API, database, jobs, integrations, tests, and docs.243. Identify risk:25 - Auth, payments, sessions, migrations, data loss, compatibility, and user-facing workflow changes.264. Write the spec:27 - Problem.28 - Current behavior.29 - Proposed behavior.30 - Affected files/components.31 - Contract changes.32 - Implementation phases.33 - Acceptance criteria.34 - Verification plan.35 - Rollout and rollback notes when relevant.365. Ask for approval before implementation when behavior, layout, copy, or data contracts are not settled.3738For sample prompts and spec shape, see `references/examples.md`.39For a reusable spec skeleton, see `references/spec-template.md`.4041## Input Signals4243Use source evidence before proposing a plan: changed files, current behavior, failing tests, issue text, screenshots, logs, schemas, route handlers, migrations, and prior specs. If the request is vague, ask for the missing product decision only after mapping what the repo already proves.4445## Output4647Use this structure:4849- **Summary**50- **Current Evidence**51- **Decisions Needed**52- **Proposed Contract**53- **Implementation Plan**54- **Acceptance Criteria**55- **Verification**56- **Risks and Rollback**5758## Guardrails5960- Do not invent requirements when evidence is ambiguous.61- Do not make product, UI, or layout decisions without approval.62- Do not edit implementation code unless the user explicitly asks you to proceed.63- Keep the plan narrow enough to review.6465## Avoid6667- Do not turn the spec into a broad roadmap unless the user asked for one.68- Do not hide unresolved decisions inside acceptance criteria.69- Do not propose implementation phases that cannot be verified independently.7071## Final Checks7273- The spec separates evidence from assumptions.74- Every decision that needs user approval is explicit.75- Acceptance criteria are testable.76- Verification covers the highest-risk changed contracts.
mo-hawary