Requirements
- Target platform
- OpenClaw
- Install method
- Manual import
- Extraction
- Extract archive
- Prerequisites
- OpenClaw
- Primary doc
- SKILL.md
Shape Up methodology for product and feature development. Use when collaboratively shaping a solution — iterating on problem definition (requirements) and solution options (shapes), breadboarding systems into affordances and wiring, and slicing into vertical implementation increments. Triggers include "shape this feature", "breadboard the system", "let's shape", "slice this into increments", "fit check", "define requirements", or any product/feature scoping discussion using Shape Up methodology.
Shape Up methodology for product and feature development. Use when collaboratively shaping a solution — iterating on problem definition (requirements) and solution options (shapes), breadboarding systems into affordances and wiring, and slicing into vertical implementation increments. Triggers include "shape this feature", "breadboard the system", "let's shape", "slice this into increments", "fit check", "define requirements", or any product/feature scoping discussion using Shape Up methodology.
Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.
I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete.
I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run.
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)
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.
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
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.
LevelNotationMeaningRelationshipRequirementsR0, R1, R2...Problem constraintsMembers of set RShapesA, B, C...Solution optionsPick one from SComponentsC1, C2, C3...Parts of a shapeCombine within shapeAlternativesC3-A, C3-B...Approaches to a componentPick one per component
Shaping → Slicing Shaping: Explore problem/solution space, select and detail a shape Slicing: Break down for implementation into vertical slices with demo-able UI
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
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.
| 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
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
Every slice must end in demo-able UI Max 9 slices Each slice demonstrates a mechanism working Format: V1: Name — affordances, demo statement
Code helpers, APIs, CLIs, browser automation, testing, and developer operations.
Largest current source with strong distribution and engagement signals.