| name | to-prd-project |
| description | Turn the current conversation context into a PRD and publish it as a GitHub issue that is ready to receive sub-issues from /to-issues-project. Project-local variant of /to-prd, adapted for this repo's PRD-as-parent-issue + sub-issues + agent:implement workflow. |
This skill writes a PRD and publishes it as a GitHub issue in mattpocock/course-video-manager. It does not apply agent:implement — labeling happens after sub-issues have been created.
Do NOT interview the user — just synthesize what you already know from the conversation. If context is thin, ask the user to talk through the problem first; don't run the skill on an empty plate.
Process
-
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary (CONTEXT.md) and respect ADRs under docs/adr/ for areas you're touching.
-
Sketch the major modules you'd build or modify. Actively look for opportunities to extract deep modules that can be tested in isolation. A deep module encapsulates a lot of functionality behind a simple, testable interface that rarely changes.
Check with the user that these modules match their expectations and which they want tests written for.
-
Write the PRD using the template below and publish it via gh issue create. Use a heredoc for the body. Do not apply agent:implement — that's reserved for after sub-issues exist. Add no labels unless the user asks.
-
Output the issue URL so the user can pass it to /to-issues-project next.
PRD template
The PRD will be read by:
- Humans deciding whether the plan is sound.
/to-issues-project when breaking it into sub-issues.- The PRD-mode implement workflow at the start of each sub-issue run (the prompt pulls in the PRD body for context).
- The review workflow when checking "does the PR match the spec?"
So the PRD must be a spec, not a sketch — concrete enough that a sub-issue agent can implement against it without re-deriving decisions.
Problem Statement
The problem the user is facing, from the user's perspective.
Solution
The solution to the problem, from the user's perspective.
User Stories
A LONG, numbered list of user stories. Each in the format:
- As a <actor>, I want <feature>, so that <benefit>
This list should cover all aspects of the feature.
Implementation Decisions
A list of implementation decisions, including:
- The modules to build/modify
- The interfaces of those modules
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do not include specific file paths or code snippets. They go stale fast.
Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note that it came from a prototype. Trim to the decision-rich parts.
Testing Decisions
- What makes a good test in this codebase (only external behavior, not implementation details)
- Which modules will be tested
- Prior art (similar tests in the codebase)
Out of Scope
Things explicitly excluded from this PRD. Be specific — "we are not building X" rather than "X is out of scope."
Further Notes
Anything else worth recording: open questions, known risks, deferred decisions.
After publishing
- Tell the user: "PRD published at <URL>. Run
/to-issues-project <issue-number> to break it into sub-issues, then add agent:implement to start work."
- Do not add
agent:implement yourself. The PRD has no sub-issues yet, so labeling it now would either silently bounce (regular single-issue workflow would try to run it as a leaf and might do unexpected work) or land in the wrong place. The user labels once sub-issues are in place.
