generate-prd

Generate product requirements documents with optional publishing to Confluence or other wiki platforms

Quality

36%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Advisory

Suggest reviewing before use

Optimize this skill with Tessl

npx tessl skill review --optimize ./.claude/skills/generate-prd/SKILL.md

Quality

Discovery

32%

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 identifies a clear domain (PRD generation with Confluence publishing) but lacks explicit trigger guidance ('Use when...'), common user-facing synonyms like 'PRD' or 'spec', and detailed concrete actions. It would benefit from expanded trigger terms and an explicit 'when to use' clause to help Claude reliably select this skill.

Suggestions

Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to create a PRD, product spec, requirements document, or wants to publish requirements to Confluence or a wiki.'

Include common synonyms and abbreviations users would naturally say: 'PRD', 'product spec', 'feature requirements', 'spec doc'.

List more specific concrete actions, e.g., 'Generates structured PRDs with goals, user stories, acceptance criteria, and scope sections; optionally publishes to Confluence or other wiki platforms.'

Dimension	Reasoning	Score
Specificity	Names the domain (product requirements documents) and mentions actions (generate, publish), but doesn't list multiple specific concrete actions like defining sections, stakeholder analysis, acceptance criteria, etc.	2 / 3
Completeness	Describes what it does (generate PRDs with optional publishing) but has no explicit 'Use when...' clause or equivalent trigger guidance, which per the rubric caps completeness at 2, and the 'what' itself is also thin, bringing this to a 1.	1 / 3
Trigger Term Quality	Includes relevant terms like 'product requirements documents', 'Confluence', and 'wiki platforms', but misses common variations users might say such as 'PRD', 'spec', 'product spec', 'requirements doc', or 'feature spec'.	2 / 3
Distinctiveness Conflict Risk	The combination of PRDs and Confluence publishing is somewhat distinctive, but 'product requirements documents' could overlap with general document generation or technical writing skills without clearer scoping.	2 / 3
	Total	7 / 12 Passed

Implementation

39%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The skill has excellent workflow structure with clear phases, validation gates, and fallback handling, but is severely undermined by its verbosity. The full PRD template inlined in the body consumes enormous token budget and should be extracted to a separate file. Publishing instructions are vague rather than executable, and the skill explains many concepts Claude already understands.

Suggestions

Extract the full PRD template into a separate file (e.g., `prd-template.md`) and reference it from the skill body to dramatically reduce token usage

Remove instructional placeholder text from the template (e.g., '[Clear description of the problem being solved. Include data or evidence where available.]') — Claude knows how to fill in a problem statement

Make publishing sections actionable with concrete API calls, headers, and payload examples rather than vague descriptions like 'Use WebFetch to publish via Confluence REST API'

Trim the requirements-gathering section — Claude doesn't need explanations like 'Problem statement — what problem are we solving?' after the field name

Dimension	Reasoning	Score
Conciseness	The skill is extremely verbose at ~250+ lines. The full PRD template is inlined when it could be a separate file. Many sections explain obvious concepts (what a problem statement is, what user stories are). The template placeholders like '[Clear description of the problem being solved. Include data or evidence where available.]' are instructional padding Claude doesn't need.	1 / 3
Actionability	The skill provides concrete steps and some executable bash commands (mkdir, date), but the publishing sections use vague pseudocode ('Use WebFetch to publish via Confluence REST API') rather than executable examples. The context-gathering agent prompts are descriptive but lack concrete tool invocations in several places (e.g., 'Use ToolSearch to load Linear tools' without specifying exact calls).	2 / 3
Workflow Clarity	The workflow is clearly sequenced across 6 phases with explicit checkpoints: a pre-flight check, a review gate before saving, explicit user approval before publishing, and a vault-first save strategy before attempting publishing. The fallback behavior table and error handling section provide good recovery guidance.	3 / 3
Progressive Disclosure	The entire PRD template (~100 lines of markdown) is inlined in the skill body, making it a monolithic wall of text. This template should be in a separate referenced file. There are no bundle files and no references to external files for the template, API details, or advanced configuration, despite clear opportunities to split content.	1 / 3
	Total	7 / 12 Passed

Validation

90%

Warnings & errors only

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: huytieu/COG-second-brain
Commit: 034af4c

Reviewed: 18 days ago

Table of Contents

Discovery Implementation Validation

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.