Don’t Rush to Blame Opus 5.5—For Long Tasks, First Define What “Done” Means

Long tasks never finish, and the budget runs out first. Tweet author beamnxw breaks the problem down into 15 Claude Code commands and a 7-layer harness. The core is not complicated: make every run leave behind results you can open, evidence you can check, and progress you can pick up again tomorrow.

In a reply, commenter CooperCode traced many complaints that “the model got lost” back to the harness never defining done. That sentence is more worth remembering than the command list. Model capability matters, of course, but long-task failures often happen at the process layer: goals are not written as verifiable conditions, context is not compacted, subtasks are not isolated, and progress is not persisted to disk. Budgets are usually worn down by a string of turns with no finish line; single big mistakes are actually rare.

The 15 commands can be viewed by purpose:

Commands are just the entry point. The referenced article gives a documentation workflow example: sources/ holds reference materials, drafts/ holds drafts, and published/ holds approved files. The root CLAUDE.md contains only facts useful across tasks, such as output locations, source requirements, and writing conventions. Put repeated processes into skills, such as /write-draft. Connect external materials via MCP. Put permissions and hooks at the execution layer: prohibit reading .env and prohibit modifying published/. Make the reviewer a subagent, give it only read and search tools, and require it to return a table of claim, verdict, source URL, and correction. Allocate effort by task. Finally, use /goal to lock down the completion conditions.

The details of /goal deserve separate mention. The official docs are clear: the evaluator only looks at what Claude displays in the conversation; it does not run commands or read files. So conditions must be written as things the output can prove. For example, “all tests under test/auth pass and lint is clean,” or more specifically, “npm test exits 0.” To limit how long it runs, add or stop after 20 turns to the condition. Commenter Mohabbat also mentioned this, and reminded people to name a check Claude can display. This detail is more useful than “making the model try harder.”

A commenter (小果果炖粥) asked in a reply: if a model needs 15 commands and a 7-layer harness to finish long tasks, is the bottleneck the model or the scaffolding? That question is worth keeping. Commands are the surface; the finishing mechanism is the substance underneath. Pick a long task first, write in the completion conditions, evidence format, and progress file, then run it. After it runs, check whether drafts/article.md and drafts/checks.md exist, whether incorrect claims were corrected, and whether unresolved claims were marked.

The original post and the full harness article are in beamnxw’s tweet and the long-form article.