// 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.
Optimize slow React Router loaders by eliminating redundant DB queries, creating slim query variants, and parallelizing independent fetches. Use proactively when writing or reviewing loader code that calls DBFunctionsService, or when triaging a slow page load.
Survey the codebase, pick ONE high-leverage deepening opportunity (filtering out anything already proposed), and publish it as a PRD-shaped GitHub issue via /to-prd-project. Designed to run unattended in the daily architecture-review workflow.
Break a PRD into native GitHub sub-issues attached to the parent PRD. Project-local variant of /to-issues, adapted for this repo's PRD-as-parent + native sub-issues + agent:implement multi-session workflow. Argument is the parent PRD issue number.
Generate or update documentation for the AI Hero API by reading the source code at ~/repos/ai/course-builder. Use when user wants to document, update docs for, or understand the AI Hero API endpoints.
Install @effect/* packages safely. Use whenever adding a new Effect ecosystem dependency.
End-to-end implementation workflow. Use when user wants to implement a feature, fix a bug, or make changes and have everything validated and committed.
| 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.
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.
The PRD will be read by:
/to-issues-project when breaking it into sub-issues.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.
The problem the user is facing, from the user's perspective.
The solution to the problem, from the user's perspective.
A LONG, numbered list of user stories. Each in the format:
This list should cover all aspects of the feature.
A list of implementation decisions, including:
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.
Things explicitly excluded from this PRD. Be specific — "we are not building X" rather than "X is out of scope."
Anything else worth recording: open questions, known risks, deferred decisions.
/to-issues-project <issue-number> to break it into sub-issues, then add agent:implement to start work."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.