OpenClaw · Skill

Shaping

Structured methodology for defining problems, exploring solutions, and planning implementation. Based on Shape Up adapted for working with an LLM.

Calendar & Scheduling
v1.0.0
VirusTotal: Benign

Install

Start with the primary install command. Alternate entrypoints are included below for ClawHub and OpenClaw CLI users.

Primary command

clawhub install borahm/shaping

ClawHub installer

npx clawhub@latest install borahm/shaping

OpenClaw CLI

openclaw skills install borahm/shaping

Direct OpenClaw install

openclaw install borahm/shaping

What this skill does

Structured methodology for defining problems, exploring solutions, and planning implementation. Based on Shape Up adapted for working with an LLM.

Why it matters

Unlike ad-hoc planning or user stories, it enforces a fit check across all requirements before committing to a shape, catching mismatches before any implementation begins.

Typical use cases

  • Defining requirements for a new feature before writing any code
  • Comparing solution approaches side by side with a structured fit check
  • Mapping an existing system to find where a proposed change lands
  • Breaking a scoped feature into demo-able vertical implementation slices
  • Running a 'should we build X or Y?' discussion with structured outputs

Source instructions

Shaping & Breadboarding

Structured methodology for defining problems, exploring solutions, and planning implementation. Based on Shape Up adapted for working with an LLM.

Source: rjs/shaping-skills by @rjs (Ryan Singer, author of Shape Up)

Two Skills in One

Shaping — Iterate on problem (requirements) and solution (shapes) before committing to implementation. Separates what you need from how you might build it, with fit checks to see what's solved and what isn't.

Breadboarding — Map a system into UI affordances, code affordances, and wiring. Shows what users can do and how it works underneath in one view. Good for slicing into vertical scopes.

When to Use

  • Exploring a new feature or product direction
  • Comparing solution approaches before building
  • Mapping an existing system to understand where changes land
  • Breaking a selected solution into vertical implementation slices
  • Any "should we build X or Y?" discussion

Entry Points

  • Start from R (Requirements) — Describe the problem, pain points, constraints. Build up requirements and let shapes emerge.
  • Start from S (Shapes) — Sketch a solution already in mind. Capture it as a shape and extract requirements as you go.

No required order. R and S inform each other throughout.

Core Notation

LevelNotationMeaningRelationship
RequirementsR0, R1, R2...Problem constraintsMembers of set R
ShapesA, B, C...Solution optionsPick one from S
ComponentsC1, C2, C3...Parts of a shapeCombine within shape
AlternativesC3-A, C3-B...Approaches to a componentPick one per component

Phases

Shaping → Slicing
  • Shaping: Explore problem/solution space, select and detail a shape
  • Slicing: Break down for implementation into vertical slices with demo-able UI

Key Actions

  • Populate R — Gather requirements as they emerge
  • Sketch a shape — Propose a high-level approach
  • Detail — Break shape into components or concrete affordances
  • Check fit — Build decision matrix (R × S), binary ✅/❌ only
  • Breadboard — Map to UI/Code affordances with wiring
  • Spike — Investigate unknowns
  • Slice — Break breadboarded shape into vertical increments

Detailed Reference

For the complete methodology, notation rules, examples, and procedures:

  • Shaping reference: See references/shaping.md — Full shaping methodology including fit checks, parts, spikes, documents, multi-level consistency
  • Breadboarding reference: See references/breadboarding.md — Complete breadboarding procedure, affordance tables, places, wiring, Mermaid conventions, chunking, slicing

Load the relevant reference when entering that phase of work.

Quick Reference: Fit Check Format

| Req | Requirement | Status | A | B | C |
|-----|-------------|--------|---|---|---|
| R0 | Full requirement text | Core goal | ✅ | ✅ | ✅ |
| R1 | Full requirement text | Must-have | ✅ | ❌ | ✅ |
  • Always show full requirement text, never abbreviate
  • Binary only: ✅ or ❌. No ⚠️ in fit checks
  • Explanations go in Notes section below the table

Quick Reference: Affordance Tables

UI Affordances: # | Place | Component | Affordance | Control | Wires Out | Returns To Code Affordances: Same columns Controls: click, type, call, observe, write, render Wires Out (solid →): Control flow — calls, triggers, writes Returns To (dashed -.->): Data flow — return values, reads

Quick Reference: Slicing

  • Every slice must end in demo-able UI
  • Max 9 slices
  • Each slice demonstrates a mechanism working
  • Format: V1: Name — affordances, demo statement

Related OpenClaw skills

Browse all →
Featured slot

Your product here

Reserve this slot to reach operators and coding-agent buyers.

Shown where builders are actively comparing tools and deployment options.

Advertise