Use when organizing PRDs, tracking requirements, managing product specs, updating PRD status, archiving completed docs, or setting up PRD structure. Auto-applies naming conventions and lifecycle management.
Install with Tessl CLI
npx tessl i github:jpoutrin/product-forge --skill prd-management74
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
72%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 has strong trigger terms and clear distinctiveness for PRD-related tasks, making it easy to identify when this skill should be selected. However, it lacks specificity about concrete capabilities (what exactly does 'organizing PRDs' or 'lifecycle management' entail?) and the structure prioritizes 'when' over 'what', leaving the actual functionality somewhat vague.
Suggestions
Add specific concrete actions at the beginning, e.g., 'Creates PRD templates, tracks requirement status, links specs to user stories, manages version history'
Restructure to lead with 'what' before 'when': describe capabilities first, then follow with the 'Use when...' clause
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (PRDs/product requirements) and lists several actions (organizing, tracking, managing, updating, archiving, setting up), but the actions are somewhat generic verbs rather than concrete specific operations like 'create PRD templates' or 'link requirements to user stories'. | 2 / 3 |
Completeness | Has a 'Use when...' clause which is good, but the 'what does this do' portion is weak - it lists activities but doesn't clearly explain the concrete capabilities. The description leads with 'when' rather than establishing 'what' first. | 2 / 3 |
Trigger Term Quality | Good coverage of natural terms users would say: 'PRDs', 'requirements', 'product specs', 'PRD status', 'PRD structure'. These are terms a product manager would naturally use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | Clear niche focused specifically on PRDs and product requirements documentation. The specific terms 'PRD', 'product specs', and 'lifecycle management' create a distinct domain unlikely to conflict with general document or project management skills. | 3 / 3 |
Total | 10 / 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 skill provides solid, actionable guidance for PRD management with concrete naming conventions, directory structures, and metadata templates. The main weaknesses are missing validation/verification steps in the workflow (how to actually validate status transitions) and the content could benefit from better progressive disclosure by splitting templates and detailed rules into separate reference files.
Suggestions
Add explicit validation steps for status transitions (e.g., 'Before moving to APPROVED: run checklist, if any item fails, return to DRAFT')
Include a feedback loop for the quality checks section showing what to do when checks fail
Consider splitting YAML templates and the quality checklist into a separate TEMPLATES.md file for cleaner progressive disclosure
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Content is reasonably efficient but includes some redundancy (e.g., explaining what directories are for when names are self-explanatory). The YAML examples and directory structure are useful but could be slightly tighter. | 2 / 3 |
Actionability | Provides concrete, copy-paste ready examples including exact file naming patterns, directory structures, YAML frontmatter templates, and markdown snippets. The quality checklist and archival rules are specific and actionable. | 3 / 3 |
Workflow Clarity | Status lifecycle is clearly defined (DRAFT → REVIEW → APPROVED → ACTIVE → COMPLETE → ARCHIVED), but lacks explicit validation steps or feedback loops. 'Validate status transitions' is mentioned but not explained how to verify or recover from invalid transitions. | 2 / 3 |
Progressive Disclosure | Content is well-organized with clear sections, but everything is inline in a single file. For a skill of this complexity (lifecycle management, multiple document types, archival rules), some content could be split into referenced files for templates or detailed workflows. | 2 / 3 |
Total | 9 / 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.
Table of Contents
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.