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 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, ...