{
  "schema_version": 1,
  "skill_name": "product-shaping",
  "evals": [
    {
      "id": "grab-bag-narrowing-or-routing",
      "prompt": "Customers keep asking us to redesign our settings section. It feels dated and messy. Plan the work for next quarter.",
      "expected_output": "The agent should recognize 'redesign the settings section' as a grab-bag: it has no defined problem, no defined end, and no appetite. Per the skill it must not plan the redesign directly. Instead it should either (a) narrow the request by asking for the specific story behind it — what is actually going wrong, when does someone's current workflow break down — and propose re-anchoring on one concrete problem (e.g., 'changing a notification preference takes eleven steps'), then set an appetite for that narrowed problem; or (b) route to product-discovery when the problem itself is unvalidated. It should explicitly name the grab-bag pattern and explain why planning a redesign without a specific problem produces unbounded work.",
      "assertions": [
        "Identifies the request as a grab-bag / unshaped idea rather than a plannable project",
        "Asks for or constructs a specific problem story (what breaks, for whom, when) instead of planning the redesign",
        "Sets or proposes an appetite as a time budget chosen up front, not an estimate of duration",
        "Does not produce a task list or milestone plan for the un-narrowed redesign",
        "Mentions routing to discovery when the underlying problem is unvalidated"
      ],
      "files": ["references/shaping.md"],
      "case_set": "regression"
    },
    {
      "id": "pitch-authoring-five-ingredients",
      "prompt": "We keep getting support tickets because customers can't tell which of our two billing plans they're on and what it includes. I think we should show plan status in the app. Write this up so we can decide whether to bet time on it.",
      "expected_output": "A pitch document following the skill's five ingredients: (1) Problem told as a specific story (customer contacts support because they cannot determine their plan), (2) Appetite stated as a chosen time budget (e.g., 'worth one small-batch box') with the reasoning that appetite is not an estimate, (3) Solution sketched as elements — places, affordances, connections — rough enough to leave implementation room but solved at the macro level, (4) Rabbit holes with decisions pre-made (e.g., what happens when a plan changes mid-cycle, where legacy plans render), and (5) No-gos explicitly fenced (e.g., no plan-comparison marketing page, no self-serve plan changes). The output should use or mirror the PITCH template structure and should NOT include a task breakdown or timeline estimate.",
      "assertions": [
        "Contains all five pitch ingredients: problem, appetite, solution, rabbit holes, no-gos",
        "Problem section tells a specific story rather than stating a category of complaint",
        "Appetite is framed as a budget decision ('how much is this worth') rather than an estimate ('this will take X')",
        "Solution stays at elements-and-connections fidelity without pixel-level or task-level detail",
        "Names at least one rabbit hole with a decision made in advance rather than deferred to the build team",
        "Includes explicit no-gos tied to the appetite"
      ],
      "files": ["templates/PITCH.md", "references/shaping.md"],
      "case_set": "dev"
    },
    {
      "id": "scope-map-and-hill-states",
      "prompt": "We're two weeks into a six-week project to add SSO to our product. The team has finished the login page redesign, mostly done the SAML wiring, and hasn't started figuring out how session handling works. Management keeps asking for percent complete. How should we report status?",
      "expected_output": "The agent should reject percent-complete and task-count reporting (lists grow as work is discovered; estimates hide uncertainty) and instead organize the work into scopes reported as hill states. Expected structure: scopes are integrated slices named by project language (e.g., 'SAML wiring', 'Session handling', 'Directory sync'), each placed at one of the four states (figuring out / validated / known / done). Session handling should sit at 'figuring out' — the uphill, riskiest scope — and the agent should recommend pushing it uphill first (validate the approach now) rather than finishing polished work first. It should explain that a scope parked at figuring-out is a raised hand, that 'validated' means approach proven on the hard part not finished, and that management reads motion across snapshots instead of asking the team for status. Nice-to-haves should be marked with ~ and understood as first cuts.",
      "assertions": [
        "Rejects percent-complete reporting with the reasoning that discovered work makes task counts and percentages misleading",
        "Organizes remaining work into scopes as independently finishable integrated slices with project-specific names",
        "Places each scope at one of the four hill states and treats session handling as uphill/figuring-out",
        "Recommends sequencing the riskiest scope first (push scary work uphill early)",
        "Explains validated as approach-proven rather than finished, and done as integrated end-to-end"
      ],
      "files": ["templates/SCOPE_MAP.md", "references/building.md"],
      "case_set": "dev"
    },
    {
      "id": "circuit-breaker-extension-decision",
      "prompt": "Our six-week project has one week left and roughly two weeks of work remaining. The team says everything left is essential. They're asking for a two-week extension. What do we do?",
      "expected_output": "The agent should apply the circuit breaker as the default: the bet was capped at six weeks, and by default an unfinshed project does not get extended — the cap is what makes it a bet rather than an open-ended commitment. It should walk the two narrow extension conditions from the skill and require BOTH: (1) every remaining task survived genuine scope hammering as a true must-have, and (2) all outstanding work is downhill with zero open questions — uphill work at the end means shaping missed something and extending buys time in the wrong place. It should prompt scope hammering first: which items could ship without? What actually happens if each is dropped? Compare down to baseline (is what exists already better than what customers have today?) rather than up to an ideal. It should note that if the breaker trips, the honest move is stop, ship what is green, and take the hole in the concept back to shaping for a possible future bet — not silently roll work over.",
      "assertions": [
        "States the circuit-breaker default: no extension by default when the box closes",
        "Requires both extension conditions (all must-haves survived hammering AND all remaining work downhill) rather than either",
        "Drives a scope-hammering interrogation of the 'essential' remaining work",
        "Uses baseline comparison (better than today) rather than ideal comparison to judge sufficiency",
        "Routes a tripped breaker back to shaping rather than recommending quiet rollover"
      ],
      "files": ["references/betting.md", "references/building.md"],
      "case_set": "release"
    },
    {
      "id": "hybrid-agent-bet-budget-and-kill-criteria",
      "prompt": "I want to delegate building a new CLI subcommand to our coding agent. It'll touch the parser, three modules, and needs integration tests. How should I scope and run this so it doesn't turn into an endless review loop?",
      "expected_output": "The agent should apply the hybrid-adaptation reference: define the appetite in ONE budget currency (work sessions, wall-clock, cost ceiling, or review-round allowance) stated up front in a pitch-like bound; batch steering into declared checkpoints (demo after the first integrated slice, midpoint check) instead of continuous mid-run course correction; include verification cost inside the scope (review time, expected fix rounds, mechanical checks preferred — tests/schema validation over line-by-line reading); draw scopes so each has a mechanically checkable done-state; and set kill criteria BEFORE starting: a round cap on fix/review iterations, a severity gate (stop when the worst finding class stops shrinking), a regression veto (a fix that introduces an equal-or-worse defect counts double), and fresh-context restart preference over iterating in a polluted context. It should note that a tripped loop routes back to reshaping, and that the first slice should be an integrated end-to-end demo, not parallel disconnected parts.",
      "assertions": [
        "Defines the appetite as an explicit budget in a single stated currency",
        "Prescribes batched steering at declared checkpoints rather than continuous mid-run intervention",
        "Includes verification/review cost inside the scope budget rather than treating it as free",
        "Sets explicit kill criteria: round cap, severity gate, and regression veto (fresh-context restart preferred)",
        "Routes a tripped loop back to shaping/reshaping rather than extending the cap mid-loop",
        "Calls for an integrated end-to-end slice first rather than parallel disconnected parts"
      ],
      "files": ["references/hybrid-adaptation.md"],
      "case_set": "release"
    },
    {
      "id": "unvalidated-problem-routes-to-discovery",
      "prompt": "Our competitors all have AI features now and our CEO wants us to build an AI assistant into the product. Nobody's actually asked for it but we don't want to fall behind. Where do we start?",
      "expected_output": "The agent should recognize that shaping is the wrong entry point: the problem is not validated — there is no evidence anyone has this need, and 'competitors have it' is a strategic-anxiety motivation, not a problem story. It should decline to shape or pitch the feature and route to product-discovery (find the actual user problem, if one exists) and/or frame the build/no-build question as a strategy decision for product-strategy. It may note what shaping WOULD do once a real problem surfaces: set an appetite and narrow to a specific use case. It should not produce a pitch, scope plan, or feature design for the unvalidated assistant.",
      "assertions": [
        "Recognizes the problem as unvalidated and does not begin shaping or pitching",
        "Explicitly routes to product-discovery for problem validation and/or product-strategy for the competitive question",
        "Explains the boundary: shaping narrows validated problems, discovery establishes whether the problem is real",
        "Does not produce feature designs, pitches, or build plans for the unvalidated request"
      ],
      "files": ["SKILL.md"],
      "case_set": "regression"
    }
  ]
}

# Anti-Patterns

Failure modes recorded in the field (independent teams, 2019–2026) and in agent
workflows (first-party practice plus published practitioner accounts). Method adapted
from Ryan Singer's *Shape Up* ([basecamp.com/shapeup](https://basecamp.com/shapeup));
this file exists because the book reports only its author's successes.

Provenance labels: **[independent]** = a named team's own account; **[first-party]** =
our own operating record; **[practitioner]** = credible published account from tooling
vendors or individual engineers.

## Field-recorded failure modes

**Appetite becomes a target. [independent]** A budget stated as "a three-week project"
invites work that expands to fill it — gold-plating inside the box. State appetites as
maximums tied to worth, and treat "under budget" as success, not slack to spend.
(Source: scalex.dev, "2 years with Shape Up" — Customaite.)

**Small-batch stuffing. [independent]** Teams whose natural work is smaller than the
cycle end up planning two months ahead to fill the bucket — losing reprioritization
flexibility without gaining single-project focus. If your work runs small, shorten the
box instead of force-fitting. (Same source.)

**Cool-down decay. [independent]** The uncommitted buffer between boxes degrades into a
parking lot: urgent spillover eats it, meetings migrate into it "to protect the cycle,"
and small fixes wait up to six weeks for it, losing context by arrival. Protect what
cool-down is for, or shrink the interval. (Same source.)

**Shaping as a separate-caste requirement. [independent]** The method presumes dedicated
shapers working ahead of builders. When one team must do both, either shaping starves or
building stalls; splitting into protected/unprotected teams just relocates the pain
(on-call imbalance, domain-switch whiplash). Mitigations seen in the field: rotating
"distraction shield" duty (Athos Commerce's Bug Hero rotation), or accepting shorter,
less-pure boxes. **[independent]**

**Circuit breaker quietly softened. [independent]** "We refused to delete code at the
end of a cycle if a project was not in a state to be shipped yet, so the deadline lost
its potency." Others consciously de-scope instead of canceling (Athos Commerce) — a
legitimate *declared* adaptation. The failure is silent erosion: keeping the vocabulary
of hard boxes while never letting one break. If you won't let the breaker trip, say so
and manage scope some other way. (Sources: scalex.dev; athoscommerce.com.)

**Betting-table theater. [independent]** Consensus-building re-litigated live at the
betting meeting wastes the meeting and produces worse bets. Desmos fixed it with
"pre-betting": stakeholders review pitches well before the table so the meeting decides.
(Source: engineering.desmos.com.)

**Low-fidelity orthodoxy. [independent]** Fat-marker-only pitches blocked Desmos's
engineers and stressed their designers; they moved concrete design INTO shaping and it
worked — for a small team of very experienced designers. Level of abstraction is a
judgment call tuned to your team, not a rule to enforce against evidence. (Same source.)

**Process instead of direction. [independent]** The sharpest abandonment lesson:
Customaite adopted Shape Up to manufacture focus while the real problem was missing
product direction. Once direction existed (North Star metrics), the heavy process became
a hindrance and they returned to sprints. Diagnose before installing process; no
methodology substitutes for knowing what matters. (Source: scalex.dev.)

**Backlog regrowth under other names. [independent/inference]** Bets-not-backlogs works
when decentralized lists stay personal. In practice they accrete into shadow backlogs —
support tallies nobody lobbies from, engineer bug lists nobody revisits. And "important
ideas come back" fails silently when the idea has no channel to return through: a single
requester with no way to re-raise, or a support firehose drowning the recurrence signal.
Keep recurrence observable (lightweight per-source counts) or accept that you are
choosing to lose ideas on purpose.

## Agent-workflow failure modes

**Unbounded review-fix loops. [first-party]** An automated reviewer finds issues, fixes
spawn new issues, each remediation invalidates prior verification evidence, and rounds
accumulate. Our record includes a nine-round marathon on a merged-anyway PR — with two
regressions introduced by rapid-fire fixes under review pressure. The cure is structural:
bound rounds up front (see references/hybrid-adaptation.md), stop when severity stops
improving, and document residue instead of chasing zero.

**Verification treated as free. [first-party]** Every fix round costs review attention,
CI time, and context rebuild — non-linearly, because a push resets evidence state.
Budget verification inside the appetite or the appetite is fiction.

**Integration deferred to hour eleven. [practitioner]** Agent builders happily produce
disconnected parts that don't assemble. The one-piece-done discipline (walking skeleton
early) is more valuable with agents, not less — integration is where conceptual gaps
surface. (Cursor's scaling-agents write-up documents the coordination failure modes of
structure-free agent fleets: lock contention, duplicated work, risk-averse churn.)

**Structure extremes. [practitioner]** Too little orchestration and agent teams conflict
and drift; too much and the system goes fragile — Cursor found an integrator role created
more bottlenecks than it resolved, and that "many improvements came from removing
complexity rather than adding it." Match orchestration weight to observed failure, not
to org-chart aesthetics. (Source: cursor.com/blog/scaling-agents.)

**Findings-driven infinite improvement. [first-party]** Machine-generated findings feed
on responses: address one batch, the generator produces the next. That is the mechanism
working, not the work converging. Change the mechanism (fix the generator's scope, pin
its version, narrow its domain) or bound the loop — never assume round N+1 converges
because round N felt productive.

## Reading this file correctly

None of these patterns argue against the method. Publicly documented adaptations and a
documented two-year abandonment-with-learnings are signs of a framework people can reason
about and leave — rarer than it sounds. The pattern to avoid is adopting the vocabulary
while silently dropping the enforcement (softened breakers, target-appetites, shadow
backlogs). Adapt declared, or follow faithfully; the failures live in the gap between.

# Betting

How shaped pitches become commitments — and how the commitment machinery keeps one
project from eating everything. Method from Ryan Singer's *Shape Up*
([basecamp.com/shapeup](https://basecamp.com/shapeup)).

## Bets, not backlogs

A backlog is a promise to re-read every old idea forever. The costs are real: grooming
time that produces nothing, ambient guilt proportional to list length, and stale items
that block attention from fresh ones. Shape Up replaces the backlog with a short list of
shaped pitches considered at each betting point — nothing else is on the table.

Two supporting moves:

- **Decentralized lists are fine.** Anyone can track ideas their own way (support's
  complaint tally, an engineer's bug list). What's banned is a *central* queue that
  feeds scheduling directly.
- **Important ideas come back.** If a request is real, it resurfaces — another
  customer hits it, the workaround gets more painful. If it never comes back, dropping
  it was correct.

Field-record caution: "come back" fails silently when there is no channel for the idea
to return through — a single requester with no way to re-raise, or requests arriving
through a firehose where genuinely important ones drown. If your intake is noisy,
keep lightweight per-source tallies so recurrence is observable; that preserves bets-
not-backlogs without pretending memory is free. See references/anti-patterns.md.

## The meaning of a bet

A bet is not a plan with better vocabulary. Three properties define it:

1. **Payout** — the pitch defines what exists at the end that doesn't exist now. A box
   full of tasks is not a bet; a shippable increment is.
2. **Commitment** — the team gets the whole box, uninterrupted. Pulling people out for
   side quests breaks the bet and destroys momentum, which compounds: lose an hour to
   context-switching and you lose most of a day regaining it.
3. **Capped downside** — if it doesn't ship inside the box, the default is stop, not
   extend. This is the circuit breaker: one project can never overload the system, and
   failure routes back to shaping (which mis-shaped it?) instead of deeper into the
   same hole.

Extensions are rare and require both conditions: every remaining item survived genuine
scope hammering as a true must-have, AND all outstanding work is downhill (no open
questions). Uphill work at the end of a box means shaping missed something — extending
just buys more time in the wrong place.

## Cycles are optional scaffolding

Basecamp runs six-week cycles with two-week cool-downs because at their scale the
rhythm standardizes capacity and forces trade-offs early. The cycle length itself is a
tunable parameter — shorter boxes cap downside harder but fragment meaningful work;
longer ones allow substance but let teams wander before the deadline feels real.

The basic truth underneath: commit in bounded units, only one unit ahead, keeping the
slate clean each time. Solo operators and small teams can run the loop fluidly — set an
appetite, shape, build, then shape the next thing — deliberately alternating the shaper
and builder hats. What does NOT flex well: interrupting committed work. If you cannot
protect a box from interruption at your scale, make boxes small enough that protection
is realistic (see references/hybrid-adaptation.md for agent-team sizing).

## Where bets get placed

At scale this is a betting-table meeting during cool-down: few well-shaped options,
short meeting, decisions made by people with authority to make them stick — no second
approval layer where bets go to die. The standing questions translate anywhere:

- Does the problem matter? (Weigh against other problems, not against zero.)
- Is the appetite right? ("How would you feel if it were half the size?" reveals
  whether the objection is really about time.)
- Is the solution attractive? (Watch for hidden real-estate or dependency costs.)
- Is this the right time? (Well-shaped and valuable still loses to badly-timed.)
- Are the right builders available?

Keep design and implementation debates out of the betting conversation; if it takes
more than moments, the pitch needs more shaping, not louder arguing.

## Product maturity changes the bet

- **Existing product:** normal flow — shape, bet, build, ship into the current system.
- **New product, R&D phase:** don't pretend to shape what nobody understands yet. Bet
  on spikes by senior builders; the goal is learning plus load-bearing architectural
  decisions, not shipping. Still one box at a time.
- **Production phase:** architecture settled, formal shaping resumes, shipping means
  merged-and-left-alone even before public launch.
- **Cleanup phase:** structure drops away deliberately near launch — unstructured
  must-have fixing, bounded to avoid becoming a way of life.

## Handling defects between bets

Bugs are not automatically interrupts. Three channels absorb them without breaking
bets: fix them in uncommitted time between boxes; bring genuinely large ones through
shaping and bet on them like anything else; and periodically dedicate a whole box to a
bug smash when debt accumulates. Reserve interrupts for actual crises — data loss,
everything broken — which are rare by definition.

# Building

How a team executes inside the box: own the whole project, integrate one slice early,
map discovered scopes, make uncertainty visible, and hammer scope until it fits.
Method from Ryan Singer's *Shape Up* ([basecamp.com/shapeup](https://basecamp.com/shapeup)).

## Hand over responsibility

Give the team the project, not tasks. Shredding the pitch into assigned tickets up
front loses the whole picture: each person executes their fragment without judging how
fragments fit, and planning done before real work begins is blind to what real work
reveals. The shaped pitch supplies direction and boundaries; the building team owns
task discovery, sequencing, and scope trade-offs within them.

This is not freedom to wander. The boundaries from shaping (appetite, elements,
no-gos) are guard rails; autonomy lives inside them.

**Kick-off reality check:** the first days look like nothing. People read code, poke at
the system, hit dead ends finding a starting point. That silence is legitimate work —
interrogating it too early pushes exploration underground instead of shortening it.

## Get one piece done

Do not build disconnected parts hoping they assemble in the final week. Pick one slice
that is **core** (central to the concept), **small** (days, not weeks), and preferably
**novel** (teaches something nobody knows yet) — and take it end-to-end first: working
interface wired to working behavior, demoable. A thin walking skeleton beats polished
fragments because it proves the concept while there is still time to react.

Supporting moves:

- **Affordances before polish.** Builders can start from stubs — plain buttons, plain
  fields, hard-coded data — long before visual design lands. First make it work; only
  then make it good-looking.
- **Program just enough for the next step.** Early backend work is strategically
  patchy: mock data where the point is UI judgment, hard-coded auth where the point is
  testing flows. Scaffolding is disposable by design.
- **Start in the middle.** Skip login pages and setup wizards; jump straight to the
  interesting problem and stub everything around it.
- **Designers don't block builders and vice versa.** With elements defined in the
  pitch, both ends work in parallel on the same slice and meet in the middle.

## Map the scopes

After the first integrated slice, organize remaining work by project structure, not by
role or person. A **scope** is an integrated slice of the project — bigger than a task,
smaller than the project — that can be finished independently in days. Scopes emerge
from doing real work: you cannot draw the map before walking some territory, so expect
the reliable map around end of week one and expect lines to move as interdependencies
reveal themselves.

Use [templates/SCOPE_MAP.md](../templates/SCOPE_MAP.md). Health checks:

- Right: you can see the whole project; scope names become the team's conversation
  language; new tasks have obvious buckets.
- Redraw when: "done" is undefinable for a scope (its tasks are unrelated), names would
  fit any project ("front-end", "bugs" = junk drawers), or a scope grows too big for
  near-term victory.

Shape patterns: most projects are **layer cakes** (UI + thin backend — judge by surface
area); watch for **icebergs** (small visible feature over massive hidden complexity)
and factor the mass into its own scopes so it can't hide. Keep a small **chowder**
list for genuinely homeless tasks; past three-to-five items, there's an undrawn scope.

## Show progress with the hill

Task counts lie in both directions: lists grow as work progresses (discovered tasks),
and an empty list can mean "done" or "nobody has looked yet." Estimates hide their own
uncertainty — four hours means nothing different for well-trodden work versus never-
done-before work that might take three days.

The hill chart fixes this by reporting unknowns instead of percentages. Each scope sits
at one point: **figuring out** (uphill, unknowns dominate) → **validated** (approach
proven on the hard part) → **known** (all downhill, execution only) → **done**. The
text-state table in the template replaces Basecamp's draggable chart; the semantics
carry. Second-order value comes from comparing snapshots: a dot that hasn't moved is
someone silently stuck, surfaced without anyone having to say "I'm stuck" out loud —
and the conversation becomes about the work ("what's keeping this uphill?") rather
than the person.

Two disciplines:

- **Earn the top.** Thinking you know the approach is the first third uphill;
  validating it is the second; being far enough into the build that surprises are
  unlikely is the top. Head-solved-but-never-touched work slides back down.
- **Solve in the right sequence.** Push the scariest scopes uphill first; leave routine
  work for last. If time runs out, you want the surprises behind you and only screw-
  tightening left — the inverted pyramid applied to risk.

## Decide when to stop

There is always more work than box. Shipping means shipping imperfect things, chosen
well:

- **Compare down to baseline, not up to ideal.** The question isn't "is this our best
  possible work?" but "is this clearly better than what customers have today?"
  Perfection has no finish line; better-than-baseline does.
- **Scope grows like grass** — not from bad people but from proximity. Every close look
  reveals improvements. Don't try to stop growth; constantly cut it.
- **Cutting scope is not lowering quality.** Being picky about what gets built at all
  differentiates the product; quality standards for what IS built stay high.
- **Scope hammering.** For every discovered addition ask: could we ship without this?
  What actually happens if we don't do it? Is it a new problem or one customers already
  live with? How likely is it, and who hits it? Must-haves go on the scope; everything
  else gets a `~` and is first against the wall when the box closes in. Marking the
  tilde IS the hammering.
- **QA is a level-up, not a gate.** Builders own basic quality of what they make; QA
  effort concentrates on edge cases late in the cycle, and its findings default to
  nice-to-haves that the team triages upward only if severity demands. Code review
  works the same way: valuable, welcome, and not a checkpoint that blocks shipping.

## Move on

Shipped features generate feedback storms — requests, complaints, "you ruined it."
Let the storm pass before reacting. Then handle input without taking on debt:

- Post-ship requests are raw ideas again. The gentle no ("interesting, maybe some day")
  keeps future options open; saying yes immediately is borrowing capacity you haven't
  budgeted.
- Anything that truly matters re-enters through shaping and competes at the next
  betting point like every other idea.

This closes the loop back to [references/shaping.md](shaping.md): feedback needs to be
shaped before it can be bet on.

# Hybrid Adaptation — Shaping for Human + AI-Agent Teams

The source book predates agentic development; its build teams were human designers and
programmers. This reference translates the method to work where builders are AI agents
(or mixed human/agent teams) and the human acts as shaper, bettor, and steering
oversight. The basic truths carry over intact; every specific practice gets re-derived.
Method base: Ryan Singer's *Shape Up* ([basecamp.com/shapeup](https://basecamp.com/shapeup)).

## Who plays which role

Shape Up's division of labor maps cleanly:

| Shape Up role | Hybrid equivalent |
|---|---|
| Shaper | Human (alone, or with an agent as sketchpad — never as decision-maker) |
| Betting table | The human accountable for the budget; optionally a structured debate (council-style) to stress-test competing pitches |
| Building team | One or more delegated agents with a defined verification path |
| QA / edge-case pass | Separate reviewer agent or human review, late in the box |

Shaping stays human because it is judgment: choosing what's worth an appetite and where
the fences go. Agents can draft breadboards or pitch text on request, but a pitch whose
appetite and no-gos were chosen by the same system that wants the work built has lost
the separation that makes betting meaningful. Keep the closed-door, private-sphere
property too: shaping in progress is not broadcast to stakeholders.

## Appetite in budget units

An agent team's appetite is still "how much are we willing to spend," but the unit is
yours to choose. Practical currencies, in increasing precision:

- **Work sessions** — "two agent sessions" (a session = one bounded delegation with its
  own context). Coarse but robust to model-price churn.
- **Wall-clock boxes** — "one working day of supervised run time." Good when latency
  matters (someone must be present to steer).
- **Cost ceilings** — token or dollar caps enforced by the harness. Most literal
  translation of appetite-as-budget, and the only one the machine can hard-stop on.
- **Review-round allowances** — caps on fix/review iterations, spent like money (see
  kill criteria below).

Pick ONE primary currency per bet and state it in the pitch. Mixed-currency appetites
produce disputes at exactly the moment clarity matters — when deciding whether the box
is spent.

## Uninterrupted time means batched steering

The commitment that builders get the whole box uninterrupted survives translation with
a twist: agents don't resent interruptions, but *you* pay for them. Every mid-run
course correction burns your attention and resets the agent's momentum; worse,
human steering injected mid-box tends to inject scope changes without appetite checks —
precisely the behavior fixed-time-variable-scope exists to prevent.

So: batch your oversight. Define checkpoints up front ("demo after the first integrated
slice", "hill-state update at box midpoint") and steer at those points rather than
continuously. Between checkpoints the running work is protected — including from you.
This is the same discipline Basecamp applies with cool-downs and self-serve hill charts:
status should be observable without being requested.

## Verification cost lives inside scope

With human teams, review was someone's job inside the cycle. With agent builders,
verification is often the dominant cost: reviewing generated output takes longer than
generating it, and every fix round re-spends that cost. An appetite that prices only
generation is fiction.

Practical rules:

- Budget the full loop: generation + your review + expected fix rounds. If you cannot
  afford the review, you cannot afford the bet — shrink the slice until you can.
- Prefer slices whose correctness can be checked mechanically (tests, type checks,
  linters, schema validation, rendered-output probes). Mechanical verification scales;
  reading every line does not.
- Treat evidence state as perishable: any push invalidates prior green results, so a
  fix round costs more than it looks. Price remediation rounds into the original
  appetite instead of discovering them later.

## Kill criteria for non-converging loops

The circuit breaker's hybrid form. Agent work fails differently from human work: the
characteristic failure is not slippage but non-convergence — loops that feed on their
own findings. Recorded first-party patterns, each of which ran nine-plus rounds before
being structurally stopped:

1. **Reviewer ping-pong.** Automated reviewer finds issues → fixes spawn new issues →
   re-review finds more. Two sub-signatures: severity stops improving across rounds,
   or fixes introduce regressions of their own (our record includes two regressions born
   of rapid-fire fixes under review pressure).
2. **Findings-driven improvement.** Machine-generated finding feeds produce the next
   finding forever. If each fix summons the next finding, the mechanism — not the work —
   is converging. Change the mechanism (narrow the generator's domain, pin its version,
   raise its threshold) or bound the loop; don't assume round N+1 converges.

Standing kill rules to adopt BEFORE betting:

- **Round cap.** A declared maximum number of fix/review rounds per bet (three is a
  sane default). Reaching the cap ends the loop: ship what's green, document residue,
  and route the remainder back through shaping if it still matters. Never extend the
  cap mid-loop — that is the breaker being softened (see references/anti-patterns.md).
- **Severity gate.** Stop when consecutive rounds stop reducing the highest-severity
  class of finding, regardless of round count.
- **Regression veto.** Any fix round that introduces a new defect of equal-or-worse
  severity than what it fixed counts double against the cap.
- **Fresh-context restart.** When a loop stalls, prefer restarting the slice in a clean
  context over iterating further in the polluted one. Cursor's scaling write-up reports
  the same discovery at fleet scale: periodic fresh starts combat drift better than
  pushing through.

Trip conditions route back to shaping, exactly like a human-team breaker trip: either
the concept had a rabbit hole nobody patched (re-shape it), or the problem was wrong
(route to discovery).

## Scoping slices for delegated builders

The building-side practices translate with emphasis shifted toward integration:

- **One piece done, early.** The walking-skeleton discipline matters MORE with agents:
  integration is where conceptual gaps surface, and cheap generation makes fragmented
  parts even more tempting than with humans. Demand a demoable end-to-end slice before
  breadth.
- **Affordances before polish, literally.** Stub interfaces and hard-coded data first;
  let the human judge flow before anyone invests in refinement that scope hammering may
  cut anyway.
- **Mechanically checkable scopes.** Draw scope lines so each one's "done" is verifiable
  by machine where possible — a test suite passing, a schema validating, a probe
  returning expected output. Ambiguous done-states invite both gold-plating and false
  completion claims.
- **Hill states in the tracking artifact.** Four text states per scope (figuring out /
  validated / known / done) in whatever board or file the team shares. A scope parked at
  "figuring out" across two checkpoints is the raised hand — investigate it at the next
  steering point instead of asking for status continuously.

## Earned autonomy

Grant delegation authority the way bets grant budgets: scoped, observed, and widened
only by demonstrated results. The pattern: start new agents, new domains, or new tools
with narrow appetites, mechanical verification, and tight caps; widen scope and raise
caps as slices ship cleanly. Authority earned this way is also revocable — a regression
pattern narrows autonomy back down without ceremony. Autonomy is priced into the bet,
not assumed as a standing permission.

## What does NOT translate

- **Six-week cadence.** With cheap generation, most useful bets fit in hours to days.
  Long boxes mainly add drift risk for agents and fatigue for the human steering them.
  Size boxes to the smallest unit that produces a demoable payout.
- **Team-size assumptions.** The book's designer+programmer pairs assume humans who
  need uninterrupted flow. Agent fleets need orchestration structure instead — but note
  the practitioner finding that structure extremes fail in BOTH directions; add roles
  only when observed failure demands them.
- **Cool-down as calendar.** Between-box slack becomes: clear stale branches and
  contexts, triage accumulated nice-to-haves honestly (most die here, correctly), and
  shape the next pitch. Shorter, more frequent, less ceremonial.

# Principles

The load-bearing ideas behind shaping. Everything else in this skill is an application
of these. Method adapted from Ryan Singer's *Shape Up* (Basecamp, 2019); the free web
edition lives at [basecamp.com/shapeup](https://basecamp.com/shapeup).

## Appetite is not an estimate

An estimate starts with a design and produces a number: "this will take five weeks."
An appetite starts with a number and produces a design: "this problem is worth two weeks
of one team — what solution fits inside that?"

The distinction matters because estimates masquerade as promises. Once a number exists,
everyone treats hitting it as the team's obligation, even though nobody controlled the
unknowns that inflate it. An appetite makes the time budget a *choice made up front*,
which flips the design question: instead of asking how long a full-featured version
takes, you ask which version of the solution is worth the budget. The best solution is
relative to constraints — there is no absolute "best" to estimate toward.

**Agent adaptation:** with delegated builders, the budget can be expressed in whatever
units your harness exposes — wall-clock days, work sessions, token or cost ceilings,
review-round allowances. What must survive translation is the direction of the
commitment: choose the budget first, shape the solution to fit it, and treat the budget
as fixed while scope stays variable.

## Fixed time, variable scope

Time is the one input you cannot flex without breaking trust; scope is the one input
you can always cut. Holding time fixed and letting scope vary forces every trade-off
into the open *while they are still cheap*. Letting scope stay fixed (the implied
promise of an estimate-driven plan) guarantees that quality or the deadline absorbs
every surprise at the worst possible moment.

This applies at each stage: the appetite constrains which solution gets shaped, and the
fixed box pushes the building team to decide what is core versus peripheral while there
is still time to act on the answer.

## Shaped work is rough, solved, and bounded

Work ready to bet on has three properties at once:

1. **Rough** — visibly unfinished, with open spaces where builders will exercise
   judgment. Detail added too early commits everyone to the wrong specifics and invites
   estimation errors: the more polished the artifact, the more hidden implementation
   complexity hides behind it.
2. **Solved** — the main elements exist at the macro level and connect. Open questions
   that could be resolved up front have been resolved; known rabbit holes are patched.
   Rough does not mean vague.
3. **Bounded** — it says where to stop. A stated appetite plus explicit no-gos tell the
   team what not to build.

Roughness without solved-ness is an unshaped idea. Solved-ness without boundedness is a
spec that will grow. Bets need all three.

## The right level of abstraction

Two failure modes bracket good shaping:

- **Too concrete** (wireframes, pixel mocks, detailed specs): over-specifies decisions
  that belong to the people doing the work, hides cost behind polish, and freezes scope
  so trade-offs become impossible.
- **Too abstract** (a phrase like "build a calendar view"): forces builders into
  mind-reading, leaves trade-offs undefined, and lets scope grow without boundary.

Shaped work sits between: concrete enough that anyone can see what the thing does,
abstract enough that the interesting decisions remain open for the team that owns them.

## Target the risk of not shipping

Shape Up optimizes for one specific risk: the risk of getting stuck — projects that
drag, pile up, and never ship. It deliberately does not address the risk of building
the wrong thing; discovery methods own that. Get clear-eyed about which risk a given
tool targets before reaching for it.

Risk reduction happens at three points:

| Stage | Mechanism |
|---|---|
| Before commitment | Shape: resolve visible unknowns and patch rabbit holes before anyone bets time |
| At commitment | Cap the downside: a fixed box means the most you can lose is the box |
| During the build | Integrate early: prove the concept end-to-end on one real slice instead of assembling disconnected parts at the end |

## Basic truths vs specific practices

Singer's appendix draws a line this skill preserves: some parts of the method are basic
truths (work needs shaping before commitment; commitments need capped downside; builds
need discovered structure), and some are practices tuned to Basecamp's scale in 2019
(six-week cycles, cool-downs, a formal betting table). Adopt the truths unconditionally;
treat the practices as defaults to adapt, not requirements to install. Solo operators
and small teams can run the whole loop fluidly by deliberately alternating the shaper
and builder hats — see references/betting.md and references/hybrid-adaptation.md.

## Evidence boundaries

Every practice claim in the source book is Basecamp-reported, from a company whose
product strategy and tooling business aligned with publishing the method. Independent
field evidence through 2026 is mixed-to-positive overall, with recurring failure modes:
shaping becoming a bottleneck when only senior people do it, circuit breakers quietly
turned into extensions, and backlogs regrowing under different names. Those findings,
with sources, live in references/anti-patterns.md — read it before betting anything
that matters. Treat this skill as a strong opinionated framework with documented failure
modes, not settled science.

## Lineage

The method's components have longer pedigrees than the book claims, which matters when
you borrow selectively:

- **Appetite/capped bets** echo flow economics: Don Reinertsen's *The Principles of
  Product Development Flow* (cost of delay, batch-size economics, treating development
  decisions as options with priced downside).
- **Get one piece done** is a walking skeleton (Alistair Cockburn) / tracer bullets
  (*The Pragmatic Programmer*): build the thinnest end-to-end slice first.
- **R&D mode spiking** descends from XP spikes.
- **Problem narrowing** (the calendar story) is demand-side interview craft — Bob Moesta
  and Chris Spiek are thanked in the book's acknowledgements; see references/shaping.md.

# Shaping

The pre-work that turns a raw idea into a bettable pitch: set boundaries, sketch the
solution's elements, patch the rabbit holes, write the pitch. Method from Ryan Singer's
*Shape Up* (free at [basecamp.com/shapeup](https://basecamp.com/shapeup)); problem-
narrowing craft owes its lineage to demand-side interviews (Moesta/Spiek, thanked in
the book).

## Step 1 — Set boundaries

Two decisions frame everything after:

**Set the appetite.** How much time is this idea worth? Two sizes cover most cases:
small batch (a fraction of a box, buildable alongside other small work) and big batch
(the whole box). If no version of the idea fits any appetite you'd pay, that is a real
answer — walk away and let it come back if it matters.

**Narrow the problem.** Take requests at face value and most are six-week projects.
Ask instead what is actually going wrong. The book's calendar story is the canonical
move: don't ask *why* do you want a feature (you'll get a feature list), ask *when*
the need occurred — what was happening when the status quo broke? That story converts
"do everything a calendar does" into "help me see free spaces," which is buildable.

Watch for grab-bags: "redesign X", "X 2.0", "clean up Y" have no defined start or end.
Re-anchor them on one specific problem ("sharing files takes eleven steps") or refuse
them as projects. A grab-bag routed here should either gain a specific problem or route
to product-discovery for proper investigation.

Default response to raw ideas: "Interesting. Maybe some day." A soft no keeps options
open without committing to work you don't understand yet. Ideas that matter come back;
see references/betting.md for why there is no backlog to forget them in.

## Step 2 — Find the elements

Sketch the solution at deliberately low fidelity so you can explore widely and leave
room for builders.

**Breadboarding (for flows).** Three primitives only: **places** (screens, pages,
states you navigate to), **affordances** (things acted on: buttons, fields, copy),
and **connection lines** (what leads where). Words and arrows, no visuals. The value:
writing out the flow provokes the real questions ("does enabling autopay also settle
the current invoice?") without anyone sinking hours into pixels that get thrown away.
Text form works fine:

```
[Invoice page]
  - "Turn on Autopay" button  --> [Setup Autopay]
[Setup Autopay]
  - card field, bank field
  - "Enable" button           --> [Confirmation + receipt]
```

**Fat-marker sketches (for visual problems).** When 2D arrangement IS the problem,
sketch with strokes too fat to permit detail. The constraint is the point: it keeps
the exploration at arrangement-level and makes premature polish physically difficult.
Annotate with words.

**Shaping non-UI work.** Most of what agents and platform teams build has no screen.
The equivalents translate directly:

| UI concept | Non-UI equivalent |
|---|---|
| Places | Components, services, data stores |
| Affordances | API endpoints, CLI verbs, events, contracts |
| Connection lines | Call graphs, data flows, event sequences |

A backend breadboard is a components-and-interfaces sketch: boxes for the pieces, named
arrows for contracts between them, deliberately silent on implementation internals. An
infrastructure change gets an interface sketch (who calls what, what changes for each
caller) plus explicit out-of-bounds lines. This is the same territory RFC/design-doc/
ADR culture covers before code; those documents are fine carriers for shaped output as
long as the fidelity stays at elements-and-connections.

**Output of step 2:** a short list of concrete elements. "A two-up month grid, dots for
events, agenda below that scrolls on tap" — narrow enough to bound the project, rough
enough that every downstream decision stays open.

## Step 3 — Address risks and rabbit holes

Slow down and attack your own sketch. Walk one use case through the solution in slow
motion and hunt for gaps. Then interrogate viability:

- Does this require technical work we've never done?
- Are we assuming parts fit together without evidence?
- Are we assuming someone can solve a design problem we haven't solved?
- Is there a hard decision better settled now than mid-box under deadline?

When a hole appears, choose: patch it by dictating the answer in the pitch (the book's
completed-to-dos example: keep legacy rendering, append group names — ugly but bounded),
declare the case out of bounds, or cut the element. De-risking trades elegance for
thin-tailed odds, and that is the correct trade when the box is fixed.

Present the sketch to people who know the code or the data before writing the pitch —
privately, framed as "something I'm shaping, not committed." Ask "is X possible within
this appetite?" never bare "is X possible?" Everything is possible; nothing is free.

## Step 4 — Write the pitch

Package the shaped concept using [templates/PITCH.md](../templates/PITCH.md): problem
(one story), appetite (budget + team shape), solution (elements at readable fidelity —
selectively more concrete than step 2 where readers must "see" it), rabbit holes (each
patch spelled out), no-gos (explicit fences). A pitch missing problem+appetite+solution
together is not ready: solution-without-problem invites design debates, problem-without-
solution pushes research onto the building team where the risk profile misaligns.

The pitch is the handoff artifact. At kick-off it becomes the team's whole context; a
reader with zero session history should be able to evaluate the bet from the document
alone.

## When not to shape

- The problem isn't validated → route to `product-discovery` first; shaping narrows
  validated problems, it doesn't discover them.
- The question is strategic (positioning, portfolio weight, whether to enter a market)
  → `product-strategy` owns that layer.
- The work is genuinely small, routine, and fully understood — shaping overhead exceeds
  its risk reduction. Just do it and note why no bet was needed.

# Pitch: <project or feature name>

> A pitch presents a shaped project as a potential bet. It is not a spec and not a task
> breakdown — those come later, if the bet is placed. Keep every element at the right
> level of abstraction: rough enough that builders have room, solved enough that they
> know what to do, bounded enough that they know where to stop.

| Ingredient | Content requirement |
|---|---|
| **1. Problem** | One specific story showing why the status quo fails. Not a category ("users want faster search") — a moment when a real person's workflow broke down. |
| **2. Appetite** | The time you want to spend, stated as a budget (e.g., "two weeks", "one six-week cycle", "one agent work session"). Never an estimate of how long it will take. |
| **3. Solution** | The core elements at breadboard fidelity: places, affordances, connections — or their non-UI equivalents. Enough for readers to "get" it; not so much that designers are boxed in. |
| **4. Rabbit holes** | Every known trap patched IN the pitch: the hard decision settled in advance, with reasoning. If the team will hit it under deadline pressure, settle it here. |
| **5. No-gos** | What this concept deliberately excludes to fit the appetite. Explicit fences prevent well-meaning scope growth. |

---

## 1. Problem

<The specific story. Who was doing what, what broke, what it cost them.>

## 2. Appetite

<Time budget + team shape. State which size: small batch (fits alongside other small
projects) or big batch (the whole box).>

## 3. Solution

<Elements list and/or sketch. For UI-shaped work: places, affordances, connection lines.
For non-UI work: components, contracts, data flows — see references/shaping.md.>

## 4. Rabbit holes

<Each patch: the hole, why it would derail the team, the decision made to close it.>

## 5. No-gos

<Explicitly excluded use cases, functionality, or polish. Each no-go should name the
appetite reason it exists.>

## Nice-to-haves (optional)

<Genuinely optional items, marked `~`. These are first against the wall if the box
closes in — listing them here is not a commitment to build them.>

# Scope Map: <project name>

> Scopes are integrated slices of a project — bigger than tasks, small enough to finish
> in days — that can be completed independently. They are discovered by doing real work,
> not planned up front. Expect the first reliable map around the end of week one;
> expect early shuffling. Redrawing lines as you learn the territory is the technique
> working, not failing.

| Field | Value |
|---|---|
| Pitch | <link or reference> |
| Team | <who is building> |
| Time box | <appetite from the pitch> |
| Map last updated | <date> |

## Hill states

Each scope sits at one of four points. Move honestly — a dot that doesn't move is how
stuck work raises its hand without anyone having to say "I'm stuck."

| State | Meaning |
|---|---|
| **Figuring out** | Approach unclear; unknowns dominate; nothing validated yet |
| **Validated** | Approach chosen and proven feasible on the hard part — de-risked, not finished |
| **Known** | All unknowns resolved; only execution remains (all downhill) |
| **Done** | Integrated end-to-end; must-haves complete; demoable |

Sequencing rule: push the scariest scopes uphill first. Get novel, risky work to
*Validated* early and leave routine polish for the end.

## Scope table

| # | Scope | Must-haves | Nice-to-haves (`~`) | Hill state | Notes |
|---|---|---|---|---|---|
| 1 | <named by project language, e.g. "Invite clients"> | <tasks that define done> | `~`<optional items> | Figuring out | <interdependencies, blockers> |
| 2 | | | | | |
| 3 | | | | | |

**Is the map right?** Check the three health signals:

- You can see the whole project — nothing worrying hides in the details
- Conversations flow because scope names are the project's real language
- New discovered tasks have an obvious bucket to land in

And the three redraw signals:

- You can't say how "done" a scope is → its tasks are unrelated; factor something out
- The name would fit any project ("front-end", "bugs", "misc") → junk drawer; integrate
- It's too big to finish soon → split until victories arrive every few days

## Chowder

Loose tasks that fit nowhere yet. Honest holding pen, not a junk drawer — if it grows
past three to five items, there is a scope waiting to be drawn.

- <task>

## Nice-to-have discipline

Any task marked `~` is cut automatically if the box closes in. Marking the tilde IS the
scope-hammering act: the team decides, in the moment of discovery, what the fixed time
box can afford. Usually nice-to-haves never get built, and that is the system working.

## Circuit breaker check

Before asking for more time, verify both conditions — and even then prefer shipping:

- [ ] Every remaining item survived genuine hammering as a true must-have
- [ ] All outstanding work is downhill (no open questions anywhere)

If either box is unchecked, the honest move is to stop, let the breaker trip, and take
the hole in the concept back to shaping.