# QuietHarness: a 1,604-byte reliability layer for Claude Code, Codex and Cursor > QuietHarness (repository name claude-code-workflow) installs a small set of behavioural boundaries into whichever AI coding agent you already run. It is an install-and-verify tool, not an orchestration platform, and its own README is explicit about what it does not do. **runesleo/claude-code-workflow** — QuietHarness：Claude Code、Codex、Cursor 共用的轻量 AI 工作系统 - Repository: https://github.com/runesleo/claude-code-workflow - Website: https://leolabs.me - Stars: 709 · Forks: 88 - Language: Shell - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/runesleo-claude-code-workflow ## The failure mode QuietHarness was written against The README lists the problems it targets, and they are all agent behaviour rather than tooling gaps: an agent overwrites files without checking existing changes, calls a task complete without running tests, expands a small edit into an unrequested refactor, and performs deletes, releases, production changes or credential operations without stopping to confirm. Anyone maintaining a real project with an AI coding agent has seen at least one of these. The intended audience is narrow. You are already using Claude Code, Codex or Cursor. You are not looking for a new agent. The README says plainly that installing only one of the three clients gives you the same core reliability boundaries, and that multi-client support exists so you can carry the boundaries to another tool later, not as an installation requirement. If you need a full task database, background automation or a team orchestration platform, the README states QuietHarness itself does not provide them. ## One Core, three adapters, and why the byte counts matter The mechanism is a set of resident instruction files. A shared Core of 1,604 bytes lives in templates/shared/AGENTS.md. Claude Code reaches it through a 168-byte adapter at templates/claude/CLAUDE.md. Cursor gets a 546-byte project rule at templates/cursor/quiet-harness.mdc. Codex reads the shared AGENTS.md directly. The three templates total 2,318 bytes, but no single client loads all three. The README is careful here: it says the comparison is file bytes and does not pretend to be exact token, speed or model-quality data. That restraint is worth noting, because the obvious marketing move would have been to call 1,604 bytes a token count. The Core keeps four things: advance the current request directly; do not pretend to have read files, pages or history you have not seen; verify changes by risk after editing files or code; confirm before money, account, public release, production or destructive actions. Everything else in the repository is documentation or optional structure. The README frames the v3 rewrite as removing protection that had turned into duplicate planning and maintenance burden, not as adding capability. ## Install and first run in an isolated directory The README's recommended path is to try the rules in a throwaway project before touching user-level configuration. Clone the repository and run the inventory script first; it reports what the installer can target on your machine. ```bash git clone https://github.com/runesleo/claude-code-workflow.git cd claude-code-workflow ./scripts/inventory.sh ``` Then create a temporary directory and populate it with the first-success fixture. ```bash demo_dir="$(mktemp -d "${TMPDIR:-/tmp}/quiet-harness-first-success.XXXXXX")" ./examples/first-success/setup.sh "$demo_dir" ``` Pick exactly one client. The installer previews by default; nothing is written until you pass --apply. For Claude Code, the dry run and the apply both name the project directory. ```bash ./scripts/install.sh --dry-run --claude-project "$demo_dir" ./scripts/install.sh --apply --claude-project "$demo_dir" ``` According to the README, that writes $demo_dir/AGENTS.md and $demo_dir/CLAUDE.md. The Codex variant writes only $demo_dir/AGENTS.md, and the Cursor variant writes only $demo_dir/.cursor/rules/quiet-harness.mdc. The installer does not go online, does not log into an account and does not modify a scheduler. Open your chosen agent in $demo_dir and send exactly one prompt. ```text Read TASK.md and complete the task. ``` The README's success condition: the agent should notice and preserve an unrelated user change, fix only the discount calculation, run the existing tests, and give real verification evidence in its final reply, without being told each of those steps. The README also labels this an onboarding behaviour check rather than a causal experiment showing QuietHarness improves a model, and says the design target is under ten minutes while real non-author timing is still an open product gate. ## What the installer prints, and why uninstall is the hard part The installer emits INSTALLED for each target it writes, and emits BACKUP immediately next to a target only when it overwrote an existing file. Before overwriting, it creates a timestamped .bak-ai-workflow-* backup in place. Uninstall is decided per target. If a target has a matching BACKUP line, restore that backup. If it has none, QuietHarness created the file, and the README says to confirm the file still matches the template and then remove that one exact path. If you have since modified it, move it aside rather than deleting it. This is the part most people will get wrong, because the decision depends on output you saw at install time and probably did not keep. The README does document rollback, with full steps in MIGRATION-v3.md. User-level installs are broader and deserve their own dry run. Claude user-level affects ~/AGENTS.md and ~/.claude/CLAUDE.md; Codex affects $CODEX_HOME/AGENTS.md, which defaults to ~/.codex/AGENTS.md. The README does not document a Cursor user-level target, only the project rule. ## Task continuity, the single writer rule, and where the design gets opinionated Beyond the Core, the repository publishes a task model drawn from the author's own setup and sanitised. A task is one authoritative record rather than a shared array that every model rewrites. status is the only lifecycle fact. owner_thread carries stable business ownership. primary_worker and claimed_by describe only the current executor. next_action, artifacts and updated_at must be explicit. When new facts conflict with an old narrative, state_revision overrides. A worker saying it is done is not persistent state; the README requires an artifact, validation and an Owner writeback. The single-writer rule is the sharpest constraint. Claude, Codex and Cursor may research and review in parallel, but one repository or one task fact surface has one writer by default. A repository write records repo, worktree, writer, allowed paths, validation and next gate. Releasing the lock requires artifact, validation, writeback, rollback, outcome and next gate. The README attributes this to a real cross-model double-write incident. This is where QuietHarness stops being a rules file and becomes a small protocol. It is also where it will not fit every team. A solo developer editing one repository will rarely need a writer lock, and the fields become paperwork. The README does not claim otherwise; it presents the task example and writer-lock example as sanitised from a working structure, not a generic schema. ## Limits, and the alternatives that actually differ The clearest limitation is stated by the project itself: no task database, no background automation, no team orchestration platform. The nine business lines (Personal Ops, Strategy Lab, Data Platform, Portfolio, Content Studio, Products & Growth, Health Ops, Daily Rhythm, Research Desk) are published as the author's real topology, and the README says the names are not meant to be copied. Reading them as a recommended structure would be a mistake. The second limitation is the evidence base. The README describes the first-success exercise as an onboarding behaviour check, not a causal experiment, and says automated verification currently covers only fixture repeatability. There is no published measurement that the Core improves model behaviour. That is an honest position, and it also means you are adopting a set of conventions on the strength of the reasoning behind them. For a genuine alternative, look at what the README calls the Leo System and the OPC Company Layer. The Leo System is the fuller structure with the nine business lines, task continuity and writer locks; QuietHarness is the subset of it that survived into the resident configuration. The OPC Company Layer in labs/opc-company/ is the opposite direction: an experimental governance layer for multiple long-lived Owner and Worker roles sharing canonical state, doing semantic handoff and resuming the same task after a worker change. It is explicitly not an installation prerequisite for QuietHarness. So the choice is between a thin resident boundary that stays quiet when nothing relevant is happening, and a governance layer that models ownership and handoff as first-class state. ## Maintenance cost and licence The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice; check LICENSE and your own obligations. The last push to the default branch was on 2026-08-29, and the repository is not archived. Releases v3.0.0 (2026-07-26) and v3.1.0 (2026-08-05) are both from the v3 line, and the README describes v3 as a reduction rather than an addition, which matters for upgrade cost: the migration document MIGRATION-v3.md exists precisely because v3 changed the resident configuration shape. Upgrading means re-running the installer against targets that may already hold files, so the BACKUP lines from the previous install are the thing to keep. The ongoing cost is small but not zero. Three templates and a handful of scripts do not create a dependency, but they do create configuration that lives in your home directory and your repositories, and the README's uninstall procedure assumes you can still tell which files were created versus overwritten. ## Conclusion Adopt QuietHarness if you already run Claude Code, Codex or Cursor on a real repository and have watched an agent overwrite uncommitted work or declare a task finished without running tests. Skip it if you want a task database, background automation or a team orchestration platform; the README states QuietHarness does not provide those, and points to the experimental OPC Company Layer and the separate branch repositories instead. Before installing to a user-level target, run the dry-run for that exact target and read the INSTALLED and BACKUP lines it prints, because those two lines are what later decides whether uninstall restores a backup or removes a file QuietHarness created. Then run the first-success exercise in a temporary directory and check the acceptance criteria in examples/first-success/README.md. ## FAQ ### What is QuietHarness (claude-code-workflow)? It is a shell-based workflow repository that installs a small set of reliability boundaries for AI coding agents. The README describes a 1,604-byte shared Core plus adapters for Claude Code, Codex and Cursor, with dry-run, backups and reversible installation. ### How do I set up claude-code-workflow? Clone the repository, run ./scripts/inventory.sh, then run ./scripts/install.sh --dry-run --claude-project followed by the same command with --apply. The README recommends trying it in a temporary directory created by examples/first-success/setup.sh before installing to a user-level target. ### How do I use claude-code-workflow once it is installed? Open your agent in the target directory and send the prompt the README gives: Read TASK.md and complete the task. Success means the agent preserves an unrelated user change, fixes only the intended code, runs the existing tests and reports real verification evidence. ### Does claude-code-workflow work with Cursor as well as Claude Code? Yes. The installer accepts --cursor-project, which writes $demo_dir/.cursor/rules/quiet-harness.mdc, and --codex-project, which writes $demo_dir/AGENTS.md. The README states that installing only one client gives the same core reliability boundaries. ## Sources - [License: MIT](https://github.com/runesleo/claude-code-workflow/blob/main/LICENSE) - [Project website](https://leolabs.me) - [README](https://github.com/runesleo/claude-code-workflow/blob/main/README.md) - [Releases](https://github.com/runesleo/claude-code-workflow/releases) - [runesleo/claude-code-workflow on GitHub](https://github.com/runesleo/claude-code-workflow) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/runesleo-claude-code-workflow