implementation-prd

Implementation PRD

Write specs that another coding agent can execute without reopening discovery.

Default Output

Create or update a spec bundle with these files:

1. <slug>_prd.md
2. <slug>_contracts.md
3. one storage artifact:
   • <slug>_schema.sql for SQL-backed systems;
   • <slug>_data-model.md for frontend-only work, NoSQL systems, or features with no relational schema change.
4. <slug>_testplan.md

Do not omit state design. If there is no durable storage delta, use the data-model artifact and state explicitly where state lives and why no schema change is needed.

When starting from scratch, scaffold the bundle with:

bash "${CLAUDE_PLUGIN_ROOT}/scripts/init-spec-bundle.sh" <slug> <product|feature|system> [output_dir] [sql|data-model]

Working Rules

• Decide early whether the request is a net-new product, a service or platform subsystem, or a complex feature inside an existing system.
• Mirror the user's language for prose. Keep code, contract types, enum values, and filenames in English unless the repo already uses another convention.
• Make explicit assumptions instead of leaving hidden gaps.
• Choose one recommended default architecture or stack when that removes downstream ambiguity. Do not present option menus unless the user asked for trade-off analysis.
• Keep MVP and non-goals sharp. Downstream implementation should know what not to build.
• Make surfaces explicit. A surface can be a UI screen, route, API endpoint, CLI command, webhook, worker job, admin panel, SDK entry point, or automation hook.

Bundle Workflow

1. Normalize inputs: problem, persona or caller/operator, target action, constraints, monetization or entitlement, integrations, data sensitivity, and delivery surface.
2. Draft the PRD first. Lock scope, scenarios, functional requirements, architecture, business rules, acceptance criteria, epics, implementation order, default technical decisions, risks, and Definition of Done.
3. Derive contracts from the PRD. Cover domain types, service boundaries, API or IPC payloads, async job events, validation rules, and error envelopes.
4. Derive the storage or data model artifact. Add durable entities, invariants, lifecycle states, and migration notes, or explicitly state that no schema change is needed and how state is represented.
5. Derive the test plan from critical paths and failure modes. Cover fixtures, unit, integration, E2E, snapshots or golden tests when rendering or formatting matters, performance or smoke, negative cases, and exit criteria.
6. Cross-check the files so naming, state machines, IDs, limits, and enum values match exactly.