Break

/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 freeze and a publish. Write down the exact interleaving you would force ("write A commits, then another actor changes the same row, then write B runs") and what each actor should do. These interleavings are your best attacks.

Other producers

A fresh stack holds only what the happy path wrote. Real systems hold what everyone produced. Find the data the change consumes from the diff, not only from the plan: for every function, check or query the change edits, list what already flowed through it on the base commit. A change aimed at a new kind of item often edits code the older kinds still pass through, and the plan will not mention them. A path through code the change edited is never out of scope, whatever the plan is about. For each piece of data the change consumes (rows, messages, files, headers, payloads, config, URLs, anything it parses):

1. List the producers. Older versions of this code, other services and background jobs, people (manual fixes, imports, admin tools), outside systems (webhooks, SDKs, browsers, build tools), and failures (a write cut short, a retry, a duplicate delivery, a crash between two writes).
2. List the shapes each producer could leave. Ask for an exhaustive list with a source for each item (a tool and version, a doc, a named failure), never for "some sample data": samples cluster on the common case and miss the shape that breaks things. Include at least one shape that contradicts the plan's own examples.
3. Produce each shape the cheapest honest way. Run the real producer when you can (the base commit, the provider's CLI, a real build tool, a recorded browser session). Otherwise write the shape directly (SQL, a crafted request) and say so.

For your own infrastructure (the proxy in front, the deployed config), test the path the profile names first. For inputs that vary by customer (their build tools, SDK versions, proxies), try the few most common variants and name the ones you skipped.

Skip this for data the change does not consume. Run the attacks on top of this data, and do restart and deploy attacks after it is loaded. Put the producers you covered, and the ones you could not, in the charter.

Other consumers

For each piece of data the change produces or changes the meaning of (a row, a stored payload, a message, a status), find everything else that reads it: other endpoints, tools, notifiers, the UI, reports, and older versions still running during a deploy. When the data ends up in a prompt, the model is a consumer too: check what the prompt tells it, not only what is stored. Trace them in the code now, for this change; do not rely on a list from the profile. After each attack, read the data through every consumer and check they agree on what it means (whether it exists, what it holds, what state it is in), even if they show it differently.

If the map is empty (no second actor, no gap in time, no outside call touches the changed state), say so and stop. There is nothing for this skill to attack. A change to copy, styling or docs usually ends here.

2. Write the charter, then stop

Which attacks apply

Choose from what the change does. The categories are generic; turn each into concrete cases for this app from the profile and the diff.

When the plan states a goal ("no customer is charged twice") as well as a mechanism ("a lock around the charge call"), test the goal. Inputs the mechanism did not foresee are where it fails.

Starting states

Run each attack from the starting states that apply, not only the clean default:

• retries: first attempt, and the last attempt before the job gives up
• concurrency: one run, and another run of the same thing already in progress
• data age: fresh, and data left behind by older versions or crashed runs
• config: filled in, and default or missing

Name the concrete state in the charter ("fix job at attempt 2 of 3"), and how you reached it.

Check a guard before building on it

When the profile, the plan or your own reading says a write has no guard, open the code and confirm it before planning an attack around it. Reading gets these wrong.

Hypotheses

Pick hypotheses from the attack list below. Each one reads:

If <fault> happens during <moment>, then after the system settles, <settled-state rule> still holds.

Rank them by how bad the worst outcome would be for a real user. Run the two or three highest-risk interleavings from section 1 first, then the rest as time and budget allow. Write charter.md with the hypotheses, the settled-state rules (section 3), the stack you will use, and a rough time estimate. List every attack from the list below that you considered and skipped, each with a one-line reason ("no second actor writes this row"). Scale the effort to the change: a single-flow change gets two or three attacks, a change to background jobs gets the full list. Show it to the user and stop until they say go.

The attack list

1. Poison item. One input that always fails, however many times it is retried. Count retries and spend, and check whether the work around it still finishes.
2. Lose the reply after the side effect. Let the write commit, then kill the process or drop the response before the caller hears back. Re-run, retry or redeliver. Count results: exactly one.
3. Real network faults, not clean errors. Point a dependency at a closed port, make it hang (docker pause), make it slow. A clean HTTP 500 is the easy case; hangs and refused connections are where the bugs are.
4. Two at once. Two actors on the same state at the same moment: two workers, a background job and a request, two tabs, a double-click, two users on one record.
5. Restart or deploy mid-flight. Restart the services the change touches while work is in progress. Boot-time migrations and sweepers run again. Run the old and new versions side by side where a deploy would.
6. Change state between two steps. Between the moments from section 1, let another actor act: a person clicks a button, a sweeper runs, retention deletes, an external service changes its mind.
7. Crash at every commit point. For each database write in the changed flow (from section 1), kill the process right after that write commits, restart, and check the rules. One commit point per attempt.
8. Prod parity. Compare the env vars and default hosts the change needs against what the deployed config provides. Put the profile's edge chain in front (a local proxy standing in for each hop) where the change handles requests.