← ClaudeAtlas

shapinglisted

Use at the very start of any non-trivial build, BEFORE writing code or scaffolding — turning a rough idea into an understood, agreed direction. "let's build X", "I want to make Y", "how should I approach Z", or any request where the goal isn't yet pinned down. Not for turning an already-agreed design into ordered tasks — that's planning
atgreen/hackinator · ★ 1 · API & Backend · score 72
Install: claude install-skill atgreen/hackinator
# Shaping ## Overview **Core principle:** Understand the work and get the human's buy-in *before* building anything. The cheapest place to fix a design is in conversation; the most expensive is in code you've already written. Shaping is where you subtract features, choose an approach, and earn a "yes." ## The Iron Gate ``` NO CODE, NO SCAFFOLDING, NO IMPLEMENTATION SKILL UNTIL THE HUMAN HAS APPROVED THE INTENT ``` This gate is not negotiable and it does not shrink under time pressure. "It's obviously what they want" is exactly the assumption that builds the wrong thing fast. Say what you intend to build; wait for an explicit yes. ## Classify, and Announce It State the path out loud so the human can correct you. Complexity only *upgrades* the path. - **Spike** — "can this even be done?" → shaping is one line: state the question, then go probe (**spike-and-stabilize**). - **Bounded** — a clear, contained change → a short in-chat design, one approval, then build. - **Architectural** — new system, real choices → the full dialogue below, ending in a written design and the **planning** skill. ## How to Shape 1. **Ask one question at a time.** A wall of ten questions gets skimmed and half-answered. One sharp question per message, and **prefer multiple-choice** — it's faster for the human and surfaces options they hadn't named. Wait for the answer before the next. 2. **Propose 2–3 approaches with a recommendation.** Not one (looks like you didn't think) and not fiv