Shaping

This is a structured methodology for working through problem and solution design with a user before writing code. It gives you a specific notation system (R for requirements, A/B/C for competing solution shapes, C1/C2 for parts within a shape) and enforces fit checks as decision matrices to compare options. The most interesting bit is the multi-level consistency rule: changes at any abstraction level must ripple up and down through your shaping doc, slices doc, and implementation plans. It's opinionated about chunking (never more than 9 top-level requirements) and phase transitions (you can't slice until you've breadboarded). Use this when you need disciplined exploration of a problem space rather than jumping straight to implementation.

skills.sh installs: 564
GitHub stars: 1.4K
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add rjs/shaping-skills --skill shaping --agent claude-code

Installs into .claude/skills of the current project.

Files

Shaping Methodology

A structured approach for collaboratively defining problems and exploring solution options.

Multi-Level Consistency (Critical)

Shaping produces documents at different levels of abstraction. Truth must stay consistent across all levels.

The Document Hierarchy (high to low)

Shaping doc — ground truth for R's, shapes, parts, fit checks
Slices doc — ground truth for slice definitions, breadboards
Individual slice plans (V1-plan, etc.) — ground truth for implementation details

The Principle

Each level summarizes or provides a view into the level(s) below it. Lower levels contain more detail; higher levels are designed views that help acquire context quickly.

Changes ripple in both directions:

Change at high level → trickles down: If you change the shaping doc's parts table, update the slices doc too.
Change at low level → trickles up: If a slice plan reveals a new mechanism or changes the scope of a slice, the Slices doc and shaping doc must reflect that.