CtrlK
BlogDocsLog inGet started
Tessl Logo

plan-change

Turn a feature request into a minimal, file-level implementation plan before any code.

63

Quality

73%

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 ./harness/wifi-densepose-sar/.claude/skills/plan-change/SKILL.md

The canonical home for this skill is plan-change in ruvnet/RuVector

SKILL.md
Quality
Evals
Security

Quality

Content

86%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 content is an exceptionally concise, well-structured planning procedure with clear sequencing and an appropriate ripple-flag checkpoint. Its only soft spot is actionability, where a brief concrete plan-entry example would push it to fully executable.

Suggestions

Add a one-line example of a plan entry (e.g., a sample file-list + interface line) to make the guidance copy-paste concrete.

Consider an explicit final checkpoint such as 'Confirm the plan names a smallest interface and flags ripples before handing off.'

DimensionReasoningScore

Conciseness

The body is a lean six-line numbered procedure with zero over-explanation and no padding, assuming Claude's competence and earning every token, matching the anchor-5 example.

5 / 5

Actionability

The numbered steps are concrete and executable ('List the files to touch and why', 'Name the smallest interface that satisfies it') with only minor abstraction, sitting above the vague/gap anchors but short of fully copy-paste-ready specificity.

4 / 5

Workflow Clarity

A clear numbered sequence with a built-in ripple-checkpoint (step 4) for a single-purpose non-destructive skill fits the 'clear sequence with most checkpoints' anchor; it lacks an explicit plan-verification feedback loop that would reach 5.

4 / 5

Progressive Disclosure

Under 50 lines with no need for external references and a well-organized numbered structure, which per the simple-skills guideline allows a 5 on progressive disclosure without separate files.

5 / 5

Total

18

/

20

Passed

Description

61%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 concise and states a clear purpose, but it omits any explicit 'when to use' trigger guidance, capping its completeness. Trigger term coverage is good but missing common synonyms.

Suggestions

Add a 'Use when...' clause naming concrete triggers (e.g., 'Use when turning a feature request into a plan before implementation, or when scoping a change').

Broaden trigger terms with synonyms users actually say, such as 'design', 'spec', 'outline', or 'break down'.

List one or two more concrete plan elements (e.g., 'file list, interface signature, ripple risks') to lift specificity from 1-2 actions toward comprehensive.

DimensionReasoningScore

Specificity

Names the domain (feature request → implementation plan) and a concrete action (produce a file-level plan), but does not enumerate multiple specific actions, matching the '1-2 concrete actions' anchor rather than the comprehensive anchor 4 or the minimal anchor 2.

3 / 5

Completeness

It states a clear 'what' (turn a feature request into a file-level plan) but provides no 'Use when...' trigger clause, which per the judging guidelines caps completeness at 3.

3 / 5

Trigger Term Quality

Includes natural terms like 'feature request', 'implementation plan', and 'before any code' that a user would plausibly say, but lacks common synonyms such as 'design', 'spec', or 'outline', so it sits at good-but-not-comprehensive coverage.

4 / 5

Distinctiveness Conflict Risk

'File-level implementation plan before any code' carves a mostly distinct planning niche with only minor overlap risk against general design/architecture skills, fitting the 'mostly distinct' anchor better than anchor 3 or 5.

4 / 5

Total

14

/

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
ruvnet/RuView
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.