prd-writing
When the user needs to define a product feature, write a product requirements document, or translate an idea into a structured spec.
71
64%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/prd-writing/SKILL.mdQuality
Discovery
64%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 effectively communicates when to use the skill with natural trigger terms, but it reads more like a trigger clause without a clear 'what it does' statement. It would benefit from leading with concrete capabilities (e.g., 'Generates structured product requirements documents with user stories, acceptance criteria, and prioritization') before the 'Use when' guidance.
Suggestions
Add an explicit 'what it does' statement before the trigger clause, e.g., 'Generates structured PRDs with user stories, acceptance criteria, success metrics, and scope definitions.'
Include additional trigger term variations like 'PRD', 'user stories', 'acceptance criteria', 'feature spec' to improve matching against common user vocabulary.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (product management) and some actions ('define a product feature', 'write a product requirements document', 'translate an idea into a structured spec'), but these are somewhat overlapping and not comprehensively listing concrete capabilities like specific deliverables or formats. | 2 / 3 |
Completeness | The description answers 'when' clearly ('When the user needs to...') but the 'what does this do' part is only implied through the trigger conditions rather than explicitly stated as capabilities. It lacks a clear statement of what the skill produces or how it works. | 2 / 3 |
Trigger Term Quality | Includes strong natural trigger terms users would actually say: 'product feature', 'product requirements document', 'idea', 'structured spec', and 'PRD' is implied by 'product requirements document'. These are terms users naturally use when requesting this type of work. | 3 / 3 |
Distinctiveness Conflict Risk | The description is fairly specific to product management documentation, but could overlap with general writing skills, technical specification skills, or project planning skills. Terms like 'structured spec' and 'translate an idea' are somewhat broad. | 2 / 3 |
Total | 9 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable PRD-writing skill with concrete templates, good examples, and clear section definitions. Its main weaknesses are moderate verbosity in the best practices section (some points duplicate template guidance) and a monolithic structure that could benefit from splitting detailed frameworks and examples into separate referenced files. The workflow is clear but could include an explicit confirmation checkpoint after input gathering.
Suggestions
Move the 12-item Frameworks & Best Practices list to a separate referenced file (e.g., PRD_BEST_PRACTICES.md) and keep only the top 3-4 most critical principles inline.
Add an explicit validation checkpoint after step 2 (Gather inputs) to confirm understanding of the problem and scope with the user before drafting.
Remove redundant guidance that appears in both the template descriptions and the best practices (e.g., assumption tracking, out-of-scope, relative timeframes are each mentioned twice).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is reasonably well-structured but includes some unnecessary verbosity, particularly in the Frameworks & Best Practices section which lists 12 bullet points, some of which restate guidance already covered in the template (e.g., assumption tracking, out-of-scope). The 'When to Use' section also over-explains trigger phrases Claude could infer. | 2 / 3 |
Actionability | The skill provides a concrete 8-section template with specific formatting guidance, SMART metric examples, and two detailed output examples showing exactly what good PRD sections look like. The instructions are specific enough to be directly executable. | 3 / 3 |
Workflow Clarity | The 5-step workflow is clearly sequenced and includes a scope clarification step and review/iterate step. However, there are no explicit validation checkpoints between drafting sections — for a document-creation skill this is less critical than for destructive operations, but the workflow could benefit from a checkpoint after gathering inputs to confirm understanding before drafting. | 2 / 3 |
Progressive Disclosure | The skill references related skills (roadmap-planning, mvp-scoping, user-research-synthesis) which is good navigation. However, the content is monolithic — the lengthy Frameworks & Best Practices section and detailed examples could be split into referenced files. At ~120 lines, this is pushing the boundary where progressive disclosure would help. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
- Repository
- shawnpang/startup-founder-skills
- Commit
4ad31b4
- 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.