write-a-prd

Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.

Quality

85%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

75%Weight 40%Scale 1-5

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

A well-structured process skill: a clear five-step workflow with user checkpoints and a detailed, ready-to-use PRD template. The main improvement opportunities are trimming the one redundant concept definition, adding a concrete submission mechanism and a final PRD-validation checkpoint, and moving the template to a reference file.

Suggestions

Delete the deep-module definition sentence (or reduce it to naming the source concept) — Claude already knows Ousterhout's shallow/deep module distinction.

Make step 5 concrete: specify how to submit the GitHub issue (e.g., gh issue create) and add a checkpoint to review the finished PRD with the user before submitting.

Move the <prd-template> block to references/prd-template.md and keep a one-line pointer plus a short section summary in SKILL.md, slimming the body toward the under-50-line ideal.

Dimension	Reasoning	Score
Conciseness	The body is lean — numbered steps with no padding — but the sentence "A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes" re-explains a concept (Ousterhout's deep modules) Claude already knows. This is a minor, trimmable instance of over-explanation rather than a pervasive problem, so it sits at 4 rather than 3.	4 / 5
Actionability	The PRD template with section-by-section requirements, the concrete user-story format example, and the specified output location ("./ai-context/prds/") give mostly executable guidance. It falls short of 5 because steps like "Explore the repo" and "Interview the user relentlessly" give no concrete techniques, and "submitted as a GitHub issue" names no mechanism (e.g., gh issue create).	4 / 5
Workflow Clarity	A clear five-step sequence with user-confirmation checkpoints ("Check with the user that these modules match their expectations") and an explicit completeness gate ("Once you have a complete understanding..."). Not 5: there is no final validation of the written PRD against the user's answers before submission, and the submission step itself is implicit.	4 / 5
Progressive Disclosure	A single well-organized file with no nested or buried references, and no bundle files exist to misstructure. At roughly 70 lines — past the under-50-line simple-skill guideline — the ~50-line PRD template could live in references/ with the body as an overview, which is what keeps this at 4 rather than 5.	4 / 5
	Total	16 / 20 Passed

Description

88%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: it states concrete actions with a clear deliverable and destination, and pairs them with an explicit "Use when" trigger clause that includes natural phrasings and the expanded form of PRD. The only gaps are a few missing synonyms (e.g., "spec") and the slightly broad "plan a new feature" trigger.

Dimension	Reasoning	Score
Specificity	"Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue" lists multiple specific concrete actions covering the whole workflow (interview, explore, design, deliver, submit). Coverage is comprehensive for this domain, matching the level-5 anchor rather than the minor-gaps level-4 anchor.	5 / 5
Completeness	The description explicitly answers what ("Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue") and when ("Use when user wants to write a PRD, create a product requirements document, or plan a new feature") with concrete trigger phrases, mirroring the anchor-5 example.	5 / 5
Trigger Term Quality	"write a PRD", "create a product requirements document", and "plan a new feature" are natural phrases users would say, including the full expansion of the acronym. Not 5 because common synonyms like "spec", "requirements doc", or "feature spec" are missing.	4 / 5
Distinctiveness Conflict Risk	PRD creation with GitHub-issue submission is a mostly distinct niche with minor overlap risk. Not 5 because the trigger "plan a new feature" is broad enough to overlap with generic planning or architecture skills.	4 / 5
	Total	18 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: webiny/webiny-js
Path: .claude/skills/write-a-prd/SKILL.md
Commit: f0d3d3e

Reviewed: 3 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.