CtrlK
BlogDocsLog inGet started
Tessl Logo

spec-planning

Reads a PRD (`prds/<feature>/prd.md`) plus its executable `run-prd-test.sh` (and any helper artifacts under `prds/<feature>/`), grounds them in codebase research, and produces `specs/<feature>/mainspec.md` plus dependency-ordered slices. Encodes the runner as a slice success criterion so implementation completion implies `./prds/<feature>/run-prd-test.sh` exits 0. Touches `specs/<feature>/.planning-done` as its final committed action. Agent-first — no human-in-the-loop.

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 ./skills/sdd/spec-planning/SKILL.md

The canonical home for this skill is spec-planning in tdg-ninja/context-specs-factory-ai

SKILL.md
Quality
Evals
Security

Quality

Content

70%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 skill body delivers an exceptionally clear, validated workflow with concrete commands, templates, and robust recovery protocols, and its guidance is largely executable. Its weaknesses are verbosity from duplicated role prose and long generic example sections, plus two referenced catalogs that are empty placeholders, which both undermines the MUST-read steps and argues for moving bulk examples into reference files.

Suggestions

Populate `references/experts.md` and `references/signals.md` (or drop the MUST-read mandates) — they currently contain only a heading, so the mandated steps produce no guidance.

Move the ~180-line Context Engineering example section into a reference file (e.g. `references/context-engineering.md`) and keep a short pattern summary with a one-line pointer per pattern in SKILL.md.

Merge the "Spec-Driven Development & Your Role" prose paragraph into the Guidelines bullets — they cover the same ground (ground in PRD/codebase, WHAT not HOW, temporal ordering) twice.

DimensionReasoningScore

Conciseness

The Invocation Contract, Guidelines, and Output Structure are efficient and instruction-dense, but the ~340-line body carries noticeable padding: the "Spec-Driven Development & Your Role" prose paragraph substantially repeats the Guidelines bullets, and the ~180-line Context Engineering section teaches generic spec-writing patterns through invented e-commerce examples (Student/Lesson/DynamoDB) that Claude could produce unprompted. This fits 'mostly efficient but includes some unnecessary explanation or could be tightened' — not 2, since none of it is concept-explanation filler like explaining what a library is, and not 4, since the duplication and generic example bulk go beyond minor trimmable instances.

3 / 5

Actionability

Concrete, executable guidance throughout: exact invocation (`claude -p "/spec-planning <feature>"`), exact input/output paths, a numbered completion protocol with git add/commit/push steps, idempotency and crash-recovery handling, and copy-paste markdown templates for the Signal section and Slice Dependency Map. The main gap is that the two "MUST Read" catalogs (`references/experts.md`, `references/signals.md`) are effectively empty (single heading, no content), so those steps yield nothing actionable — minor gaps that keep this at 'mostly executable guidance with minor gaps' rather than fully copy-paste-ready at 5.

4 / 5

Workflow Clarity

The multi-step process is explicitly sequenced (completion protocol: write artifacts → commit/push → touch sentinel → commit/push) with strong validation and feedback loops: the sentinel is gated on prior steps, idempotency short-circuits repeat invocations, crash recovery ("verify the existing artifacts are complete and self-consistent, fix any gaps, then write the sentinel") handles partial failure, and the ambiguous-PRD path (write clarifications-needed.md, exit without sentinel) is an explicit error-recovery branch. This matches the top anchor 'clear sequence with explicit validation steps; feedback loops for error recovery'.

5 / 5

Progressive Disclosure

The body is well-sectioned and its two reference files exist at one level deep, but both referenced catalogs (`references/experts.md`, `references/signals.md`) are empty placeholders containing only a heading, making the "MUST Read the experts catalog at START of planning" pointers effectively broken; meanwhile ~180 lines of Context Engineering example material that would fit naturally in a reference file are inlined in SKILL.md. This sits at 'some structure but could be better organized; references present but not clearly signaled; content that should be separate is inline' — not 2 (structure and navigation are present, not minimal/buried) and not 4 (the empty references and inlined bulk are more than minor gaps).

3 / 5

Total

15

/

20

Passed

Description

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

The description is highly specific, concrete, and third-person with exact file paths and a well-defined input/output contract, but it completely lacks a 'Use when...' trigger clause and offers limited natural-keyword coverage. Its distinctiveness within the spec-planning workflow is excellent.

Suggestions

Add an explicit trigger clause, e.g. "Use when the dispatcher needs to turn a PRD into an ordered spec plan, or when planning features via spec-driven development from `prds/<feature>/`."

Include natural synonyms users would say — "requirements", "feature planning", "spec-driven development", "turn a PRD into specs" — to broaden trigger-term coverage.

Trim mechanism detail (e.g. the sentinel-touch mechanics) in favor of one sentence on when the skill applies, keeping the description focused on what + when.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions with exact paths: "Reads a PRD (`prds/<feature>/prd.md`) plus its executable `run-prd-test.sh`", "produces `specs/<feature>/mainspec.md` plus dependency-ordered slices", "Encodes the runner as a slice success criterion", "Touches `specs/<feature>/.planning-done` as its final committed action". It is written in third person ("Reads", "produces", "Touches") and covers inputs, outputs, and completion semantics comprehensively, matching the top anchor rather than the 'several specific actions with minor gaps' anchor at 4.

5 / 5

Completeness

The 'what' is explicit and detailed (read PRD + runner, research codebase, write mainspec + slices, commit sentinel), but there is no 'Use when...' clause or equivalent trigger guidance — the closest hint is "Agent-first — no human-in-the-loop", which describes the execution model, not when to invoke it. Per the judging guidelines, a missing 'Use when...' clause caps completeness at 3, which this clearly fits ('clear what, when missing or only weakly implied').

3 / 5

Trigger Term Quality

Relevant domain keywords are present ("PRD", "spec", "mainspec", "slices", "run-prd-test.sh", "codebase research") but common natural variations a user or dispatcher would say are missing — no "spec-driven development", "requirements", "feature planning", "turn PRD into specs", or similar synonyms. It matches the anchor 'Some relevant keywords but missing common variations or synonyms', not 4 (which would require broad natural-term coverage) nor 2 (keywords here are domain-specific, not generic filler like "works with files").

3 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche via unique artifacts (`run-prd-test.sh`, `mainspec.md`, `.planning-done` sentinel, slice dependency ordering) that no generic planning or document skill would claim, giving minimal conflict risk. It sits at the 'clear niche with distinct triggers' anchor rather than 4, since even closely related spec-writing skills would be distinguished by the PRD-test-runner and sentinel contract.

5 / 5

Total

16

/

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
tdg-ninja/context-specs-claude-code
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.