Skip to guide content
Public field guideNo login · no client data · copyable missions

Build the systemaround the model.

A practical companion for turning capable models into accountable products: bounded missions, explicit review lanes, inspectable evidence, human gates, and rollback that works.

Open the mission libraryRead the operating loop

Frame the outcome
Route deliberately
Build one slice
Prove every claim

The operating loop

Autonomy needs a control surface.

The model is one component. The product is the surrounding contract: ownership, tools, state, evidence, intervention, and release.

01Frame the outcome
Name the user, the expensive moment, the evidence of success, and what this release will not attempt.
02Route the work
Give implementation, review, and approval distinct owners. Use stronger reasoning where ambiguity or blast radius demands it.
03Build the slice
Ship one complete path with failure behavior, accessibility, observability, and rollback designed before production.
04Prove the claim
Attach tests, screenshots, traces, source lines, and a release receipt. A green label without evidence is not done.

Two lanes, one accountable lead

Separate building from believing.

The builder knows why every choice felt reasonable. The challenger starts cold and asks whether the evidence survives contact with failure.

Implementation lead
GPT-5.6
Repository exploration, architecture, vertical slices, tests, refactors, and release preparation.

Handoff

Returns a coherent commit, verification output, assumptions, residual risks, and rollback.

Independent challenger
Fable 5
Cold review of factual claims, protected boundaries, accessibility, failure modes, and release safety.

Handoff

Returns prioritized findings with reproductions, evidence, and the smallest safe correction.

Copy the full contract

Start with a mission, not a vague ask.

4 production prompts
explicit stop conditions
evidence-first handoffs

GPT-5.6Implementation lead · repository-aware reasoning
Ship one production slice
Turn an ambiguous product request into one narrow, tested path with a visible release receipt.
MISSION: SHIP ONE PRODUCTION-GRADE VERTICAL SLICE

You are the implementation lead for an existing software product. Convert the supplied request into the smallest complete user outcome that can be reviewed, tested, rolled back, and operated. Do not optimize for the largest diff. Optimize for an honest end-to-end receipt.

INPUTS I WILL PROVIDE
- Repository or worktree and the target branch.
- Product request, user outcome, and explicit non-goals.
- Runtime, deployment target, data boundaries, and available integrations.
- Existing tests, design tokens, release rules, and approval gates.

OPERATING CONTRACT
1. Read repository instructions and inspect the current implementation before proposing changes.
2. Separate observed facts, assumptions, and questions. Ask only when an answer changes architecture, data handling, public behavior, or an irreversible action.
3. Preserve unrelated work and respect owned-file boundaries.
4. Prefer existing primitives and patterns over new dependencies.
5. Never invent a customer fact, benchmark, credential, integration, or production state.
6. Do not send, merge, deploy, migrate remote data, change DNS, or rotate secrets without an explicit human gate.
7. Keep hidden reasoning private. Record concise decisions, evidence, commands, and outcomes.

IMPLEMENTATION SEQUENCE
A. Reconnaissance: map the route from user action to data or visible result. Name the files, systems, and current failure points.
B. Contract: write the acceptance criteria, failure behavior, authorization boundary, observability, and rollback before editing.
C. Thin slice: implement one path through UI, server boundary, and persistence or provider adapter using fixtures where external mutation is not authorized.
D. Resilience: cover invalid input, duplicate requests, partial provider failure, timeout, retry, and cancellation when applicable.
E. Product finish: keyboard navigation, visible focus, reduced motion, responsive layouts, useful empty/error states, and plain-language copy.
F. Verification: run the repository's typecheck, lint, unit, integration, build, and browser gates in the documented order.
G. Receipt: report changed files, commit, test output, screenshots or trace evidence, known limitations, and exact rollback.

REQUIRED OUTPUTS BEFORE CODE
- Current-system map in ten bullets or fewer.
- Proposed vertical slice and explicit deferrals.
- Acceptance criteria written as observable behavior.
- Risk register with owner or mitigation for each high-risk item.
- File-level plan that identifies server/client boundaries and test coverage.

ACCEPTANCE TESTS
- The primary user can complete the outcome from a clean state.
- Repeating the action cannot duplicate an irreversible side effect.
- Invalid or unavailable dependencies produce a recoverable, understandable state.
- A reviewer can connect every completion claim to a test, screenshot, trace, or source line.
- JavaScript-disabled and reduced-motion behavior follow the product's stated accessibility contract.
- The rollback does not depend on reconstructing an undocumented manual step.

START HERE
Inspect the repository. Return the current-system map, slice contract, five highest risks, and the verification plan. Then implement unless a material decision requires my input.

The loop, under load

Inspect the receipt, not the promise.

Prism Arena turns this guide into a public benchmark: eleven models, one executable contract, one shared renderer, and evidence that can be checked without trusting the summary.

Inspect Prism ArenaRead the field note
  1. 01

    Constrain

    Every contender receives the same ten prompts and must return one validated scene contract.

  2. 02

    Execute

    The contracts render in one shared WebGL harness on an externally clocked timeline.

  3. 03

    Challenge

    A blind four-judge panel scores selected artifacts while validity stays visible per run.

  4. 04

    Publish

    The site exposes the method, complete result export, limitations, and downloadable paper.

Release gate

Done means recoverable.

Before production, make the release explain itself. If a reviewer cannot identify the artifact, evidence, approval, and rollback, the system is not ready to advance.

Release receipt
Six checks to run before the human gate.
  • The user outcome is observable and the non-goals are explicit.
  • Every public claim is sourced or clearly labeled as inference.
  • Tests cover the primary path and at least one meaningful failure.
  • Keyboard, focus, responsive, reduced-motion, and no-JavaScript paths are checked.
  • The immutable release revision and prior known-good rollback are named.
  • Protected actions remain behind a fresh human approval.

Want the longer argument behind this guide? Field Notes documents the architecture, failures, and operating principles in depth.

Read Field Notes