CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

write-prd

Produce a Product Requirements Document (PRD) for a product feature. Use when the user asks to write a PRD, or to formalize a feature's scope, goals, user value and success metrics. Not for internal technical or architecture change proposals.

60

Quality

75%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/flowai-engineering/skills/write-prd/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

56%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.

The core PRD guidance (principles, template, examples, workflow) is concrete and well structured, but the body is bloated by a lengthy off-topic question-formatting section and duplicated persist-to-disk instructions. Moving the question-format rules to a reference file and tightening Section 2 would substantially improve both conciseness and organization.

Suggestions

Move the Section 0 'Question Format (FR-UNIVERSAL.QA-FORMAT)' rules to a references/ file (e.g., references/question-format.md) and keep a two- or three-line summary in SKILL.md, cutting roughly half the body's tokens.

State the 'save to a file (documents/prd-<slug>.md)' requirement once — either the top CRITICAL blockquote or step 5 — instead of repeating it twice.

Tighten the long sub-bullets in Section 2 ('When the product's own data is unknown', question-format details) to the operative rule plus one example each; the current multi-clause paragraphs repeat the same point several ways.

DimensionReasoningScore

Conciseness

Section 0 (Question Format) is a ~1,200-word block of hyper-detailed question-formatting rules (option titles, 'Essence' lines, pointer replacement, catch-all bans) largely unrelated to PRD writing, and the 'MUST save to file' instruction is stated twice (top blockquote and step 5) — noticeably verbose with several padded sections. It is not a 1 because it never explains concepts Claude already knows; the padding is redundancy and off-scope prescriptiveness.

2 / 5

Actionability

The body gives a copy-paste-ready PRD template with concrete sections, concrete Bad-vs-Good examples ('API response time must be under 200ms for 95% of requests at a load of 100 QPS'), a recommended-value format for targets, a specific output path pattern (`documents/prd-<slug>.md`), and a Mermaid example — mostly executable guidance with the minor gap of no worked example of a completed PRD.

4 / 5

Workflow Clarity

Steps 1–5 (Analyze → Ask → Draft → Review → Persist) are clearly sequenced with an ordering constraint (never write the file in the question round), a review checkpoint against Section 4 examples, and a feedback loop for unanswered targets (recommended value marked '(proposed, awaiting approval)' and listed in Open Questions). It is not a 5 because the Review checkpoint is a single soft instruction with no verification of the persisted file.

4 / 5

Progressive Disclosure

Sections are well organized, but the skill is ~185 lines with no bundle files, and the large Question Format section (labeled 'FR-UNIVERSAL.QA-FORMAT', suggesting a shared standard) is inlined wholesale when it clearly belongs in a separate reference file — matching 'some structure but content that should be separate is inline'. Not a 2 since the remaining structure is genuinely clear and navigable, and not a 4 because the inline bulk is substantial.

3 / 5

Total

13

/

20

Passed

Description

82%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 what the skill does, when to use it with natural trigger phrases, and explicitly excludes a neighboring use case. Its only weakness is modest capability coverage — one deliverable action rather than multiple specific actions — and a few missing synonyms like 'product spec'.

DimensionReasoningScore

Specificity

The description names the domain ('Product Requirements Document (PRD) for a product feature') and the concrete action of producing it, plus aspects like scope, goals, user value and success metrics — but these read as facets of one deliverable rather than a comprehensive list of distinct capabilities, matching the 'names domain and 1-2 concrete actions' anchor.

3 / 5

Completeness

It explicitly answers both what ('Produce a Product Requirements Document (PRD) for a product feature') and when ('Use when the user asks to write a PRD, or to formalize a feature's scope, goals, user value and success metrics') with concrete trigger phrases, plus an explicit negative boundary.

5 / 5

Trigger Term Quality

'Use when the user asks to write a PRD' is exactly the natural phrase a user would say, and 'formalize a feature's scope, goals, user value and success metrics' covers related phrasings; however common synonyms like 'product spec', 'requirements doc', or 'feature requirements' are missing.

4 / 5

Distinctiveness Conflict Risk

The PRD niche is clear and the explicit exclusion 'Not for internal technical or architecture change proposals' sharply separates it from adjacent technical-writing skills, giving minimal conflict risk.

5 / 5

Total

17

/

20

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

Validation for skill structure

No warnings or errors.

Repository

korchasa/flowai-plugins

Path

plugins/flowai-engineering/skills/write-prd/SKILL.md

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.