This skill uses the current conversation context and codebase understanding to generate a spec (you may refer to this type of document as PRD). Do NOT interview users, only synthesize what you already know.
Issue tracker and triage label vocabulary should have been provided to you; if not, run
/setup-matt-pocock-skills
.
Process
-
If you haven't explored the repo yet, explore it first to understand the current state of the codebase. Always use the project's domain glossary vocabulary in the spec and comply with relevant ADRs.
-
Draft the seams you plan to test this feature on. Prioritize using existing seams instead of adding new ones. Use the highest-level seams possible. If new seams are indeed needed, propose them at the highest level possible.
The fewer seams the better, ideally one. Confirm with the user whether these seams meet expectations.
- Write the spec using the template below and publish it to the project issue tracker. Apply the triage label; no additional triage is required.
<spec-template>
Problem Statement
The problem the user is facing, described from the user's perspective.
Solution
The solution to the problem, described from the user's perspective.
User Stories
A long numbered list of user stories. Each user story follows the format:
- As an <actor>, I want a <feature>, so that <benefit>
<user-story-example>
1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
</user-story-example>
This list of user stories should be very comprehensive, covering all aspects of the feature.
Implementation Decisions
A list of made implementation decisions. It can include:
- Modules to build/modify
- Module interfaces to modify
- Technical clarifications from developers
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do not include specific file paths or code snippets. They may become outdated quickly.
Exception: If a snippet generated by a prototype encodes a decision more precisely than prose (state machine, reducer, schema, type shape), it can be inline in the relevant decision with a brief note stating it comes from a prototype. Only keep the decision-dense parts, do not include a complete working demo.
Testing Decisions
A list of made testing decisions. Includes:
- Description of what constitutes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for testing (i.e., similar types of tests in the codebase)
Out of Scope
Description of items outside the scope of this spec.
Further Notes
Other notes about the feature.
</spec-template>