051-design-two-steps-methods

Use when a complex or risky code change should be split into Kent Beck's two-step method by first making the change easy through behavior-preserving preparatory refactoring, then making the intended behavior change once the design supports it. This should trigger for requests such as Apply two-step change; Make this risky change safer; Refactor before changing behavior; Separate preparation from behavior change. Part of Plinth Toolkit

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

85%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 tight, well-structured interactive workflow skill with a clear sequenced process, explicit validation and feedback loops, and clean one-level-deep reference disclosure. The weakest dimension is actionability, where implementation detail is partly deferred to sibling skills.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence without explaining basic concepts, but the 'When to use' list duplicates trigger phrases already present in the frontmatter description, a minor redundancy that could be trimmed rather than the flawless token efficiency of the top anchor.	4 / 5
Actionability	Concrete, specific guidance is given throughout (named refactoring techniques such as extract method/class, isolate dependencies, add seams; explicit verification via tests/build/characterization tests), but step 5 defers detail to other skills and there are no copy-paste examples, leaving minor gaps versus fully executable guidance.	4 / 5
Workflow Clarity	A clearly sequenced six-step workflow with explicit validation checkpoints (step 4 validate preserved behavior, step 6 verify and report) and a feedback loop ('If behavior changes unexpectedly, fix or revert the preparation'), reinforced by a MUST-based Constraints checklist.	5 / 5
Progressive Disclosure	The body is a concise overview pointing to a single one-level-deep, clearly signaled reference (references/051-design-two-steps-methods.md, which exists as a real bundle file), with well-organized sections making navigation easy.	5 / 5
	Total	18 / 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 well-constructed description that clearly answers both what and when, with distinct methodology-specific triggers and low conflict risk. The only soft spot is specificity, which names two actions rather than a comprehensive set.

Dimension	Reasoning	Score
Specificity	Names two concrete actions (behavior-preserving preparatory refactoring, then the intended behavior change) framed with precise methodology language, but does not list several distinct actions, matching the '1-2 concrete actions' anchor rather than the 'several specific actions' anchor above.	3 / 5
Completeness	It explicitly states what the skill does (split a change into preparatory refactoring then the behavior change) and when to use it via concrete trigger phrases, satisfying both halves of the top anchor.	5 / 5
Trigger Term Quality	Four natural trigger phrases ('Apply two-step change', 'Make this risky change safer', 'Refactor before changing behavior', 'Separate preparation from behavior change') give good keyword coverage, though they lack the synonym/extension breadth (e.g., file types or shorthand variants) that would reach the comprehensive anchor.	4 / 5
Distinctiveness Conflict Risk	The 'Kent Beck two-step method' and 'behavior-preserving preparatory refactoring' framing carves a clear, narrowly-scoped niche with distinct triggers and minimal overlap with other skills.	5 / 5
	Total	17 / 20 Passed

Validation

100%

Warnings & errors only

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: jabrena/plinth
Path: skills/051-design-two-steps-methods/SKILL.md
Commit: 77b8825

Reviewed: about 23 hours ago

Table of Contents

Discovery Implementation Validation

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.