To Spec (ex To PRD, Claude Code skill)
Synthesises the current conversation into a spec published straight to your issue tracker. The command is now /to-spec (former name: /to-prd). The skill does NOT interview you (that's the job of /grill-me or /grill-with-docs upstream), it synthesises what Claude already knows. It explores the repository to reuse the domain vocabulary, identifies testing seams, preferring the ones that already exist, and asks you to confirm they match your expectations. Output: a spec using a strict template (Problem Statement, Solution, numbered User Stories, Implementation Decisions, Testing Decisions, Out of Scope, Further Notes) published to the tracker with the `ready-for-agent` label, no triage step.
Strengths
- No redundant interview: the skill consumes the conversational context already acquired (ideal after /grill-me)
- Testing seams set in the spec and confirmed with you, not discovered during implementation
- Numbered and exhaustive user stories by default, no rushed "as a user I want X"
- Mandatory 'Out of Scope' section, clarifies what is NOT in the spec before the ticket breakdown
Limitations
- Assumes the grilling phase has been done, poor output if context is thin
- Refuses file paths and code snippets in the spec ('they may end up being outdated very quickly'), can frustrate if you want a very technical spec
- Publishes directly to the issue tracker, no dry-run mode to review before push
Best for
- PM/PO who want a clean spec 30 minutes after the scoping session, without having to write it
- Tech leads handling the spec→implementation handoff who want to set the testing seams early
- Teams that write the spec before the code and want a unified format