Turn a Development Harness into Durable Operating Rules

Format

Markdown

Inputs

AIDevelopmentHarness (document, code, text) · Required

Outputs

HarnessRulesAndFiles (document, text) ChangeSummary (text, document)

This is my only opportunity to use Fable 5. After this session, my environment will be operated long-term by smaller models such as Sonnet, Opus, and Haiku. Your sole task is to convert your judgment into durable rules and files so that every future session with a less capable model is more effective. Use this session to establish the operating system; do not spend it on routine tasks.

## Operating rules — read all of these before acting

1. **Work autonomously.** Inspect what the environment makes available, including `CLAUDE.md`, subagents, model and effort settings, MCP, skills, and memory mechanisms. You may ask me one batch of questions at the start, with no more than five questions. After that, do not pause to wait for me.
2. **Prioritize value and write as you go.** Do the highest-value work first. As soon as each deliverable is complete, write it to disk before beginning the next. The session may be interrupted at any time; the files already written are all I may receive.
3. **Protect existing files.** Before changing any existing file, save a backup copy. Put substantial new material in new files. Keep `CLAUDE.md` concise and use it to route readers to those files.
4. **Write for weaker models.** You do not need step-by-step directions for yourself, but rules written for future models must be concrete, executable, and include decision criteria and examples. Abstract requests such as “maintain high quality” are not useful unless operationalized.
5. **Keep the system runnable on Sonnet-level capability.** Do not make deliverables depend on abilities only you have.
6. **Use the highest effort setting the environment permits.** Long runs are acceptable.

## Deliverables — work in this order

### A. Rapid diagnosis
Identify the three biggest current harness problems that waste tokens, cause loss of focus, or lead to errors. For each, give a specific remedy. Write this first so later deliverables can refer to it.

### B. Rewrite `CLAUDE.md`
Treat this as the highest-leverage file because it will be loaded in every future session. Consolidate duplicate rules, remove obsolete material, and move lengthy guidance into linked files. Write for a weaker model that needs explicit direction while leaving capable models room to exercise judgment.

### C. Model-routing rules — a separate file
Document these rules:
- The commander does not do bulk work directly: delegate large-scale reading, repository scans, web research, and batch file edits to subagents. The main conversation should receive conclusions, not raw work products.
- Every delegation includes three parts: objective and rationale, acceptance criteria, and required report format.
- Explicitly specify the model and effort level, using only models actually available in this environment; inspect availability rather than guessing.
- Subagent reports contain conclusions and file-and-line references. Long outputs should be saved to a file and reported by path.
- Escalation and de-escalation: if a small model makes an error once, move the task up to a stronger model. If a mid-tier model makes the same subtask error twice, escalate with the complete failure history. Once a successful approach is established, move it back to a cheaper model for batch application. Retry the same thing no more than twice.
- Do not let an agent validate its own work. Use a fresh-context agent for acceptance checks: read files back from disk; test or run code; and obtain a second opinion or use a multiple-answer review for high-risk judgments.

### D. Externalize judgment — a separate file
Turn expert judgment into rubrics and checklists that a weaker model can apply. At minimum, cover:
- when to escalate to a stronger model;
- what counts as genuinely complete;
- when to stop and ask the user;
- signs that the approach is wrong and should change rather than be retried; and
- how to verify minimum acceptable quality.

For every criterion, provide one positive example and one counterexample.

### E. Delegation prompt templates
Provide ready-to-use delegation templates for the future main model, each with fill-in fields for acceptance criteria and report format. Include one template for each common task type: search, implementation, refactoring, research, and review.

### F. Maintenance protocol
Explain how future weaker models can safely update these files: which files they may edit independently, which changes require asking the user first, where and in what format to record lessons from mistakes, and how much accumulated material should trigger a concise-up.

### G. Letter to future sessions
Write a letter to future sessions containing three important things about this environment that I did not ask about, the most likely ways this system will degrade over time, and how to prevent that degradation.

## Mandatory closeout

1. Use a fresh-context subagent to adversarially review all deliverables. Have it look for conflicting rules, incorrect paths or tool names, and ambiguous wording a weaker model could misread. Fix the issues and repeat the review as needed.
2. Read every file back from disk and verify that it exists and is complete.
3. Give me a one-page summary of what changed, why it changed, and how to start using it tomorrow.
4. If context is running low, stop producing other deliverables immediately. Complete the first three closeout steps, and record unfinished work in the letter to future sessions as a handoff.

## Honesty requirement
State the harness's limitations. Decomposition, verification, and multi-sample review can improve execution quality; they cannot resolve ambiguous problems or substitute for taste. Explain what to do in those situations: escalate to a stronger model, seek an external second opinion, or explicitly say the task cannot be done. Investigate uncertain facts; if they cannot be verified, label them as uncertain rather than inventing an answer.