/break

name: break
description: Try to break a change the way the real world will - network faults, restarts, two things at once, users doing things out of order - on a disposable local stack, and report what broke with a reproduction.

/break

`/verify` asks "does the change do what the plan said?". This skill asks the opposite: "how does this change fail once it meets real networks, real users and the other services around it?". Run it after `/verify` passes, on the same local stack.

It is not a unit test hunt. Empty strings, unicode and wrong types belong in unit tests, unless a real producer sends them: a model filling in tool arguments is one, so an empty or odd-but-valid value it writes is in scope here. The bugs this skill looks for only exist when the whole system is running:

• **Network and infrastructure:** a dependency that is slow, refuses connections or

hangs; a reply lost after the side effect happened; a process killed or restarted mid-job.

• **Users:** double-clicking, two tabs, going back, refreshing mid-flow, leaving and

coming back after something changed.

• **Services interacting:** two workers, or a background job running at the same

moment as a request, events arriving twice or out of order, old and new versions running together, state changed by someone else between two steps.

Hard rules

• Never fix what you break. Report only.
• Only the disposable local stack. Never inject faults into a shared, staging or

production system.

• Use local stubs for model and paid-provider calls. Real paid calls happen only if the

charter lists them with their cost and the user approves.

• A stub accepts whatever you send, so it cannot tell you the real provider would refuse

the request. When the change alters what is sent to an outside service (a schema, a tool definition, a new field), check the request against the provider's real rules wherever that is free: a token-counting or validation endpoint, a dry-run mode, the provider's published schema. That is not a paid call.

• A finding is something you **made happen on the running system**. Something you

can only argue from reading code is a *suspicion*: list it separately, with what it would take to demonstrate.

• Every finding reproduces twice before it is reported.
• A failure in your own harness is not a finding. If the fault you injected also broke

the thing you use to observe, say so and fix the harness, not the verdict.

Before you start

Reuse `/verify`'s setup: `.verify/setup.json`, the environment scripts and the run marker. Boot with `env.sh up`, seed with `env.sh seed`, and arm `env.sh down` on every exit path, exactly as `/verify` half two does. If there is no setup contract, stop and ask for `/verify-setup`.

Create a run directory: `.verify/breaks/<YYYYMMDD-HHMMSS>/`. Everything you write goes there.

Find the plan the same way `/verify` does. Then read the diff and the code around it. Unlike `/verify`, this skill must read code: the plan says what should happen, and only the code shows where it can fail (what calls the changed code, what it trusts, where it gives up). Code is for **aiming**. Judging still comes from the running system.

Read the app profile

`/verify-setup` writes `.verify/profile.json`: the app's services, background actors, status transitions, outside services, behaviour-changing config and the chain in front of production. Check it first:

VERIFY_PIPELINE="${VERIFY_PIPELINE:-$CLAUDE_PLUGIN_ROOT/pipeline}"
(cd "$VERIFY_PIPELINE" && npx --no-install tsx src/cli.ts profile-check --repo "$(pwd -P)")

If the file is missing or the check fails (the code has moved on), rebuild it before anything else by following section 7 of the `/verify-setup` skill; it takes a few minutes and asks at most one question. If the rebuild fails, carry on without a profile and say so in the report.

Use only the slice that matters for this change: the actors and transitions that touch the changed files or the tables they write, the outside services the change calls, and the edge chain. Open each cited line you rely on and drop any entry the code no longer supports. Entries are leads, not proof: a missing entry never means nothing else does this.

Reaching the state under test

The repo's seed usually creates tenants, not the mid-flight state you want to attack. Getting there is most of the work, so do it cheaply:

• Use the product's own test doubles first: local sandbox, fake providers, stub servers.
• Point model and provider clients at a local stub you control when the attack is about

how the system handles their answers (invalid, truncated, refused, slow, hanging). It costs nothing and lets you choose the bad answer.

• When an upstream stage is expensive (a real agent run, a paid pipeline), you may seed

its output with SQL, writing the same rows the real code writes. Say so in the report.

• Give each attack its own project or tenant, so one attack's leftovers do not change

the next one's outcome.

If the setup contract is missing something the stack needs (an env var, an image that will not pull), work around it and list it under **Setup gaps** in the report.

1. Map the seams

A seam is anywhere the change hands work or state to something else. Write `seams.md` with one short entry per seam:

• **Actors** that touch the changed state: API handlers, workers, the reaper or lease

expiry, sweepers, schedulers, boot-time migrations, webhooks, the browser, external services. Include background actors the diff did not touch but that read or write the same rows. They are where the collisions come from.

• **State** each actor reads or writes, named as tables, keys, files or messages.
• **Moments between steps**: for each changed write, find its transaction boundary

and every actor that can read or change the same state before the next write. After a commit and before a reply, between two transactions, between a claim and a completion, between a f