FIELD TOOL / PM-TO-PROD AGENT BRIEF

A PM asking Claude Code to ship needs a packet, not a pep talk.

Use this when a product person is learning Claude Code, Codex, or another coding agent and the ask is still mushy: “help me ship”, “fix the demo”, “deploy this”. The packet turns the ask into repo state, target deploy, failing command, proof check, rollback, and the exact line where a human decision is required.

The danger is not that a PM uses an agent. The danger is an agent working without a finish line.

Claude Code can move fast for a PM if the brief is narrow enough to verify. If the brief says “make it work”, the agent will invent the finish line and call the nearest green check a win.

repo_state says what exists before edits.
target_ship says the visible user outcome, not the internal task.
proof_command says how the PM knows the work landed.
human_boundary says what the agent must not decide alone.

Rule: no Claude Code shipping session starts until the PM can name one command, URL, screenshot, or record count that would fail before the work and pass after.

Copyable PM shipping packet

Before asking Claude Code/Codex to ship, fill this packet.

1. ROLE AND BOUNDARY
- I am the PM / owner for this task.
- The agent may edit:
- The agent may not edit:
- The agent must ask before: credentials, paid services, deleting data, changing auth, changing billing, legal terms, production deploy.

2. REPO STATE
- repo/path:
- branch:
- last known good commit or timestamp:
- install command:
- run command:
- test/lint command:
- deploy target:

3. TARGET SHIP
Describe the user-visible outcome in one sentence:

Example: "A logged-in user can export the report CSV from /reports and the file contains columns A, B, C."

4. CURRENT FAILURE
- What happens now:
- Smallest repro step:
- Error/log/screenshot path:
- Bad input, if any:
- Expected output:

5. ACCEPTANCE PROOF
The agent is not done until this passes after the last edit:
- command / URL / manual check:
- expected observed result:
- negative check that would fail if nothing changed:

6. ROLLBACK PLAN
- file(s) most likely touched:
- safe rollback command or restore point:
- data migration risk: none / low / unknown / high

7. STOP CONTRACT
The agent must stop and report STUCK if:
- it cannot reproduce the failure;
- the proof command is missing;
- a secret or paid account is needed;
- the fix changes product scope;
- two repair attempts fail the same acceptance proof.

8. FINAL RECEIPT FORMAT
Return:
- files changed;
- exact proof command/check run;
- observed result;
- remaining unknowns;
- rollback note;
- next human decision, if any.

Pair with localhost → live Need a scoped fix?

Start with what the PM can see.

Name the page, record, file, email, or deployed behavior. Internal agent tasks are not acceptance criteria.

Freeze the repo state.

Branch, run command, and last known good point matter more than the model choice once the session goes sideways.

Make one failure reproducible.

If there is no repro step, the first job is diagnostic. Do not let the agent skip straight to patches.

Require a negative check.

A green test proves more when you also know what would still fail if the work had not landed.

Separate scope from implementation.

A PM can decide the desired behavior. The agent can propose implementation. Do not let it silently change the product.

Keep humans for irreversible moves.

Credentials, billing, production data, legal terms, and destructive deploys are not agent taste calls.