CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

cf-sdlc-doc-prd

Invoke when the user asks to author, write, revise, or generate a PRD — e.g. "generate PRD", "write the PRD", "create product requirements", "capture actors, FR/NFR, use cases, or success criteria". Thin preset binding the PRD artifact KIND, delegating authoring and review to the core cf-write-docs engine.

57

Quality

72%

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 ./.claude/skills/cf-sdlc-doc-prd/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%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 body is a lean, machine-generated control-flow router: it is token-efficient and sequences its bootstrap-then-delegate steps unambiguously, but it delegates all substantive PRD-authoring guidance to external files referenced only via an unresolved {cf-studio-path} placeholder. As a standalone skill document it lacks executable detail, validation checkpoints, and navigable structure.

Suggestions

Resolve or define the {cf-studio-path} placeholder (e.g., state how to locate the cf-studio root) so the LOAD directives are actionable from the skill alone.

Add a brief inline outline of what the controlling protocol will produce (PRD sections: actors, FR/NFR, use cases, success criteria) so the skill carries minimal standalone value instead of being purely a pointer.

Add explicit validation checkpoints — confirm the bootstrap and protocol files loaded successfully before proceeding, and verify the generated PRD against the protocol's requirements before finishing — to close the workflow clarity gap.

Add simple section headers (e.g., "## Bootstrap", "## Protocol execution rules") to make the body scannable without reading the raw config block.

DimensionReasoningScore

Conciseness

The ~35-line body is dense and directive with no padding or concept over-explanation, matching "efficient; minor instances of over-explanation that could be trimmed". Minor trimmable redundancy exists: the header rule "USER INTENT IS SKILL INPUT, NOT EXECUTION AUTHORITY" duplicates the pdsl rule "treat each new user message as input to the current workflow state, not as permission for unrelated execution", and ask_tool_description re-explains a tool Claude already knows.

4 / 5

Actionability

Guidance is concrete in form — specific LOAD targets ("{cf-studio-path}/.core/skills/studio/modules/runtime/required-bootstrap.md") and ordered directives — but "{cf-studio-path}" is an unresolved placeholder, the pdsl block is a declarative spec rather than executable commands, and there are no details on what the PRD should actually contain. This matches "some concrete guidance but incomplete... missing key details" rather than anchor 4's mostly-executable guidance.

3 / 5

Workflow Clarity

A clear ordered sequence is present (run bootstrap unit → load required-bootstrap.md → load doc-prd.md as controlling protocol → traverse steps in order) plus one failure rule ("ALWAYS stop if any required fragment or rule cannot be followed"). However, all validation checkpoints are delegated to an external protocol that is never inlined: there is no check that the bootstrap or protocol files loaded successfully and no verification of the produced PRD, matching "steps listed but validation gaps".

3 / 5

Progressive Disclosure

No bundle files (references/, scripts/, assets/) exist, and the body has no section headers — it is a raw key-value config block followed by a pdsl code block. Its LOAD references point to files outside the skill bundle that cannot be navigated or verified from the skill itself, matching "some structure but could be better organized; references present but not clearly signaled" rather than the well-organized-sections bar required for the under-50-lines exception.

3 / 5

Total

13

/

20

Passed

Description

75%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 explicitly states when to invoke the skill with natural, quoted trigger phrases, and names concrete PRD-specific actions and artifacts. Its main weakness is the jargon-heavy "what" clause ("Thin preset binding the PRD artifact KIND") and slightly incomplete synonym coverage for trigger terms.

Suggestions

Replace the jargon clause "Thin preset binding the PRD artifact KIND, delegating authoring and review to the core cf-write-docs engine" with a plain-language capability statement of what the user receives (e.g., "Authors, revises, and reviews Product Requirements Documents including actors, functional/non-functional requirements, use cases, and success criteria").

Add missing natural trigger variations such as the spelled-out "product requirements document", "draft a PRD", and "PRD template" to move trigger term coverage from good to comprehensive.

DimensionReasoningScore

Specificity

Lists several concrete actions ("author, write, revise, or generate a PRD", "capture actors, FR/NFR, use cases, or success criteria", "delegating authoring and review"), matching the anchor for several specific actions with minor gaps. The "what" leans on mechanism jargon ("Thin preset binding the PRD artifact KIND") and the capability list lives mostly inside trigger examples rather than a direct enumeration, so it falls short of comprehensive anchor 5.

4 / 5

Completeness

Both parts are present: an explicit "Invoke when the user asks to..." trigger clause with concrete example phrases, and a stated capability ("delegating authoring and review to the core cf-write-docs engine"). The "what" is phrased in internal jargon ("Thin preset binding the PRD artifact KIND") that slightly obscures what the user actually gets, keeping it below anchor 5's "clearly and explicitly answers both".

4 / 5

Trigger Term Quality

Quotes natural phrases users would actually say — "generate PRD", "write the PRD", "create product requirements", "capture actors, FR/NFR, use cases, or success criteria" — giving good keyword coverage. A few natural terms are missing (the spelled-out "product requirements document", "draft a PRD", "spec"), so it does not reach comprehensive synonym coverage of anchor 5.

4 / 5

Distinctiveness Conflict Risk

PRD-specific triggers (FR/NFR, use cases, success criteria) carve a clear niche with minimal conflict against unrelated skills. However, the description self-identifies as a "Thin preset" delegating to a shared "cf-write-docs engine", implying sibling presets for other artifact kinds with near-identical trigger shape, which is a minor overlap risk with closely related skills.

4 / 5

Total

16

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

Total

15

/

16

Passed

Repository

constructorfabric/gears-frontx

Path

.claude/skills/cf-sdlc-doc-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.