shaping
Use this methodology when collaboratively shaping a solution with the user - iterating on problem definition (requirements) and solution options (shapes).
45
47%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./shaping/SKILL.mdQuality
Discovery
17%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description is too abstract and relies on methodology-specific jargon ('shapes') without explaining concrete actions or providing natural trigger terms. While it attempts a 'Use when' clause, the trigger condition is vague and would not help Claude distinguish this skill from other collaborative or planning-oriented skills. The description needs substantial improvement in specificity, trigger terms, and distinctiveness.
Suggestions
List specific concrete actions the skill performs, e.g., 'Guides iterative requirements gathering through structured problem statements, solution sketches, and trade-off analysis'.
Add natural trigger terms users would actually say, such as 'brainstorm solutions', 'define requirements', 'explore options', 'scope a feature', 'design session'.
Clarify what makes this skill distinct from general planning or brainstorming — specify the methodology name and its unique artifacts or steps to reduce conflict with similar skills.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description uses vague, abstract language like 'shaping a solution', 'iterating on problem definition', and 'solution options (shapes)' without listing any concrete actions. No specific capabilities are described. | 1 / 3 |
Completeness | It has a 'when' clause ('Use this methodology when collaboratively shaping a solution with the user'), but the 'what' is extremely vague — 'iterating on problem definition and solution options' doesn't clearly explain what the skill actually does. The 'when' trigger is present but not explicit enough with natural user language. | 2 / 3 |
Trigger Term Quality | The terms used ('shaping a solution', 'shapes', 'requirements') are either jargon-specific to a particular methodology or too generic. Users are unlikely to naturally say 'shape' or 'shaping' when requesting help with collaborative problem-solving. | 1 / 3 |
Distinctiveness Conflict Risk | The description is so generic ('collaboratively shaping a solution', 'iterating on problem definition') that it could overlap with virtually any design, planning, brainstorming, or requirements-gathering skill. There are no distinct triggers to differentiate it. | 1 / 3 |
Total | 5 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a comprehensive, well-structured methodology skill that provides highly actionable guidance with concrete formats, examples, and clear do/don't patterns. Its main weakness is length — at 400+ lines it pushes the boundaries of what should be in a single SKILL.md, with some sections that could be extracted into reference files. The workflow is well-defined with explicit phase transitions and validation checkpoints.
Suggestions
Extract detailed sections (Spikes, Breadboards, Shape Parts guidelines) into separate reference files and link to them from the main SKILL.md to improve progressive disclosure and reduce token cost.
Trim the 'Communication > Why This Matters' subsection — the instruction to show full tables is sufficient without explaining why summaries are bad, which Claude can infer.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite long (~400+ lines) and contains some redundancy (e.g., multi-level consistency is explained at the top and referenced again later). However, most content is domain-specific methodology that Claude wouldn't inherently know, so the verbosity is partially justified. Some sections like 'Why This Matters' under Communication could be trimmed. | 2 / 3 |
Actionability | The skill provides highly concrete guidance: specific notation systems (R0, R1, A, B, C1, C2), exact table formats with markdown examples, clear do/don't examples for shape titles, spike questions, and parts. The fit check format, parts table format, and document structures are all copy-paste ready. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced: Starting a Session → Core Concepts → Phases (Shaping → Slicing) with explicit transition criteria. The multi-level consistency section provides clear validation steps (identify level, check ripple effects, update all affected levels). The 'Possible Actions' section enumerates all valid moves. Phase transitions have explicit gates ('You can't slice without a breadboarded shape'). | 3 / 3 |
Progressive Disclosure | The skill references external skills (`/breadboarding`) appropriately and mentions separate document outputs (slices doc, slice plans). However, the SKILL.md itself is a monolithic document with extensive inline content that could benefit from being split into referenced files (e.g., spike guidelines, breadboarding integration, notation reference). The document is long enough that separate reference files would improve navigability. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (594 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- rjs/shaping-skills
- Commit
d8b65d7
- 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.