CtrlK
BlogDocsLog inGet started
Tessl Logo

implementation-planner

Converts a PRD or requirements document into a structured, phased implementation plan with individual phase files and granular per-task files written to .context/plans/. Also restructures existing monolithic planning documents into digestible, hierarchical directory structures. Creates a root plan index summarising all phases, a numbered phase file per phase, and a numbered task file per task inside each phase directory. Use when the user asks to create an implementation plan, break down a PRD, convert requirements to tasks, structure project phases, generate a roadmap, plan a project in sprints, organise task breakdown, split a monolithic planning doc, or decompose a spec into phases and tasks.

75

Quality

94%

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

SKILL.md
Quality
Evals
Security

Quality

Content

92%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 highly operational skill file: both modes are driven by runnable scripts with mandatory validation loops, safety ordering rules for destructive cleanup, and a scope guardrail that halts execution at 9+ phases. The only notable weakness is redundancy — the trigger-phrase lists and mode-mapping content appear in three overlapping sections, and the Mindset section adds little actionable value.

Suggestions

Collapse the "Trigger phrases" section into the "When to use each mode" table — the phrases already appear in the description and are largely restated in the Recognition examples table.

Trim the "Mindset" section to its one useful sentence (the two failure modes) or fold it into the intro; the 'navigable contract' framing is padding.

The Mode 2 naming-convention GOOD/BAD block ("step-1-extract-movement-logic" etc.) is reference material — consider moving it to references/mode2-advanced.md to shorten the main file.

DimensionReasoningScore

Conciseness

The body is largely efficient — tables instead of prose, exact commands, no explanations of concepts Claude already knows — but the "Trigger phrases" section ("create an implementation plan", "plan this out in phases", etc.) substantially duplicates the description and the overlapping "When to use each mode" and "Recognition examples" tables, and the "Mindset" section ("a navigable contract between an agent and a codebase") is philosophical padding. Not score 3 because these are trimmable redundancies in an otherwise tight document, not pervasive over-explanation.

4 / 5

Actionability

Guidance is fully executable throughout: exact scaffold commands ("sh scripts/new-plan.sh <plan-slug>"), the concrete output directory tree, the identifier format with a worked example ("P02T03 = phase 2, task 3"), slug conversion examples, and a copy-paste-ready guardrail message template. Not score 4 because commands and examples cover the common cases for both modes completely, including validation with documented exit codes ("Exit 0 = valid, 1 = invalid").

5 / 5

Workflow Clarity

Both modes have clearly sequenced steps with explicit validation checkpoints and feedback loops: Mode 1 Step 5 mandates "MUST run before reporting to the user — no exceptions" with a fix-and-re-run loop ("If any file fails: fix the violation and re-run validate-plan.sh. Repeat until exit 0"), and Mode 2 ends with a validation checklist plus a safety ordering rule ("never delete source before the new structure is confirmed valid"). Not score 4 because checkpoints, error-recovery loops, and checklists are all present, matching the score-5 anchor.

5 / 5

Progressive Disclosure

The body is a well-signaled overview with one-level-deep references that all resolve to real files: anti-patterns.md, worked-examples.md, mode2-advanced.md, example-transformation.md, seven templates/*.yaml, and the schemas — each listed in a table with a "When to Use" column, plus explicit resource-loading rules ("Load scripts and templates only when needed"). Not score 4 because the split is appropriate and navigation is easy: detail genuinely lives in the references while SKILL.md carries only the operating procedure.

5 / 5

Total

19

/

20

Passed

Description

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

An exemplary description: third-person voice, specific capabilities with a named output location, and an explicit 'Use when' clause with ten natural trigger phrases spanning both of the skill's modes. The only weakness is that a couple of triggers ('generate a roadmap', 'sprint planning') are broad enough to invite minor overlap with adjacent planning skills.

Suggestions

Tighten the broadest triggers (e.g. replace "generate a roadmap" with "generate a phased implementation roadmap from a spec") so the description triggers only when the hierarchical plan output is actually wanted.

DimensionReasoningScore

Specificity

The description enumerates multiple concrete actions with comprehensive coverage: "Converts a PRD or requirements document into a structured, phased implementation plan", "restructures existing monolithic planning documents", "Creates a root plan index... a numbered phase file per phase, and a numbered task file per task", and names the exact output location (.context/plans/). Not score 4 because coverage of the skill's two modes and their outputs is complete, not just 'several actions with minor gaps'.

5 / 5

Completeness

Both questions are answered explicitly and concretely: the 'what' is three sentences of specific capability and output structure, and the 'when' is an explicit "Use when the user asks to..." clause listing concrete trigger phrases. Not score 4 because the 'when' is not merely present but enumerates ten specific triggers, matching the score-5 anchor example.

5 / 5

Trigger Term Quality

The 'Use when' clause covers natural phrasings and their synonyms comprehensively: "create an implementation plan, break down a PRD, convert requirements to tasks, structure project phases, generate a roadmap, plan a project in sprints, organise task breakdown, split a monolithic planning doc, or decompose a spec into phases and tasks" — these are phrases a user would naturally say. Not score 4 because both creating and restructuring trigger vocabularies are covered with variations, leaving no obvious common terms missing.

5 / 5

Distinctiveness Conflict Risk

The niche is clear — PRD-to-phased-plan decomposition with a defined file layout and plan restructuring — and most triggers ("break down a PRD", "decompose a spec") are unambiguous. Not score 5 because broad triggers like "generate a roadmap" and "plan a project in sprints" create minor overlap risk with general project-management or roadmap skills, matching the 'mostly distinct; minor overlap risk' anchor rather than 'minimal conflict risk'.

4 / 5

Total

19

/

20

Passed

Validation

87%

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

Validation14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 5 deeper-than-1-level

Warning

referenced_paths_exist

Referenced path issues: 1 missing, 16 deeper-than-1-level

Warning

Total

14

/

16

Passed

Repository
pantheon-org/tekhne
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.