orchestrator
Skill17 starsChanged 51 days agoMITView on GitHub
Full contractor-mode loop: sub-protocols (LOCALIZE, BENCH-BASELINE, REPRODUCE, DRIFT), review routing by file pattern, blast radius, UAT, parallelism and effort caps, escalation, just-do-it, goal-backed runs. Load it to RUN that loop, once you have an approved plan and are entering step 1, or when a step needs its detail. It is a protocol, not a way to do the work: it never replaces the language, review or planning skill the task itself calls for, and a task small enough to just edit (SKIP_SET) needs none of it. The always-on spine lives in rules/orchestrator-protocol.md. Not for trace capture (harness-trace) or harness optimization (harness-mechanic).
80 other projects use a version of this.
Adopted by
Most recently taken up by
- BrightGold70/skillstheir own version, first seen Nov 8, 2026
- Veeiy/agent-skillstheir own version, first seen Nov 8, 2026
- Mehul72/skillstheir own version, first seen Nov 8, 2026
- pietz/skillstheir own version, first seen Nov 8, 2026
- kcns008/cluster-skillstheir own version, first seen Nov 8, 2026
- soilmass/motion-design-agenttheir own version, first seen Nov 8, 2026
Used with
Projects with it also use worker, reviewer and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
stotihvSkillworker
Execute beads autonomously within a track. Handles bead-to-bead context persistence via Agent Mail, uses preferred tools from AGENTS.md, and reports progress to orchestrator.
Also in 3 projects that use this
MicrosoftSkillreviewer
ASP.NET Core ハンドブックの記事をレビューする。Use when: 記事をレビューする、ドキュメントを校正する、コードレビューする、PRをレビューする。技術ドキュメントのレビュー、品質チェック、校正。
Also in 4 projects that use this
am-willSkillplanner
Create comprehensive, phased implementation plans with sprints and atomic tasks. Use when user says: "make a plan", "create a plan", "plan this out", "plan the implementation", "help me plan", "design a plan", "draft a plan", "write a plan", "outline the steps", "break this down into tasks", "what's the plan for", or any similar planning request. Also triggers on explicit "/planner" or "/plan" commands.
Also in 4 projects that use this
yakatotechSkilladvisor
Provide improvement suggestions and advice on work content. Use for document review, efficiency suggestions, and best practices
Also in 3 projects that use this
AWSSkillplanning
Discovers user intent and generates a structured, step-by-step plan for model customization workflows. This skill must always be activated alongside any other skill when the user's request relates to model customization — including fine-tuning, training, building, customizing, reviewing data, or getting advice on approach, regardless of domain. Do not skip this skill even if the immediate ask is narrow (e.g., reviewing data format or a single workflow step), because planning discovers the full scope of work needed. Also activate when the user wants to resume, continue, or modify an existing plan.
Also in 3 projects that use this
OpenAISkillobservability
Vercel Observability expert guidance — Drains (logs, traces, speed insights, web analytics), Web Analytics, Speed Insights, runtime logs, custom events, OpenTelemetry integration, and monitoring dashboards. Use when instrumenting, debugging, or optimizing application performance and user experience on Vercel.
Also in 3 projects that use this
Other versions80 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 80
- nubjs/nub★ 4.4ksame name
- SirAllap/agentglass★ 347same name
- DylXBT/claude-orchestrator-skills★ 114same name
- nwiizo/claudelytics★ 88same name
- nahisaho/MUSUBI★ 74same name
- olivieropinotti/orchestrator-skill★ 70same name
- sanky369/vibe-building-skills★ 30same name
- felvieira/claude-skills-fv★ 27same name
- robertbstillwell/marketing-skills★ 26same name
- kcns008/cluster-agent-swarm-skills★ 25same name
70 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository37 other files it gives its agents.
- adrSkill
- android-kotlinSkill
- apple-swiftSkill
- autoresearch-promptSkill
- blog-writerSkill
- cloud-infrastructureSkill
- commitSkill
- cover-imageSkill
- freezeSkill
- gemini-reviewSkill
- golangSkill
- harness-mechanicSkill
- harness-traceSkill
- humanizerSkill
- ios-debuggerSkill
- knowledge-syncSkill
- learning-docsSkill
- learning-loopSkill
- obsidianSkill
- plan-forgeSkill
- process-clippingsSkill
- project-analyzerSkill
- project-checksSkill
- pr-reviewSkill
- pythonSkill
- railsSkill
- react-nextjsSkill
- refine-requirementsSkill
- releasing-softwareSkill
- rubySkill
- scoreSkill
- second-opinionSkill
- skill-forgeSkill
- source-controlSkill
- terraformSkill
- test-design-reviewerSkill
- verify-frontendSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 3 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 66 edited versions we read keep these.
3
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 35
Default executor is the native software-engineer subagent.
- Distinctive: line 58
Run tests, lint, build. Max 2 retries on flake.
- Very specific: line 60
If REPRODUCE ran (step 1b), also confirm reproduction_confirmed = true: the script that previously FAILED must now PASS.
- Very specific: line 133
Prohibited in
approval.md: no exploit text, no reproducing command, no vulnerable-code excerpt. - Distinctive: line 139
After RE-VERIFY, before SCORE.
- Distinctive: line 192
If the plan requires edits to a shared surface, run the parallel batch first, then a sequential INTEGRATE wave for the shared files.
- Very specific: line 237
Use the harness-trace skill (schema, JSONL format, capture logic).
“Common” is measured: kept by at least 6 in 10 of the 66 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
ABOUTME: Detail of the autonomous development loop, loaded on demand at step 1 (spine stays in rules/orchestrator-protocol.md)
ABOUTME: Sub-protocols, review routing, blast radius, UAT, parallelism, effort, escalation, goal-backed runs
Orchestrator (contractor mode): full protocol
The spine (loop steps, SKIP_SET, literal report lines, invariants) is always in context from rules/orchestrator-protocol.md. This file carries everything else. Read the section you need; you do not need to read all of it.
Plan checkpoints (<!-- checkpoint:verify -->, <!-- checkpoint:decide -->, see plan-first-workflow) halt the loop mid-IMPLEMENT: pause the current subtask, present state, resume only after human approval.
At plan approval (between step 0 and step 1), if the task has a deterministic done-criterion, propose a /goal line for Max to set: see Goal-Backed Runs below.
Research + Complexity (Step 0)
research-analyst searches docs/solutions/, LEARNING.md, MEMORY.md, vault, then external. Returns: comparison table, recommendation, ecosystem solutions (avoid hand-rolling), 1-2 common pitfalls. MUST end with complexity verdict:
| Level | Criteria | Effect |
| simple | Known tech, <3 files, prior art exists | Standard flow |
| moderate | Some unknowns, 3-5 files | Standard flow |
| complex | Unfamiliar tech, >5 files, multiple approaches, no prior art, cross-cutting | Extended flow: write quality_reports/research/YYYY-MM-DD_desc.md + /second-opinion on approach + activate annotation cycle (see plan-first-workflow) |
Implementation (Step 1)
Split into independent workstreams. Each software-engineer receives: scope (files), plan (subtask + criteria), context (lang/framework). Single-scope: implement directly. See parallelism rules below.
Declared exclusions (page faults). Any brief that scopes context (engineer or reviewer) also declares what was deliberately cut and how to recover it: excluded: <files/areas>; read on demand from <path>. An implicit omission reads as "does not exist" and the agent concludes from absence; a declared one is a recoverable page fault. One line, listing only deliberate cuts, never an inventory of everything untouched.
Executor selection
Default executor is the native software-engineer subagent. Cost-sensitive scoped implementation or mechanical-analysis subtasks MAY instead route to scripts/pi-exec (the pi coding agent driving gemini flash, Google-billed), invoked via Bash, to conserve Anthropic credits.
Preferred invocation in DELEGATED prompts (fresh implementing sessions): the software-engineer-pi agent from the registry, a thin haiku driver that runs the wrapper and relays results; it is not a skill and must not be searched for as one. It cannot edit files or implement natively, so "executor unavailable" surfaces as a loud report, never as a silent fallback. Direct Bash invocation of the wrapper remains valid for the orchestrator in-session. If pi fails a subtask twice, re-implementation goes to the native software-engineer and the fallback is DECLARED in the summary (it is the change contract's falsification signal, never silent).
Constraints on a pi-executed subtask (non-negotiable, since pi runs outside Claude Code's hook loop; the spine states them too):
- The orchestrator is the sole committer: pi never commits. Hooks that fire on Claude Code tool events (verify-before-stop, aboutme-enforcer) cannot see pi processes; pre-commit-gate still gates every commit because the orchestrator makes them all.
- DRIFT (1c) is mandatory and its skip conditions are void: every pi-executed subtask gets a fresh-context drift check, even a single trivial one.
- Review and spec roles are never routed to pi: cross-model review of Gemini-written code is the point (native Fable/Opus stays adversarial). Rewriting rules, agents or skills is a spec role.
- The ORCHESTRATOR reports each pi-executed subtask on the literal
EXECUTOR:line. The wrapper's own stdoutEXECUTOR:line (model/brief/workdir) is a local log, not the trace signal.
Sub-protocols
| Sub-step | When it runs | How | Trace data | Skip when |
| LOCALIZE (1a) | Before any edits | Engineer outputs files_to_edit. Orchestrator checks files exist and align with plan. WARN on extras. STOP on missing planned files UNLESS engineer provides scope_reduction_rationale (e.g., "File X turned out not to need editing because ..."). | {files_planned, files_proposed, precision, recall, mismatches, scope_reduction_rationale?} | Plan lists exact files; single-file task |
| BENCH-BASELINE (1a, hot-path) | With LOCALIZE, before any edits | If the task touches a repo's hot-path packages (mirsad internal/{lsh,pii,decode,control,adapter,proxy,cache} today), run that repo's make bench-baseline on the clean pre-edit tree → .bench/baseline.txt. Machine must be quiet (see VERIFY). | {baseline_captured, bench_pkgs, baseline_path} | No bench-baseline target; task touches no hot-path package |
| REPRODUCE (1b) | Bug-fix only, after LOCALIZE | Script that FAILS on current code and PASSES after the fix. Target files from LOCALIZE. | {script, fails_before_fix, passes_after_fix} (passes_after_fix null until VERIFY) | Not a bug-fix; purely visual bug; plan says infeasible |
| DRIFT (1c) | After each subtask (including parallel ones, using git diff -- <files_for_subtask> to avoid races) | Fresh-context agent receives: subtask description + scoped diff. One question: "Did we build exactly this, no more, no less?" Verdict: aligned / minor drift (WARN, proceed) / significant drift (STOP). | {subtask_id, verdict, deviations} | Single subtask; trivial (<10 LOC) |
Report each executed sub-step on the literal line from the spine. Free-form phrasing is invisible in telemetry.
VERIFY (Step 2)
Run tests, lint, build. Max 2 retries on flake; on the 3rd failure, STOP and escalate (same flow as Step 7 escalation).
If REPRODUCE ran (step 1b), also confirm reproduction_confirmed = true: the script that previously FAILED must now PASS. If not, the fix didn't address the reported bug; return to FIX.
If a .bench/baseline.txt exists for the task (BENCH-BASELINE ran), also run make bench-compare. Exit ≠ 0 ⇒ a Major finding, never an auto-fail: either fix the regression, or add an explicit accept-with-rationale row to the plan's Decisions table ("expected cost of feature X: +N% on Y"). Never a silent accept. The A/B is only valid on a quiet machine: competing benchmark or build processes invalidate the same-session comparison (observed live).
Review Routing (Step 3)
Open every round with the literal REVIEW-ROUND: n=<n> budget=<b> scope=full, where n is total_fix_rounds (REVIEW->FIX plus UAT->FIX cycles, the same number the plan's Budget bounds) and <b> is that budget. Without it the round is invisible to telemetry and to review-budget-guard, which then has nothing to count.
| Pattern | Agents |
*.go, *.rb, *.py, *.ts, *.kt, *.swift | architecture + security |
| Hot paths, queries, caching | + performance |
*_test.*, *_spec.* | + test + test-design-reviewer |
go.mod, Gemfile, package.json, pyproject.toml | dependency |
migrations/, schema.rb, *.sql | database |
docs/, README*, ADR/, *.md | dx |
| No match | architecture + security (minimum) |
Findings come back in the Finding Contract shape (rules/quality-gates.md): severity, location, claim, fix, evidence.
Finding Consolidation (step 3 → 4)
Reviewers overlap by design: the routing table above maps file patterns to agents, never defect classes to owners. Consolidate the reports before FIX runs:
- Join. Reviewers run in background (see Review Scheduling), so consolidation is the barrier: collect every launched agent before proceeding. Mechanically: write the launched roster to
quality_reports/reviews/<slug>/000-roster.mdat launch; wait for each completion notification; for any agent that signals idle WITHOUT a report, request it withSendMessage({to: <agent name>}), because a backgrounded reviewer does NOT reliably self-deliver. Countagents=from reports actually in hand, read off the roster file, never from memory. Not FIX, FIX is skippable when no Critical/Major lands, and that is exactly the path where a missing reviewer reads as "clean". Record the launched roster in the round's findings file and printagents=<returned>/<launched>on theREVIEW-ARTIFACT:line;review-budget-guardblocks a SCORE while they disagree. A stopped-at-cap agent counts as returned only once its truncation finding exists (see Review Scheduling). 0b. Snapshot check. Findings are anchored to the SHA each reviewer read. Before consolidating, confirm the working tree still matches it (git rev-parse HEADplus a clean-tree check for the reviewed paths). A mismatch means the tree moved under a running reviewer: say so loudly and either re-anchor the affected findings or re-run that reviewer. Silently consolidating line-anchored findings against a moved tree produces fixes at the wrong lines. - Collect every agent report.
- Group findings by
(file, line). - Within a group, merge the findings whose claims describe the same defect; the dedup key is
(file, line, normalized claim). - On merge, keep the highest severity of the group and record
reported_by: <agent>[,<agent>], listing every agent that reported it. - The consolidated list is what FIX (step 4) and SCORE (step 6) consume.
Duplicates are expected and harmless. Never instruct an agent to skip a concern because another agent owns it: a duplicate is caught here, a concern that every agent assumes someone else owns is caught nowhere. The two existing inline deferrals (security-reviewer defers deep CVE analysis to dependency-reviewer, database-reviewer defers complex N+1 to performance-reviewer) are depth gradients, not partitions, and stay as they are.
Invariant: consolidation may lower the finding count, never the highest severity in a group. Grouping by line is not merging by line: an N+1 and a god-object both filed at y.go:10 are distinct claims, so both survive as separate findings.
Review Artifacts
Findings that live only in session context die at the next auto-compact: fix round 3 cannot cite round 1, and the fix-round budget ends up asserted in the final summary instead of auditable. Persist them, split in two, because a finding carries the exploit recipe by construction (the Finding Contract demands evidence such as a reproducing command). The recipe stays local; only a redacted record is committed.
Per-round findings (local, gitignored)
Each REVIEW round writes one file: quality_reports/reviews/<YYYY-MM-DD_slug>/NNN-findings.md, numbered from 001 in round order. The slug is the plan file's own slug (quality_reports/plans/active/YYYY-MM-DD_<slug>.md); with no plan on disk, derive it from the branch name; either way reuse it verbatim for approval.md, so the two paths always pair. Contents:
| Field | Content |
| Reviewed branch and commit | Branch name plus the exact commit SHA the round reviewed |
| Round | Round number, matching NNN |
| Findings | The consolidated list (see Finding Consolidation) in Finding Contract shape: severity, location, claim, fix, evidence |
| Status | Per finding, one of open / fixed-in-round-<n> / accepted |
supersedes: NNN | Present when this round restates findings first recorded in an earlier file |
| Reviewer roster | Every agent launched this round, with per-agent status completed / truncated; the source agents= is counted from |
| Leftover worktrees | Every review worktree still on disk at consolidation: path, owning agent, disposition (removed after consolidation / kept: <why>). Absent means none survived auto-clean, not that nobody looked |
| Verification gaps | What this round could not check, and why |
Immutable once written. A later round never edits an earlier file: it writes the next NNN, carries supersedes: NNN, and restates fresh per-finding statuses for everything it inherits. A mutable shared list would be a second amnesia source: if round 2 fixed 2 of 3 findings and did not update the file, round 3 reads three open findings and re-fixes two.
Gitignore guard, before the FIRST write. These artifacts land in the user's project repos, not in claude-forge. Check the target repo's .gitignore for a quality_reports/reviews/ entry; append the line if absent, never rewrite the existing file. Exploit detail must not enter git history: committing it publishes the vulnerable state permanently, with no coordinated-disclosure discipline.
approval.md (committed)
Written at convergence and committed with the change, at quality_reports/approvals/<YYYY-MM-DD_slug>.md (outside the ignored tree, so the record reaches the PR and the human reviewer):
| Field | Content |
| Branch, commit | What was approved |
| Rounds run | Count, matching the highest NNN written |
| Counts by severity | Critical / Major / Minor, over the consolidated list |
| CWE ids | Where applicable, id only |
| Final SCORE | In the canonical SCORE: form |
| Residual risks | What was accepted and why, in one line each |
| Findings path | Path of the local, gitignored findings directory |
Prohibited in approval.md: no exploit text, no reproducing command, no vulnerable-code excerpt. The findings files carry the recipe locally; approval.md carries only the redacted record. A CWE id and a count are the level of detail it may reach.
Absence of approval.md means the loop did not converge. That is a signal only if something reads it, so PRESENT (step 8) surfaces it on the literal REVIEW-ARTIFACT: line with converged=no (on that line, findings=<c/m/n> carries the Critical/Major/Minor counts, in that order, over the consolidated list). It is never left for a human to notice.
Blast Radius (Step 5b, conditional)
After RE-VERIFY, before SCORE. Detects entropy: docs, tests, imports still referencing pre-change behavior.
Trigger (ANY of)
- Changed files add/remove/rename exported symbols. Detect with
ast-grepor a fully-qualified regex (e.g.,\bMyModule\.MyFunc\b). Never naked grep on common names likeget,init,render: they explode to hundreds of false matches. - More than 3 files changed
- Schema/migration changes, CLI flag definitions, REST/gRPC endpoint handlers
How
- CLI pre-filter:
ast-grepor qualified regex for changed symbols; collect importers, docs, tests referencing them. - Fresh-context agent receives only snippets of related files (not full files). Flags stale references, old-behavior assertions, comments describing removed logic, broken imports.
- Report: MAJOR (functional contradiction) or MINOR (stale comment/doc). CRITICAL contradictions re-enter FIX (step 4) before SCORE. Close with the literal
BLAST-RADIUS:line from the spine (ast-grep usage is NOT a signal; only that line is).
Skip when
Docs-only; pure refactors with no API change; pre-filter found 0 related files. When a trigger held but a skip condition applies, say so on the same literal line.
UAT: Goal-Backward Verification (Step 9)
UAT is Outcome Verification with a human walkthrough. The schema (observable truths → evidence → pass/fail) lives in verification-protocol.md; don't redefine it here.
Build the table from the goal (3-7 observable truths). Fill Evidence via CLI/output for every truth that can be verified mechanically. Use AskUserQuestion only for truths that need human judgment (visual, subjective, UX). On failure: feed into fix loop (step 4), re-verify, re-score, re-UAT failed items only. UAT→FIX rounds count against the plan's fix-round budget.
Skip when: in SKIP_SET.
Review Scheduling
Review agents cannot conflict with the tree the loop is building, so they never need to block it. That is a property of how they are launched (isolated, below), not a promise about what they do: reviewers write by design. Measured over 420 reviewer launches (78 sessions): per-agent latency is not the problem (median 2.0 min, p90 6.1), but a single pathological run consumed 20% of all blocking time in the dataset, and the worst sessions ran 8-15 review rounds against a budget of 5.
- Launch backgrounded (
run_in_background: true) with an explicitname, and say which reviewers are running and what you are doing meanwhile. A silent multi-minute block leaves interruption as the user's only control, which is how four of the six longest recorded "runs" ended. - Launch isolated (
isolation: "worktree", on every review-agent launch, alongsiderun_in_background: true). The agent gets a temporary worktree copy of the repo and its file writes land there. The cost is roughly 200-500ms of setup plus a checkout's worth of disk per agent, and it is paid because reviewers write: mutation testing writes mutants into the source and runs the suite against each, and executable probes write files too. A mutation run that dies before restoring leaves surviving mutants on disk; in a copy that is a worktree you throw away, in the main tree it is corrupted source that the next build and the next reviewer both consume. - What is isolated is the working tree, not the repository. A worktree shares the
.gitdatabase with the main repo (objects, refs, branches, stash, config, hooks; onlyHEAD,refs/bisectandrefs/worktree/*are per-worktree), so a reviewer reaching for git plumbing can still move state the main tree reads. The reviewer definitions carry the rule that follows from this: never mutate shared git state, and undo a mutant by rewriting file content, not withstashorcheckout <ref>. - Open every reviewer brief with the isolation assertion, verbatim and first:
This launch carries isolation: "worktree"; base SHA <sha>.The reviewers gate their own writes on it, so the sentence is not decoration: a brief without it puts the reviewer in strictly-read-only mode. - A launch that omits the parameter is denied on the
Agenttool path.reviewer-isolation-guard(hooks/reviewer-isolation-guard.sh, PreToolUse onAgent) refuses any*-reviewersubagent launched withoutisolation: "worktree", because such an agent is a write-encouraged reviewer standing in the real tree; it fails open on environment failures (nojq, unparseable payload, a cwd outside a work tree) and closed only on the violation itself. Two paths stay prose-only: Workflow-tool scripts spawn subagents through an internalagent()primitive that no PreToolUse matcher observes, and an edited or unregistered hook enforces nothing. There the agent-side downgrade is the only guard, and it stays the universal backstop everywhere else too. The definitions can fail closed only because the brief carries the assertion above: comparinggit rev-parse --git-diragainst--git-common-dirdetects "some linked worktree", not "my own copy", and it therefore false-passes whenever the launching session is itself in a linked worktree, which is this repo's normal state (.claude/worktrees/<branch>). An omitting launcher omits the assertion too, which is what the reviewer actually keys on, and a brief asserting isolation that was never passed still defeats the self-check. A launch that legitimately cannot pass the parameter (pr-reviewreviews inside its own throwaway clone) makes the FIRST line of its promptISOLATION-EXEMPT: <reason>, a fixed literal so exemptions stay greppable and countable in transcripts. Only the first line counts: briefs quote untrusted text verbatim (issue bodies, plan excerpts, file quotes), and a marker accepted anywhere would let quoted content exempt its own launch, indistinguishably from an authored exemption. The marker silences the hook only. It is not a write-enable: an exempted brief carries no isolation assertion, so the reviewer still self-downgrades to read-only. - Name the base SHA in the brief and require
file:linecitations against it. The worktree is a copy, so a finding that does not say what it was anchored to cannot be checked against the main tree; the consolidation snapshot check (step 0b) keys on exactly that SHA, and an anchor that no longer exists there is a stale finding, not a defect. The copy materializes at the default branch, not at the SHA you name (observed: reviewer worktrees atorigin/mainwhile reviewing a feature branch), so the brief also tells the reviewer to read the reviewed content withgit show <sha>:<file>. The object store is shared, so that always resolves. - Clean up after consolidation, never before. An unchanged worktree auto-cleans. One the reviewer changed does not, and what it changed is the evidence behind its findings, so remove it only once its report is consolidated, with
git worktree remove --force <path>(plainremoverefuses a dirty tree, which is exactly the case that survives auto-clean). Every worktree still on disk at consolidation goes in the round's findings file as a Leftover worktrees row, never silently deleted. - This is isolation, not permission. A reviewer can still write anything inside its own copy, and a prompt-injected reviewer is still prompt-injected. The copy bounds where the damage lands; it does not prevent it. No
tools:allowlist backs this up, deliberately: withBashallowed the allowlist is theatre, and without it the empirical review above becomes impossible (pinned byhooks/tests/test_agent_definitions.py). - Do non-conflicting work while they run: change contracts, plan updates, commit-message prep. Never edit a file that is under review, that moves the tree beneath a running reviewer (see Consolidation step 0b).
- Cap: 15 minutes per reviewer, enforced harness-side (
TaskStopon the backgrounded task), because theAgenttool has no timeout parameter and a synchronous launch therefore cannot be capped at all. Never state the cap in the reviewer's prompt: an agent told its deadline returns shallow findings fast, which is worse than truncation because it is indistinguishable from diligence. - Poll, do not hope. Between the non-conflicting work items, check outstanding reviewers (
TaskList, or aMonitorwith an until-condition). At the 15-minute mark for an agent,TaskStopit. An unattended orchestrator has no clock event: without an explicit poll the cap is a number in a document, not a limit. - No commits while a reviewer is outstanding.
git commitruns the pre-commit gate, which runs the test suites and moves HEAD, tripping the snapshot check for every running reviewer at once. Preparing a commit message is safe; committing is not. - A stopped agent is
truncated, never clean. Record its per-agent status in the findings file and file a Major finding, "review incomplete: covered X, uncovered Y", so it flows through the normal FIX/escalation path.converged=yesrequires every routed agentcompleted. Major, not Critical: an infra timeout should cost a fix round, not zero the score.
Parallelism
| Agent class | Default | Max | Scheduling | Condition for max |
| Main-tree read-only (research-analyst, review agents, explorers) | 5 | 7 | background | Always |
| Write (software-engineer) | 3 | 5 | synchronous | File scopes disjoint AND no shared integration surfaces |
Shared integration surfaces (even a 1-line change needs a sequential wave): routing tables, barrel exports / index.*, DI container config, dependency manifests (go.mod, package.json), migrations directory, shared test fixtures.
If the plan requires edits to a shared surface, run the parallel batch first, then a sequential INTEGRATE wave for the shared files.
Pilot before a large run: any fan-out over ~10 similar items (parallel agents, workflow stages, batch migrations) runs 1-2 items first; inspect the result, fix prompt or approach, then launch the rest. A full-fleet launch on an unproven prompt burns tokens at fleet scale.
Effort assignment
Effort is the cost lever, not model downgrade. An effort level does not buy the same amount of thinking on every model release, so re-baseline this table at each release instead of porting it. Each agent pins effort: in its frontmatter per role:
| Role | effort | Why |
| Orchestrator / main coding session | settings effortLevel | long agentic coding turns; the value lives in settings, set per model release from measured runs |
| software-engineer | inherit (omitted) | writes code at session effort |
| Review agents, research-analyst, tech-writer | medium | bounded analysis that gates the loop |
| harness-mechanic | high | cross-trace synthesis |
| project-analyzer | low + model: haiku | mechanical extraction |
Override per task with /effort. Do not pass effort: inherit (invalid; omit instead).
Escalation (Step 7)
total_fix_rounds counts every REVIEW→FIX cycle AND every UAT→FIX cycle. When it reaches the plan's fix-round budget (default 5) without meeting the score threshold, STOP and escalate.
Present to the human:
- Current score and threshold
- Top 3 unresolved findings (Critical/Major)
- Round-by-round score delta
- Hypothesis on why progress stalled
- Options: lower threshold, accept remaining risk, re-plan, abandon
Just-do-it mode
Skip final approval and auto-commit when ALL of: SCORE ≥ 80, no Critical findings, BLAST-RADIUS clean. Bypasses UAT (no human walkthrough possible in this mode). Stops at a local commit on the feature branch: does not push, does not open a PR.
Goal-Backed Runs (optional)
/goal (CLI ≥ 2.1.139) wraps a session-scoped prompt-based Stop hook: an evaluator (small fast model, no tool access) re-checks a completion condition after every turn and sends Claude back to work until it holds. It complements score-evidence-guard: the hook rejects SCORE claims lacking fresh evidence; /goal rejects stopping before the gate is met.
/goalis user-typed; Claude cannot set it. At plan approval, when the task has a deterministic done-criterion, propose the exact line for Max to set, phrased against the canonicalSCORE:format so the evaluator finds it verbatim in the transcript, e.g.:/goal the transcript reports a line matching SCORE: <n>/100 (threshold: 80, gate: commit) with n >= 80, after make check && make test-e2e pass on the final code, or stop after 5 fix rounds- The turn-cap clause mirrors the plan's fix-round budget. Reaching it triggers the escalation flow, never a silent stop.
- The condition must be transcript-evaluable: the evaluator runs no commands, so it can only judge what the session surfaced. The
SCORE:line format is exactly what it keys on. - Skip for SKIP_SET and for tasks whose done-criterion needs human judgment (visual, UX): those stay with UAT (step 9).
Trace Capture
Use the harness-trace skill (schema, JSONL format, capture logic). Trace is skipped for SKIP_SET. Trace files are local-only (gitignored).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

