Menu
Turn the current conversation context into a PRD and publish it to the project issue tracker when repository publishing rules are clear.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Turn a plan, spec, or PRD into one or more independently-grabbable issues, and publish them when repository publishing rules are clear.
Triage issues through the repository's Issue Tracker Contract Orbit state machine. Use when the user wants to create, inspect, classify, move, or prepare issues for implementation or review.
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
Review current worktree changes, fix blockers, record non-blocking technical debt, and create a git commit. Use when asked to review and commit, prepare a commit, finalize local changes, or run a pre-commit review.
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
| name | to-prd |
| description | Turn the current conversation context into a PRD and publish it to the project issue tracker when repository publishing rules are clear. |
This is the to-prd workflow. Before running it, read the repository's issue discovery rules, for example docs/issue-discovery-orbit/discovery-rules.md when present.
This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user - just synthesize what you already know.
If repository publishing rules are clear, publish the PRD to the issue tracker. If they are missing or conflicting, output a PRD candidate instead and list what must be confirmed before publishing.
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
A deep module is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
If child implementation issues are already known, include them in the PRD issue body under ## Blocked by, record the intended resume state, and use the repository's blocked state instead of the entry state while those children remain unresolved. Do not publish a PRD with both the blocked state and the entry state. If child issues will be published later, keep the section with the placeholder text and treat updating it as part of the issue-slicing handoff.
If publishing rules are missing or conflicting, do not publish. Present the PRD as a candidate and list the missing or conflicting rules.
The problem that 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 user story should be in the format of:
This list of user stories should be extremely extensive and cover all aspects of the feature.
A list of implementation decisions that were made. This can include:
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
A list of testing decisions that were made. Include:
A description of the things that are out of scope for this PRD.
Any further notes about the feature.
References to child issues that must complete before the PRD can advance, if any. If child issues have not been published yet, write "None - child issues not published yet". When blockers are listed, also record the intended resume state.
