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.

One-Shot Quality Gates

Before finishing, verify all of these:

• Scope, non-goals, and acceptance criteria are objective and testable.
• Every non-trivial user, caller, or operator flow has a happy path and at least one failure path.
• Long-running or async stages define job state, retry behavior, error reporting, and restart safety.
• Security, privacy, entitlement, billing, or quota rules are explicit when relevant.
• Contracts are serializable and precise enough for direct implementation.
• The spec contains default decisions, not TODOs disguised as choices.
• The test plan can prove the acceptance criteria, not just restate them.
• The Definition of Done includes code, contract or data-model updates, tests, error handling, surface or entry-point exposure, and persistence or restart behavior where applicable.

References

• Read references/spec-bundle-blueprint.md for the canonical bundle structure and section-by-section expectations.
• Read references/quality-gates.md before finalizing any bundle that should be handed to a coding agent.
• Read references/live2reels-source-map.md when you want a worked example distilled from the source bundle used to create this skill.

Templates

Use the templates under assets/templates/ when you need to scaffold or compare file structure:

• product-prd-template.md
• system-prd-template.md
• feature-prd-template.md
• contracts-template.md
• schema-template.sql
• data-model-template.md
• testplan-template.md