to-prd
Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
73
58%
Does it follow best practices?
Impact
98%
1.50xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.agents/skills/to-prd/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description adequately communicates the core purpose and includes an explicit 'Use when' trigger clause, which is good. However, it lacks specificity in the actions performed and misses important trigger term variations (e.g., 'product requirements document', 'spec'). The description would benefit from more concrete details about the output format and supported issue trackers.
Suggestions
Add trigger term variations such as 'product requirements document', 'spec', 'requirements doc', and specific tracker names like 'Jira', 'Linear', or 'GitHub Issues' to improve discoverability.
Expand the 'Use when' clause with more natural trigger phrases, e.g., 'Use when user asks to write a PRD, product spec, requirements document, or wants to turn a discussion into a trackable issue.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (PRD creation) and two actions (turn conversation into PRD, publish to issue tracker), but lacks detail on what the PRD contains or what 'publish' entails (e.g., which issue tracker, what format). | 2 / 3 |
Completeness | Clearly answers both 'what' (turn conversation into PRD and publish to issue tracker) and 'when' (when user wants to create a PRD from the current context), with an explicit 'Use when' clause. | 3 / 3 |
Trigger Term Quality | Includes 'PRD' and 'issue tracker' as relevant keywords, but misses common variations like 'product requirements document', 'spec', 'requirements', 'Jira', 'Linear', 'ticket', or 'product spec' that users might naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | The PRD + issue tracker combination is fairly specific, but 'current conversation context' is vague and could overlap with other skills that generate documents or tickets from conversations. The lack of specificity about which issue tracker adds some ambiguity. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
50%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill provides a reasonable workflow for generating PRDs from conversation context, with a useful template and a sensible 3-step process including user checkpoints. However, it lacks concrete tool invocations for publishing to the issue tracker, includes some unnecessary explanations (deep module definition), and misses validation steps after the publishing action. The inline PRD template is well-structured but could be extracted for better progressive disclosure.
Suggestions
Add concrete tool calls or commands for publishing to the issue tracker (e.g., specific API call, CLI command, or MCP tool invocation) to improve actionability.
Remove the deep module definition paragraph — Claude already understands this concept — and replace with a brief directive like 'Prefer deep modules with simple, testable interfaces.'
Add a validation step after publishing (e.g., 'Verify the issue was created successfully and share the link with the user') to close the feedback loop.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary explanation, such as the definition of 'deep module' which Claude already knows. The PRD template is appropriately detailed but the user-story example within it adds some bulk that could be trimmed. | 2 / 3 |
Actionability | The process steps are clear but lack concrete commands or executable examples. Instructions like 'publish it to the project issue tracker' and 'Apply the needs-triage triage label' are vague — no specific tool calls, API commands, or CLI invocations are provided. The PRD template is concrete and useful, but the surrounding workflow relies on assumed context (issue tracker details, setup command) without specifying how to actually execute those actions. | 2 / 3 |
Workflow Clarity | The 3-step process is clearly sequenced and includes a user checkpoint in step 2 (checking module expectations). However, there's no validation after publishing the PRD, no error handling if the issue tracker is unavailable, and no verification that the setup command has been run successfully before proceeding. | 2 / 3 |
Progressive Disclosure | The PRD template is inline rather than in a separate referenced file, which makes the skill longer than necessary. The reference to `/setup-matt-pocock-skills` is a good external pointer, but there are no other references to supporting files. For a skill of this length (~60 lines), the inline template is borderline acceptable but could benefit from being extracted. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- coder/agent-tty
- Commit
a05d4e5
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.