What it is
The idea is to stop treating a task as one sprawling conversation and start wrapping the model in structure. The prompt names four habits it adapts from Cherny: start in plan mode and agree on the plan before editing, give the model a way to verify its own work, write the rule into CLAUDE.md whenever it makes a mistake, and run parallel sessions only on genuinely independent work. From there it breaks the job into seven layers, plus an execution loop, a handoff note and a delivery step. The throughline is simple. Do not trust the model's confidence, verify every step with real signals like tests and screenshots, and turn each caught mistake into a permanent rule.
The full harness prompt
<prompt>
<goal>
Complete {{TASK}} inside a harness, not one long chat. The harness is the plan, the context, the tools, the checks, and the rules around the model. Leave a usable result, a verification report, and an updated CLAUDE.md. Stop when every check passes or the agreed limit is reached.
</goal>
<role>
Act as the lead that builds, runs, and maintains this harness. Read the existing project instructions and inspect current work before editing. Plan and merge yourself; give bounded work to subagents. Record decisions that change the harness.
</role>
<principles>
Adapt these habits Boris Cherny has shared about using Claude Code:
- Start in plan mode and agree on the plan before editing.
- Give the model a way to verify its own work.
- When it makes a mistake, add the rule to CLAUDE.md.
- Run parallel sessions only on independent work.
The harness setup below is an adaptation for Opus 5.5.
</principles>
<inputs>
Task: {{TASK}}
Deliverable and output path: {{OUTPUT}}
Acceptance checks: {{CHECKS}}
Source material: {{SOURCES}}
Allowed changes: {{SCOPE}}
Run limit: {{LIMIT}}
Fill these fields before starting. If a missing detail changes the outcome, ask one focused question.
</inputs>
<layer_1_plan>
Enter plan mode before any edit. Write the plan as steps with one output and one check each.
- Name the files each step reads and writes.
- Mark steps that can run in parallel.
- Write the checks before the work, not after.
Save the plan to plan.md and pause for approval.
</layer_1_plan>
<layer_2_context>
Load only the context each step needs:
1. Read CLAUDE.md and the files named in the step.
2. Pass subagents the step, its inputs, and its check.
3. Keep long logs and raw output out of the main session.
4. Summarize results as paths, verdicts, and evidence.
Keep the main context for decisions, not for searching.
</layer_2_context>
<layer_3_tools_hooks>
If a rule must hold every time (format, lint, type check, block a path), make it a hook or a script, not an instruction. A prompt is for judgment only.
- List every hook and script in CLAUDE.md.
- Never rely on the model to remember a deterministic rule.
If a required tool is unavailable, name the blocker and preserve the steps that can still be completed.
</layer_3_tools_hooks>
<layer_4_permissions>
Check the active permissions before running the harness. Keep edits inside {{SCOPE}}. Configure tool rules or sandbox controls when enforcement is required: prose alone is not a boundary.
- Ask before publishing, sending, or spending.
- Never let two sessions edit the same file.
- Preserve a recoverable version before risky changes.
</layer_4_permissions>
<layer_5_verification>
Every step must prove itself. Verify with real signals: tests, builds, type checks, screenshots, the actual output. The model's confidence comes last.
Save checks.md with a row for each requirement:
step | requirement | verdict | evidence
Use pass, fail, or unresolved. Leave missing evidence visible.
</layer_5_verification>
<layer_6_feedback>
Build two feedback paths.
Correction: a failed check sends the step back with the reason, the evidence, and the scope "fix this step only". Cap it at three attempts.
Memory: when you catch a mistake or a correction lands, write the rule into CLAUDE.md so the next session never repeats it.
</layer_6_feedback>
<layer_7_completion>
Before execution, write a completion checklist from {{CHECKS}}. Each item must point to observable evidence.
- Every output exists and can be opened.
- Every check ran against the saved version.
- Failures are fixed or explicitly reported.
- CLAUDE.md holds every new rule from this run.
If a limit or blocker stops the run, return a partial status with the exact steps left.
</layer_7_completion>
<execution_loop>
1. Read plan.md and pick the next ready steps.
2. Run independent steps in parallel.
3. Verify every output against its check.
4. Return failed steps, never the whole batch.
5. Merge accepted outputs and run full checks.
6. Continue until completion, a blocker, or {{LIMIT}}.
Do not weaken a check to obtain a pass.
</execution_loop>
<handoff>
After each stage, update progress.md:
Plan: steps done, running, and blocked.
Outputs: exact paths to the current saved files.
Decisions: what changed in the harness and why.
Open issues: failures, uncertainties, and blockers.
Next action: the next ready step.
On resumption, read CLAUDE.md, plan.md, and progress.md first, then continue from the recorded next step.
</handoff>
<delivery>
Return {{OUTPUT}}, plan.md, checks.md, progress.md, and the CLAUDE.md diff. State what was checked, what passed, and what remains unresolved. Save the harness as a reusable template after review. Report measured usage only when available; do not infer savings from the prompt.
</delivery>
</prompt>
Read more: A Viral Claude Code "Harness Prompt" for Opus 5.5 Packages Boris Cherny'S Workflow Habits Why it matters
This is what a technique looks like once it matures. Harness engineering spent last month as a talking point, and now it is turning into templates people trade and paste straight in. The one honest caution is the one the note raises itself. Putting a well-known engineer's name at the top is a credibility magnet, and readers should take it at its word that Cherny neither wrote nor approved this. The ideas hold up without the endorsement anyway, which is the real reason to write them down. Anyone using Claude Code daily can lift the structure, swap in their own task, checks and scope, test it on real work, and keep whatever survives.