agent-skills / autonomous-workflow
CLAUDE.md20 starsChanged 13 days agoMITView on GitHub
This file is auto-loaded by Claude Code when working inside skills/workflow/autonomous-workflow/. It captures why this skill exists, how it's shaped, and what to keep in mind when changing it — context that an agent or contributor needs before editing the procedures. For the runtime instructions the skill follows when executing a task, read SKILL.md and rules/*.md. This file is about design intent, not runtime behavior. autonomous-workflow is an orchestrator skill. It does not contain the intelligence to plan, code, test,…
In this repository48 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- ideateSkill
- interviewSkill
- playwright-trace-analyzerSkill
- profile-optimizerSkill
- rum-trackingSkill
- screencastSkill
- video-analyserSkill
- youtube-transcriptSkill
- create-skillSkill
- docsSkill
- handoffSkill
- optimize-claude-mdSkill
- persistent-memorySkill
- attach-mediaSkill
- ci-auto-fixSkill
- create-prSkill
- github-actions-authorSkill
- resolve-conflictsSkill
- animations-nativeSkill
- animationsSkill
- behavioral-designSkill
- chartingSkill
- storybookSkill
- uxSkill
- visual-designSkill
- ai-engineeringSkill
- confidenceSkill
- criticalSkill
- impact-mapSkill
- jev-assertSkill
- measurableSkill
- optimize-approachSkill
- polishSkill
- pr-reviewSkill
- review-loopSkill
- tddSkill
- verify-behaviorSkill
- aw-verifySkill
- e2e-testing-mobileSkill
- e2e-testingSkill
- telemetry-verifySkill
- ui-verifySkill
- autonomous-workflowSkill
- aw-create-planSkill
- aw-create-walkthroughSkill
- fix-bugSkill
- implement-suggestionSkill
The file
Show its rules and text
We split this CLAUDE.md into the rules it gives an agent
35 rules. About 0 are common, 13 are distinctive, and 22 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈13
Distinctive · estimate
This author's own choices. Worth a look.
22
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 34
If you find yourself adding domain knowledge to this skill (how to write a React component, how to fix a TypeScript error, how to write a …
- Very specific: line 161
Never block on a missing companion.
- Very specific: line 172
Add a row to the registry table in rules/companion-skills.md.
- Very specific: line 174
Add the invocation in the relevant phase-N-*.md rule, with an ## Anchor heading matching the disable link target.
- Distinctive: line 176
Verify the workflow still degrades gracefully when the new companion is missing (uninstall the companion locally, run a task, confirm it …
- Very specific: line 178
Update the install commands in SKILL.md, README.md, and install.sh if the new companion should be in the recommended install set.
- Very specific: line 183
Delete the row from rules/companion-skills.md.
- Distinctive: line 184
Delete the invocation block in the relevant phase rule.
- Very specific: line 189
No companion is non-removable.
- Very specific: line 196
Every tier reviews once, locally, before the PR: review-loop in local mode (branch-reviewer → apply → polish simplify, zero GitHub calls), …
- Distinctive: line 285
When changing the cap numbers, update all of:
- Very specific: line 307
Every task starts with tier detection.
- Distinctive: line 330
When in doubt, choose the heavier tier.
- Distinctive: line 375
When editing this skill, do not break these — they're load-bearing:
- Distinctive: line 381
Companions degrade silently: Never make the workflow block on a missing companion (except the one above).
- Very specific: line 389
Anchors must match disable links: Every ## Anchor heading in a phase rule that's referenced from companion-skills.md must produce a slug …
- Distinctive: line 417
Sub-Agent Resource Discipline is non-relaxable: Every sub-agent dispatch block must embed the resource-discipline sentinel line.
- Very specific: line 485
When changing a phase, gate, taxonomy class, or load-bearing invariant in this skill, always update rules/diagnostic-surface.md in the same …
- Distinctive: line 526
Design rule for the loop: keep domain knowledge out of this skill.
- Very specific: line 654
Every phrase aw advertises appears in the routing rule.
- Distinctive: line 839
When adding a new self-modifying action, follow the same template: choose a confidence mode, pick a threshold (default 90 %), gate the …
- Very specific: line 851
Read SKILL.md and rules/companion-skills.md first to refresh the contracts.
- Very specific: line 856
Verify anchors still match disable links (grep -E "phase-.*\.md#" rules/companion-skills.md).
- Very specific: line 857
If the change affects companion behavior, update rules/companion-skills.md in the same PR.
- Very specific: line 887
If you ever rename the namespace, update all four (frontmatter name, install.sh symlink target, routing rule dispatch, and every doc …
- Distinctive: line 905
Run a small Lite Mode task — verify Phase 0 + Phase 2 + Phase 5 + Phase 6 companions all fire correctly.
- Very specific: line 907
Run a larger Full Mode task — verify plan.md and walkthrough.md are generated, the brief validates and the checks gate, stuck-loop respects …
- Distinctive: line 911
If you change the stuck-loop number, mode-detection criteria, or the companion list, do both runs.
- Very specific: line 939
Universal loop + two-scope writes (the R2 risk): run two checks against LoreKit (memory.search { q, scopes: ["repo::{owner}/*", "global"], …
- Very specific: line 942
Project-bound lesson: run a task that produces a repo-bound lesson (an Applies when line referencing a repo path) and confirm the lesson …
- Very specific: line 1134
review-loopself-reports a clean skip: when sub-agent dispatch is unavailable, with a NOT REVIEWED slot in create-pr's report. - Distinctive: line 1164
Ask" trigger #3 ("Scope creep detected"), which conflated the agent inventing work with the user *asking for* work, and there was no …
- Very specific: line 1232
sanctioned, reproducible path: when the split is *structurally* unavailable, aw runs the Full phases in one window — playing the planner …
- Very specific: line 1482
When ME == AUTHOR, the run enters PR (self-review) sub-mode: Step 4 auto-fix re-enabled, Steps 5.1–5.6 (pending GitHub comments) replaced …
- Distinctive: line 1485
Should-fix → High bucket) rather than a separate channel.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
autonomous-workflow — Developer Documentation
This file is auto-loaded by Claude Code when working inside
skills/workflow/autonomous-workflow/. It captures why this skill exists, how it's
shaped, and what to keep in mind when changing it — context that an agent
or contributor needs before editing the procedures.
For the runtime instructions the skill follows when executing a task, read
SKILL.md and rules/*.md. This file is about
design intent, not runtime behavior.
What this skill is
autonomous-workflow is an orchestrator skill. It does not contain the
intelligence to plan, code, test, review, or deliver — it contains the
sequencing and gates that decide when those things happen and which
companion skill handles each one.
Concretely:
- Phase model 0 → 7 — every autonomous task moves through the same phases in order; each phase has a gate that must pass before the next.
- Companion skills — the actual work (planning, TDD, UX review, code quality, doc updates, PR creation, CI fixing) is delegated to specialist skills in this same repo.
- Artifacts — Full Mode produces
checks.yaml(the living, executable contract Phase 4 gates on), a leanplan.mdhandoff document, andwalkthrough.mdin.agent/{branch}/so a fresh Claude session can pick up where another left off. Plan snapshots (plan.v{N}.md) are opt-in, not default (see the artifact-lightening design intent below).
If you find yourself adding domain knowledge to this skill (how to write a
React component, how to fix a TypeScript error, how to write a good commit
message), you're in the wrong place — that knowledge belongs in a companion
skill (ux, tdd, create-pr, etc.) which this skill invokes.
Why this skill exists
LLM agents tend to fail in three predictable ways during long-running tasks:
- Skip validation — start coding before they understand the requirement.
- Lose context mid-task — a session ends, a new one begins, the new session has no memory of decisions made.
- Burn tokens on hallucinated fixes — get stuck on a failing test and try increasingly speculative fixes for 20+ iterations.
autonomous-workflow exists to address all three:
- Phase 0 (Validation) is mandatory — the agent must confirm understanding with the user before any code is written.
checks.yamlis the living contract;plan.mdis the handoff artifact in Full Mode — both generated by theaw-create-plancompanion.checks.yamlcarries the executable acceptance criteria Phase 4 gates on and cannot go stale silently (it passes or fails against reality on every loop).plan.mdcarries the decisions, requirements, and approach a fresh session needs to resume cold after compaction or a session boundary — its evidence-backed payoff is cross-session resumption, not ceremony, so it is tiered into an always-on Core and include-when-needed Extended sections and the executor writes drift back into it (Phase 3) so it stays honest. Seereferences/anthropic-architecture-research.md§5 for the empirical basis (and the honest gaps), and the artifact-lightening design intent below.- Phase 4 stuck-loop has a mode-aware hard cap — 3 iterations in Lite
Mode, 5 in Full Mode. At the cap, the agent runs
confidence(analysis); if confidence is below 90% the workflow re-traces the execution path, regenerates the affectedplan.mdsection, and resumes ONCE more before mandatory user escalation. No more 20-iteration token burns.
Everything else in this skill (companion invocation, mode detection, artifacts, parallelization) is in service of those three goals.
Architecture at a glance
skills/workflow/autonomous-workflow/
├── SKILL.md # Thin index. Frontmatter + phase table + companion table.
├── README.md # User-facing install / customize / migrate docs.
├── CLAUDE.md # ← this file. Developer docs.
├── install.sh # Symlinks templates into ~/.claude or ./.claude.
├── rules/
│ ├── companion-skills.md # Registry of all optional companions + disable links.
│ ├── prerequisites.md # gh (required) + gw (recommended) install + native fallback.
│ ├── overview.md # High-level narrative for orientation.
│ ├── phase-0-validation.md # Each phase rule is self-contained — agents
│ ├── phase-1-planning.md load on demand. They can include the
│ ├── phase-2-worktree.md SKILL.md + companion-skills.md as context
│ ├── phase-3-implementation.md and not need any other phase rule.
│ ├── phase-4-testing.md
│ ├── phase-5-documentation.md
│ ├── phase-6-pr-creation.md
│ ├── phase-7-ci-gate.md # Replaces phase-7-cleanup.md from v2.
│ ├── artifacts-overview.md # The artifact pattern (plan.md, checks.yaml, walkthrough.md).
│ ├── decision-framework.md # Branch naming, test strategy, mode detection.
│ ├── error-recovery.md # Common failures and recovery procedures.
│ ├── parallel-coordination.md# Sub-agent fan-out and multi-agent handoff.
│ ├── safety-guardrails.md # Hard limits, validation checkpoints.
│ ├── smart-worktree-detection.md # Fuzzy-match task to existing worktree.
│ ├── planner-executor-handoff.md # Handoff contract between the brief (`aw`) and `aw-executor`.
│ ├── corrections.md # The corrections a capable model needs on Full runs; read before the brief.
│ ├── diagnostic-surface.md # Phase model + failure taxonomy + guards table consumed by `/create-skill diagnose autonomous-workflow`.
│ ├── self-improvement-loop.md # Episodic-lessons fast tier (LoreKit loop::aw-lessons) + promotion to diagnose. Read Phase 1; write Phase 4/7.
│ └── _template.md # Boilerplate for new rule files.
├── aw/
│ └── SKILL.md # THE DISPATCHER. A nested skill (like aw-tester-chrome), not an agent —
│ # opt-in entry, tier routing, universal lessons loop. Invoked /aw.
├── templates/
│ ├── aw-executor.agent.md # aw-executor agent (phases 3-7, executes the brief). Linked by install.sh as aw-executor.md.
│ ├── _deprecated-single-agent.md # DEPRECATED — kept for backward compat only. Not linked.
│ └── routing.rule.md # Auto-routing rule (linked into ~/.claude/rules/).
└── references/
├── autonomous-workflow-complete.md # Full end-to-end walked example.
├── error-recovery-scenarios.md # Concrete error → recovery transcripts.
├── iterative-refinement.md # Worked example of stuck-loop recovery.
├── self-improvement-walkthrough.md # Worked example: a lesson's full lifecycle (capture → recur → promote).
├── anthropic-architecture-research.md # Verbatim Anthropic citations + design mapping.
└── planning-quality-research.md # 2024–2026 web-research pass on planner quality (anti-reinvention, spec fidelity, clarify-or-abstain, executable checks); evidence base + decision record for the v3.15 plan-quality gates.The split between SKILL.md (lean index, always in context), rules/ (loaded
on demand), and references/ (loaded only when an agent wants worked examples)
is deliberate — context budget is finite, and most phases only need their own
rule file plus companion-skills.md.
The companion-skills pattern
The defining design decision in v3 is that the workflow is modular by default. Companions are not hard dependencies; they're advisory invocations.
How a companion is wired
A phase rule contains a section like:
## TDD Trigger
When the task involves pure logic, business rules, or "test-driven" was
requested, invoke:
Skill("tdd")
If the skill is unavailable, log one line and continue:
- [TIMESTAMP] Phase 3: tdd — skipped (not installed)Three things matter:
- The trigger condition is concrete — file globs, keyword match, file counts. Not "if the agent feels appropriate." Subjective triggers leak judgment into runtime and make behavior non-reproducible.
- The
Skill()invocation is wrapped in graceful degradation — if the companion isn't installed, the workflow logs a one-liner and continues. Never block on a missing companion. The only exception isconfidenceat Phase 1, which is the load-bearing safety gate. - The section anchor matches the "Disable by" link in
rules/companion-skills.md. If you rename the heading, update the link target — GitHub anchors are slug-derived from headings (with.stripped, so## Claude.md Triggerbecomes#claudemd-triggernot#claude-md-trigger).
Adding a new companion
- Confirm the companion skill exists in
agent-skills.git/skills/<name>/. - Add a row to the registry table in
rules/companion-skills.md. Include the trigger condition (concrete), args, and the disable link. - Add the invocation in the relevant
phase-N-*.mdrule, with an## Anchorheading matching the disable link target. - Verify the workflow still degrades gracefully when the new companion is missing (uninstall the companion locally, run a task, confirm it skips).
- Update the install commands in
SKILL.md,README.md, andinstall.shif the new companion should be in the recommended install set.
Removing a companion
- Delete the row from
rules/companion-skills.md. - Delete the invocation block in the relevant phase rule.
- (Optional) Note in
CHANGELOG.mdso users know.
Why some companions can't be disabled
No companion is non-removable.
The Full tier's one mandatory gate is the deterministic brief validation in
aw/rules/full-tier.md plus the sealed
run-checks.mjs gate, and neither is a companion — they cannot be uninstalled.
Skill companion for the review pass
Every tier reviews once, locally, before the PR: review-loop in local mode
(branch-reviewer → apply → polish simplify, zero GitHub calls), run by
create-pr Step 5.5 on Micro/Lite and by aw's Full Step 3.
Nothing is posted to the PR unless the user passes --pr-review, which turns on
create-pr Step 6.5's one posted pass; Phase 7 runs no review.
The rule lives in aw/SKILL.md#review.
Detection is implicit — Skill() raises if the skill is missing; catch and log.
The full registry entry, dispatch contract, and rationale live in
rules/companion-skills.md#agent-companions
and aw/SKILL.md#review.
The feature-pr-verifier agent is dispatched as subagent_type: feature-pr-verifier
by the aw dispatcher at PR open, not by Phase 7 after CI green — that trigger
was never reached in the analysed executor transcripts: the executor's done-condition
needs Phase 7 to have run once, not CI to be green, and it holds no dispatch tool of its own. It is the only remaining agent
companion in the registry. When adding new agent companions, mirror the same
pattern: dispatch from the session that holds the dispatch rung, detect by
capability (the dispatch tool accepts the agent type — never a file at an install
path), and report a miss by name as not run (<reason>) rather than skipping it.
The .agent/ artifact directory
Artifacts (Full Mode plan.md and walkthrough.md) live in
.agent/{branch-name}/ inside the worktree. Not in .gw/ (that's the gw
CLI's territory for its own config). Not on the main branch (artifacts are
worktree-scoped — committing them to main creates context confusion).
The directory name .agent/ (singular) was chosen to align with the
~/.agents/skills/ cross-tool discovery convention used by Codex, Cursor,
OpenCode, and other Agent Skills–compatible clients. Naming consistency
across the ecosystem is the goal — so other tools can adopt the same artifact
location if they want to.
Earlier versions used .gw/ because the workflow was tied to gw-tools.git.
That coupling is gone in v3. The .gw/ reference now appears only in
migration notes and "never use this for artifacts" reminders.
The mode-aware stuck-loop cap (3 / 5) and auto-replan
The two most important numbers in this skill are 3 (Lite cap) and 5 (Full cap), and the most important pattern is auto-replan-then-escalate.
Earlier versions of the workflow let agents iterate on a failing test for up to 20 attempts before stopping. Empirically, the agent rarely converges past attempt 3 on the same area — when it does, it's almost always wrong (it's fixing symptoms, not root cause). Continuing past the cap means burning tokens on hallucinated fixes that the user is going to throw away anyway.
v3.2 split the cap by mode (Lite is for simpler tasks; Full Mode tasks are more complex and benefit from one extra attempt) and added an auto-replan guard before mandatory user escalation, drawing on the Plan-and-Act and IoRT literature on replanning when stuck.
The protocol:
iteration_cap = 3 (Lite Mode) | 5 (Full Mode)
auto_replan_used = False
while not all_tests_pass:
iterations_on_same_area += 1
# Before each iteration ≥ 2: lightweight self-reflection (R5)
if iterations_on_same_area >= 2:
if not (attempt_meaningfully_different and understood_prior_failure):
goto: stuck_loop_detection # bias toward replanning early
if iterations_on_same_area == iteration_cap:
stuck_loop_detection:
Skill("confidence", "analysis")
if confidence_score >= 90%:
→ escalate to user with findings
else if not auto_replan_used:
re_trace() # entry → exit; re-state the root cause
Update affected plan.md sections
iterations_on_same_area = 0
auto_replan_used = True
resume Phase 4 ONCE MORE
else:
→ mandatory user escalationPhase 4 testing is where this fires most often, but the same logic applies anywhere the agent is iterating on the same problem.
When changing the cap numbers, update all of:
rules/phase-4-testing.md(## Stuck-Loop Detection)rules/safety-guardrails.md(## Stuck-Loop Limit (Phase 4))rules/companion-skills.md(## Stuck-Loop Protocol)rules/error-recovery.mdrules/overview.mdSKILL.mdCore Principles + companion table (Phase 4confidencetrigger)README.mdKey Principles + companion table (Phase 4confidencetrigger)templates/aw-executor.agent.md— How to work (stuck loop)templates/_deprecated-single-agent.md— DEPRECATED but update for consistencyreferences/iterative-refinement.md— the worked stuck-loop example referenced from phase-4 must reflect the canonical limits (the "Different rule for stuck-loop iteration" callout under "When to Stop Iterating").
Otherwise the limits drift across surfaces and the agent gets contradictory instructions.
Tier detection (Micro / Lite / Full) and the aw dispatcher
Every task starts with tier detection. The decision changes which artifacts are
produced, which companions run, and whether aw writes a brief and hands it to aw-executor.
The criteria live in SKILL.md Step 1
and nowhere else — see "exactly one home" below. What this section owns is the
shape of that decision, which is what a reader of the design intent needs:
- It is a four-question walk, not a lookup. The first
yesselects the tier, and the table below the walk only describes its outcomes — where the two seem to disagree, the walk wins. That asymmetry is stated in Step 1 itself because thetier-routingL2 suite's misses were readers resolving the table against the walk and picking the table. - Complexity is the primary signal; file count is the tie-breaker. Questions 1 and 2 (architectural / cross-cutting; unfamiliar code or an unknown cause or location) fire before the 4+-file question, so an investigation whose eventual patch might be one line is still Full — tiering on the guessed size of the patch is exactly what those two questions exist to prevent.
- Micro requires one file and nothing to reason about. A one-file change
carrying non-trivial logic is Lite. The
ORin question 4 is load-bearing. - Who runs it: Full is a brief plus sealed checks, worked in the caller's session
by
aw; Lite is single-pass from a shortplan.mdbrief; Micro is single-pass with no artifacts.
When in doubt, choose the heavier tier. Micro/Lite are for genuinely small changes — not for "the user said it's small." Phase 0 and Phase 2 are mandatory in every tier, Micro included.
The aw dispatcher (aw/SKILL.md — a nested skill, not an agent) is the
opt-in, single entry point that owns this decision: it reads aw-lessons,
detects the tier, and routes (single-pass for Micro/Lite, a brief plus sealed checks worked in the caller's session for Full).
It replaced the old "routing rule dispatches the planner first" behavior, which
sent Lite tasks to the planner anyway. See the two
design-intent sections below.
The tier table has exactly one home: SKILL.md Step 1. The dispatcher links
it rather than restating it. While the dispatcher was an agent it
carried an inline copy — an agent boots cold, so having the rows in the prompt
was worth something — and the copies were kept honest by a byte-comparison L1
check. A skill runs in the caller's context with SKILL.md already loaded, so
the copy buys nothing and can only rot.
Phase 0 and Phase 2 are mandatory regardless of mode. Phase 5
docs update runs in both modes (the self-improving doc loop is
cheap and matters for small changes too — they still drift docs).
Parallelization
Three places benefit from sub-agent fan-out:
- Phase 1 research (
Exploresub-agents per package/concern) — when the task is complex, parallel exploration finds context faster than sequential reads. See [rules/phase-1-planning.md#parallel-research]. - Phase 3 implementation — controlled fan-out when slices are
file-disjoint (cap 3 concurrent sub-agents). Each sub-agent MUST receive
the Sub-Agent Resource Discipline embedding. If the task does not decompose
cleanly, keep Phase 3 sequential. See
rules/parallel-coordination.md#sub-agent-resource-discipline. - Phase 7 CI fixes (
ci-auto-fixsub-agents per failed check) — cap at 2 handoffs per PR; each sub-agent has its own retry budget. See [rules/phase-7-ci-gate.md#parallel-ci-fixes] and [../create-pr/SKILL.md] Step 8.
Things to keep invariant
When editing this skill, do not break these — they're load-bearing:
- Phase 0 and Phase 2 are mandatory. Validation and worktree isolation are not optional.
confidenceat Phase 1 is non-removable. It's the only companion that must always run.- Companions degrade silently. Never make the workflow block on a missing companion (except the one above).
checks.yamlis the living contract;plan.mdis the handoff document. Phase 4 gates on the checks (they self-validate against reality);plan.mdis a self-contained-but-lean handoff artifact, not an exhaustive knowledge base. The executor writes decision/AC drift back intoplan.mdso it does not go silently stale. Plan snapshots (plan.v{N}.md) are opt-in inaw-create-plan(thesnapshotarg), not written by default.- Anchors must match disable links. Every
## Anchorheading in a phase rule that's referenced fromcompanion-skills.mdmust produce a slug matching the link. GitHub strips.from slugs (so## Foo.bar→#foobar, not#foo-bar). - Artifact paths are
.agent/{branch}/, never.gw/{branch}/. The only acceptable mention of.gw/is a migration note or "never use this" reminder. - A GitHub access path is required;
ghis one of two, andgwis optional with a native fallback. The workflow must never block on a missinggw— Phase 2 detects it at Step 0 and falls back to nativegit worktreewith a one-time warning. Nor may it block on a missinggh: that binary is absent in Claude Code cloud sessions, wheremcp__github__*is the path, andaw-executoralready carries those tools in itstools:frontmatter. Phases 6–7 resolveACCESS_PATH(gh|mcp|none) once viaagents/shared/rules/github-access.md— never bywhich gh, never bygh auth status. Withnone, GitHub steps degrade and are named inDegraded:; they are never reported as done. Do not restate that file's verb mapping in a phase rule — link it. - The system-prompt for the agent template stays lean. It references
SKILL.mdfor procedures rather than duplicating them. If the agent template grows beyond ~250 lines of system prompt, it's drifting. - The diagnostic surface is the contract that makes this skill diagnosable.
Removing or breaking
rules/diagnostic-surface.mdsilently downgrades/create-skill diagnose autonomous-workflowto its fallback (inferred fromSKILL.mdH2 sections) — fidelity drops and the diagnoser cannot reason about hard invariants. Treat the surface likecompanion-skills.md: every change to a phase, gate, taxonomy class, or load-bearing invariant must update the surface in the same PR. - Sub-Agent Resource Discipline is non-relaxable. Every sub-agent dispatch
block must embed the resource-discipline sentinel line. Whole-project
tsc,lint,build, andtestcommands are forbidden inside sub-agents and reserved for orchestrator-only boundaries (Phase 4 Step 6, Phase 6 pre-PR). Seerules/parallel-coordination.md#sub-agent-resource-discipline. awis a thin, opt-in router, and it is a skill. It detects the tier and routes (single-pass for Micro/Lite, a brief plus sealed checks worked in the caller's session for Full) and owns the universal lessons loop. It must not accrue domain knowledge, must not force Full on light tasks, and must not silently wrap casual edits. It must not regrow atools:block, amodel:line, or an inline tier table — see the shape design-intent section. On Full,awwrites the brief and works it in the caller's session; it dispatchesaw-executoronly when the user asks for a background worker or parallel briefs. With no dispatch tool, the review and the PR verifier reportnot run, never a self-review — it never downgrades to Lite.- Episodic lessons are advisory-only. An
aw-lessonslesson biases the plan but never silently changes a gate, skips a phase, or alters a cap. The only path from a lesson to changed behavior is a confidence-gated, user-approveddiagnoseapply, and promotion requiresseen_count >= 3(or an explicitstructuraltag). Never auto-apply lessons to behavior or promote on one run. Seerules/self-improvement-loop.md#entrenchment-guards-load-bearing. checks.yamldefinitions are executor-immutable; gaming a check is never a fix. The executor flipsstatus:(and amendsrun:/setup:only with a loggedcheck-run-amendedentry);id:/requirement:/ears:/expect:are owned by the brief writer. The four forbidden strategies (modify checks/tests, overload comparisons, record/replay state, special-case inputs) and theunsatisfiableabort affordance are non-relaxable. All-green checks never waive the suite,confidence,reviewer, or Phase 7 verification. Seerules/phase-4-testing.md#executable-checks-loop.- A
blockingmissing-information gap halts even under--no-confirm. The pre-authorization grant waives the Phase 0 confirmation wait, never the missing-information gate. Seerules/phase-0-validation.md#step-3c-missing-information-gate.
Diagnose participation — design intent
This skill does not implement Diagnose Mode — it implements the
diagnostic surface contract consumed by /create-skill diagnose.
The retrospective self-improvement loop itself (the seven-step procedure,
the confidence gate, the report format, the apply / PR flow) is owned by
create-skill so the same procedure can target any skill in the repo.
The split landed in v3.7. Before that, --diagnose was a flag on this
skill, with a hardcoded seven-step procedure baked into
rules/diagnose-mode.md. When fix-bug and other workflow skills started
needing the same retrospective capability, the procedure had to either be
duplicated per-skill or generalized. We chose generalize — the engine moved
to create-skill (which already has authoritative knowledge about skill
quality), and per-skill knowledge moved into a declared
rules/diagnostic-surface.md per consumer.
What this skill still owns:
- Phase model 0 → 7 — declared in
rules/diagnostic-surface.md. - Failure taxonomy (F1 +
F-novel, append-only) — same file. - Existing-guards-per-phase table — same file.
- Hard invariants the diagnoser must not propose to weaken — same file.
- Source root the diagnoser writes against —
skills/workflow/autonomous-workflow/.
What create-skill owns:
- The seven-step procedure (collect → classify → attribute → propose → gate → write → apply / PR).
- The output report format.
- The
confidence(analysis) ≥ 90 %gate before--apply. - The hard rules: one proposal per report, earliest-phase wins, mechanical > judgment, never weaken gates.
When changing a phase, gate, taxonomy class, or load-bearing invariant in
this skill, always update rules/diagnostic-surface.md
in the same PR — otherwise the diagnoser walks a stale matrix and either
misses real gaps or proposes redundant checks.
Two-tier self-improvement — design intent
v3.10 added a fast tier of self-improvement to complement the existing
diagnose slow tier. The motivation: diagnose is the right mechanism for
turning a failure into a permanent skill-source change, but it (a) only fires
when a human invokes it and (b) starts cold from a single session with no record
that the same failure happened before. The fast tier fills both gaps.
| Tier | Mechanism | Storage | Behavior change? | Gate |
| Fast (global) | LoreKit memory.* tools, tag loop::aw-lessons, scope global (read Phase 1, write Phase 4/7) | LoreKit (managed) — follows the user across every repo | No — advisory input to planning | none (privacy pre-flight only) |
| Fast (repo::) | LoreKit memory.* tools, tag loop::aw-lessons, scope repo::{owner}/{repo} | LoreKit (managed) — repo-scoped; LoreKit's mode decides private / synced / committed | No — advisory input to planning | none (privacy pre-flight, stricter because a repo scope is team-visible) |
| Slow (global → skill source) | /create-skill diagnose autonomous-workflow | this skill's source | Yes — a rule / gate / trigger for every consumer | confidence(analysis) ≥ 90 % + user approval |
| Slow (repo:: → repo rules) | Skill("docs", "update --add-rule …") | the cwd repo's CLAUDE.md / .claude/rules/ | Yes — a rule for everyone working in that repo | confidence(analysis) ≥ 90 % + user approval |
The fast and slow tiers are connected by a recurrence gate: a lesson
reaching seen_count >= 3 (or tagged structural) is promotion-eligible.
The scope of the lesson determines the promotion target: a global lesson
promotes to the skill's source (every consumer benefits via the next install);
a repo:: lesson promotes to the cwd repo's own rules (every teammate
working in that repo benefits via the next git pull). The workflow surfaces a
one-line suggestion in either case — it never acts silently. The full
contract, lesson schema, classification rule, scope mapping, and the
entrenchment guards live in
rules/self-improvement-loop.md.
Why a fast tier that doesn't change behavior? Because the dominant risk in
any reflective-memory loop is self-reinforcing error (Reflexion's documented
failure mode; the SSGM governance literature). Letting a single run rewrite the
skill is exactly that failure. The fast tier captures lessons cheaply and
reversibly; only recurrence-proven lessons earn a permanent, human-approved
change. The fast tier is a fully optional companion — disconnect LoreKit's
memory.* tools and it degrades to nothing while diagnose keeps working.
Design rule for the loop: keep domain knowledge out of this skill. The lessons themselves live in LoreKit, not in the workflow's rules. The workflow only owns when to read / write / promote — the same orchestrator discipline that governs every other companion.
The dispatcher is a skill, not an agent — design intent
v3.23 converted aw from an agent (templates/aw.agent.md, symlinked to
~/.claude/agents/aw.md) into a nested skill (aw/SKILL.md, invoked /aw).
The routing decision, the tier table, the Micro/Lite single-pass path, the
lessons loop, and the single-context Full fallback are unchanged — only the
shape moved. aw-executor remains an agent.
Why. This repo wrote the deciding test before aw existed, in
references/anthropic-architecture-research.md §2.2:
any future proposal to add a third agent must demonstrate a third independent context — not a third role. If the third agent would re-read the same
plan.mdand the same diff that the executor already has, it is a skill, not an agent.
aw was that third agent, and its context boundary is conditional: real when
the routing rule fires mid-conversation (Micro/Lite edit churn stays out of the
user's window), absent when a developer opens a session specifically to run
/aw — where there is nothing to protect, and the single-threaded-continuity
argument this skill already cites for making Micro/Lite single-pass argues
against isolating them at all. aw-planner / aw-executor pass the same test
unconditionally (the planner's exploration history is genuine dead weight for
the executor, and plan.md is a real cold-read handoff), which is why they were
not touched.
Three costs the agent form was paying, all removed:
- It burned the delegation rung the executor needs.
awheldTask;aw-planner/aw-executordid not. Three documented behaviours were therefore unreachable by construction — the Phase 1 parallelExplorefan-out, the Phase 3 file-disjoint fan-out (cap 3), the Phase 7ci-auto-fixfan-out (cap 2) — and so wascreate-pr's Phase 6review-looppass, which is what produced theNOT REVIEWEDdraft PRs recorded inaw-lessons(executor-context-lacks-subagent-dispatch-skips-review-loop,seen_count2). With the dispatcher in-context, both agents are dispatched from the top-level session — the rung that observably keptTask— so v3.23 grants themTask. Belt-and-braces:awstill re-runsreview-loopitself when the executor reports the pass as skipped. - A duplicated tier table with a CI guard to police it. L1 Check B
byte-compared
aw.agent.md's copy againstSKILL.mdStep 1. The duplication was an artifact of the shape, not of the domain. There is now one copy and a link to it, so there is nothing to compare. - A triplicated tool grant. The agent enumerated 4 LoreKit + 11 GitHub tools
with two paragraphs explaining that sub-agents inherit neither MCP tools nor
gh. A skill inherits the caller's grant.
Costs accepted, stated plainly:
- No
model:pinning. The agent pinnedmodel: opus; a skill runs on whatever the session is using. - Micro/Lite transcripts land in the user's window. Previously isolated. This is the conditional-boundary trade above, taken deliberately.
- No
tools:block.awcannot grant itself anything. Its obligation is to degrade visibly instead — a missingmemory.*,gh, or GitHub MCP grant is named in the terminal contract'sDegraded:line, never silently swallowed. - Existing installs get a dangling
~/.claude/agents/aw.mduntil they re-runinstall.sh, which removes it (the same legacy-symlink cleanup the pre-aw-namespace rename used). Deleting the agent file outright, rather than leaving it deprecated in place, is deliberate: twoawentries with near-identical auto-trigger descriptions is a worse failure than a dangling symlink.
Design rules that keep this from rotting:
- Do not re-add a
tools:block, amodel:line, or an inline tier table toaw/SKILL.md. Each one is a step back toward the agent form; the first two are meaningless in a skill and the third can only rot. - Do not convert
aw-executorto a skill. It passes §2.2 on its own merits: it is the background worker for an explicit background or parallel request, with the brief as its cold-read input. The default Full path works in the caller's session and dispatches only the fresh-eyes reviewer. - Do not reintroduce a planning agent. The Full brief is written in the
caller's context, which holds the conversation; a separate planner spent ~45
minutes on a 333-line plan in a three-way comparison and added nothing the
brief and the corrections do not — see
aw/references/dispatcher-rationale.md. awstill must not accrue domain knowledge. The ~200-line ceiling and the thin-router invariant below apply unchanged — the shape changed, the discipline did not.
One natural-language entry point — design intent
v3.24 made aw the sole natural-language destination. Before it, two skills
competed for the same request: aw's description advertised "autonomously",
"end-to-end", "in a worktree", and the parent autonomous-workflow's
description advertised near-identical phrasing ("autonomously",
"independently", "end-to-end", "in isolation", "take care of this"). The
harness matches descriptions; nothing arbitrated between them.
The cost of losing that race is not cosmetic. A request landing on the parent
runs the phase machinery with tier detection skipped (so a Micro typo fix
pays the Full brief→executor handoff, or a Full task runs single-pass with no
plan.md and no sealed checks) and the universal lessons loop
skipped (the read and write were hoisted to the dispatcher in v3.12 precisely
so every tier contributes). Those two are the dispatcher's entire job, so
bypassing it silently un-does the v3.12 design.
The fix is one-directional: the parent's description now states what it is (the
phase machinery), states that it is not the entry point, and names aw — while
quoting no trigger phrase and making no Triggers on / Use when claim.
/autonomous-workflow still runs the machinery directly for anyone who wants to
bypass tier detection deliberately; the marker in the repo inventory moved
auto → / to say so.
Why the routing rule still carries the full trigger list, even though it now
duplicates aw's description: frontmatter cannot link a canonical home the way
aw/SKILL.md links the tier table, so one of the two surfaces has to hold the
words — and this file is also the live rubric the L2 aw-should-trigger suite
reads (scripts/eval/l2.mjs passes the whole file), so slimming it to a pointer
would leave that suite with no vocabulary to decide trigger on. The
duplication is forced by the two consumers, so it is kept honest by review
instead of eliminated.
Two properties keep it honest:
- The parent's description quotes none of the trigger vocabulary and makes no
Triggers on/Use whenclaim. Only the claiming forms (a quoted phrase, or those two clauses) count, because the sentence that fixes the problem — "a natural-language request to do work autonomously … belongs to theawskill" — necessarily names the words it is disclaiming. - Every phrase
awadvertises appears in the routing rule. Whether a phrase actually routes is behaviour, measured by the L2aw-should-triggersuite, not by a text-sync check.
Design rules that keep this from rotting:
- Never add trigger vocabulary back to the parent's description. If a phrase
should fire the workflow, it goes in
aw's description and the routing rule, in the same change. - Never slim the routing rule's positive trigger list to a pointer. It is
the L2 rubric; a pointer would silently gut the
aw-should-triggersuite.
Adaptive dispatch (the aw dispatcher) — design intent
v3.11 added aw — a thin, opt-in dispatcher — to resolve two tensions at
once. (It shipped as a third agent and became a skill in v3.23; the section
above covers that move. The two tensions below, and the design rules that
follow, are shape-independent and unchanged.)
- One entry point, but not always-heavy. Developers wanted a single thing
to invoke. But "always write a brief and dispatch an executor" is the wrong answer: the
research is explicit that always-planning wastes compute and degrades
long-horizon performance (Learning When to Plan, arXiv 2509.03581), and
single-threaded continuity beats the multi-agent handoff for simple/sequential
work (Cognition's context-engineering argument; single-agent ≥ multi-agent
under equal token budgets). So
awis adaptive: it detects the tier and only pays the brief→executor handoff cost on Full, where context isolation + a resumableplan.mdactually earn it. - Universal self-improvement without universal planning. The fast-tier lessons loop only helped tasks that ran the Full phases. Hoisting the loop's intake-read and exit-write to the dispatcher makes every tier contribute and benefit — even a Micro typo fix — which is the actual goal ("more stable agents after more runs"). Planning depth and learning coverage are now decoupled.
Design rules that keep this from rotting:
awstays thin. It routes and owns the loop. It must not accrue planning/coding domain knowledge — that lives in the skill, companions,rules/corrections.md, and the executor. The target is ~200 lines of body (create-skillanti-pattern S1 is a god-skill). This target is currently breached and has been for several versions — the dispatcher is ~294 body lines as of v3.23 (it was ~274 as an agent), because each of v3.19 single-context Full, v3.21 follow-ups, and v3.23 skill-semantics + review-recovery added a section without one being removed. Recorded rather than quietly re-baselined: the next contributor to touch this file should push down, and the reduction most likely to pay is moving the single-context Full procedure into a rule file the way the lessons loop already is.- Opt-in, not a wrapper.
awruns because the user phrased autonomous work or invoked/aw. It must not intercept casual single-file edits, questions, or interactive coding. The routing rule's exclusion list enforces this. - Full works in the caller's session. On Full,
awwrites the brief, works to its sealed checks itself, and dispatches onebranch-reviewerthat did not write the code;aw-executoris dispatched only for an explicit background or parallel request. Never route Micro/Lite through the executor (pure handoff overhead). Without a dispatch tool the review is reportednot run, never replaced by self-review. It is never a license to skip an available dispatch — the check is "can I dispatch?", not "do I feel like it?". - "Can I dispatch?" is a capability question, and the tool's NAME is not the
answer. The Claude Code CLI calls it
Task; the Claude Agent SDK harness behind Claude Code on the web and in cloud sessions calls itAgent. Every availability check acrossaw,review-loop, andpr-reviewtherefore asks whether any available tool dispatches a sub-agent, never whether one spelling is present. A name check fails in the direction that hides itself: it routes a fully dispatchable session into the single-context fallback and the degraded review path, both of which report as legitimate outcomes. This is not the rejected capability probe below — it decides nothing about whether to run a companion, it only reads the name of a tool the context already holds, and every branch it feeds fails closed (toward a namedNOT REVIEWED, toward single-context Full), never toward a silent skip. - Micro reuses the Lite phase path. Micro is a routing tier, not a fourth set of phase rules — it follows Lite's phase behavior with planning and quality companions skipped. This keeps the phase rules from needing a third column.
Plan-quality gates + executable checks — design intent
v3.15 added four planning-quality mechanisms, each mapping one researched
failure mode to the earliest phase that can catch it (full evidence base:
references/planning-quality-research.md):
| Mechanism | Failure mode addressed | Where | Enforcement |
| Restate-and-diff | Specification misalignment — the model plans against its perception of the spec, not the spec | Phase 0 Step 3b | Procedure + checklist (human-in-loop) |
| Missing-Information Gate | Hallucinated requirements — guessing where information is absent | Phase 0 Step 3c | blocking halts even under --no-confirm (hard invariant) |
| Existing Code Survey | The "implement-box": re-implementing existing functionality as semantic clones review doesn't catch | Phase 1 / plan Extended section | aw-create-plan trigger (deterministic; create ⇒ survey) |
Traceability + checks.yaml | Silently dropped requirements; "criteria met" judged instead of verified; verifier gaming | Phase 1→2 authoring, Phase 4 loop | Rules #9/#11 (deterministic) + check-integrity hard invariants |
Design rules that keep this from rotting:
- The brief's Core is six headings.
plan.md's Core is Task, Requirements, Guardrails, Acceptance Criteria (Definition of Done), Turn Cap, and File Changes (L1G130aruns the executor's bail grep against the template); everything else is Extended and Full-tier only. Traceability is embedded in the Acceptance Criteria (AC-{n}+covers:), and the survey is an Extended section with a deterministic trigger. The executor's bail check also accepts fix-bug's fast-lane plan, which still carries the legacy eight headings (L1G130b), and the Definition of Done is the one linerun-checks.mjsprints (L1G130c). checks.yamlis additive, never a replacement. It mechanizes the Acceptance-Criteria sprint contract; the suite,confidence,reviewer, and Phase 7 verifiers are unchanged. The check-integrity rules exist because verifier-driven loops are demonstrably gameable (models special-case test inputs and edit tests to force green; an explicit abort affordance is the strongest counter-lever, and it must be prompted for explicitly because Claude under-uses it by default — see research §5).- Backward compatible by absence. No
checks.yaml→ the executor logs one line and gates on ACs by judgment (pre-v3.15 behavior). Plans withoutAC-{n}IDs (fix-bug fast-lane, legacy) skip rule #11 with a logged note. - The brief pins contracts, not implementations.
ears+expectare exact;runis a draft the executor finalizes (logged). Pinning full check bodies upfront would re-introduce the cascading-error failure mode (§2.8).
Artifact lightening — design intent
v3.18 rebalanced the Full-Mode artifacts around one distinction: a written plan does two different jobs, and only one is well-evidenced.
- Within-run handoff (brief → executor). The executor is a fresh agent
with no access to the caller's context, so it needs a self-contained
plan.mdto start. This is load-bearing — it is why the handoff exists (see §2.3 / §2.12 ofreferences/anthropic-architecture-research.md). - Cross-session resumption (a later session picks up cold). This is the benefit the plan file is usually justified on, and it is the weakest-evidenced one — §5.2 concedes the marginal benefit over in-context planning is unproven for a task that finishes inside one un-compacted window.
The 2024–2026 practitioner + research consensus (Cursor's ephemeral-by-default plans, planning-with-files' consumed-every-turn plan, Kiro/spec-kit's ceremony-is-overkill-for-small-tasks finding, Fowler's spec-anchored tier, and the stale-plan drift literature) points at four moves, all adopted here:
checks.yamlis the primary, living contract. Prose rots faster than reality; an executable check cannot drift silently. So the framing everywhere now leads with checks, and the VS Code extension surfaceschecks.yamlfirst, expanded, aboveplan.md.plan.mdis a lean handoff document, not a knowledge base. Kept self-contained (the cold-read guarantee the brief validation enforces), but the brief is not padded against every hypothetical question — the executor discovers details while it works, and the user can be asked.- The executor consumes and repairs the plan. The dominant failure of a
written plan is going write-only and stale, so Phase 3 now mandates a
drift write-back: when a decision or AC changes mid-run, update the affected
plan.mdsection (and itschecks.yamlentry), not just the Progress Log. plan.v{N}.mdsnapshots are opt-in..agent/is gitignored per-developer scratch, so an immutable version chain is a second, weaker VCS for the same file — directory noise plus a redundant write per iteration, rarely re-read, with no measured task-success benefit (§5.4).aw-create-planwrites onlyplan.mdby default; thesnapshotarg opts back into the chain.
Design rules that keep this from rotting:
- Do not drop the cold-read guarantee.
plan.mdmust stay executable-from-cold for the Full-tier handoff — a lean brief is never a license to write an incomplete one. checks.yamlintegrity is unchanged. Elevating it to "the contract" does not relax the executor-immutable / no-gaming /unsatisfiable-abort rules.- Snapshot opt-in is additive, backward-compatible. Snapshot mode reproduces
the pre-v3.18
plan.v{N}.mdbehavior exactly; the extension already renders the versions group only when snapshots exist, so default runs simply show none.
Confidence-gated autonomous action — design intent
The pattern v3.6 established remains: autonomous actions that change code or skill source are allowed inside the loop, but only behind a confidence gate. Two instances exist today; in v3.7 the first relocated but the contract is unchanged.
| Instance | Confidence mode | Threshold | Action gated |
/create-skill diagnose <skill> --apply | confidence(analysis) | ≥ 90 % | git apply of a proposed change to the target skill's source |
tdd provenance fix in loop | confidence(code) | ≥ 90 % | Extract-and-rewrite refactor of production code to fix a test |
Both instances share three contracts:
- No autonomous action without a passing gate. Below threshold, the action is refused and the existing escalation path (stuck-loop, user prompt, or report-only artifact) takes over.
- Mechanical post-checks complement the judgment gate. Confidence scores intent; mechanical checks (build, tests, mutation re-verify) confirm the action was implemented correctly.
- Human override is explicit, not silent. Manual flags
(
--no-confidence-gate, user-confirmation prompts) exist so a human can deliberately bypass the gate — but the autonomous loop never sets them.
When adding a new self-modifying action, follow the same template: choose a confidence mode, pick a threshold (default 90 %), gate the action, and document the failure cascade. Resist the urge to skip the gate "just this once" — the agent's gates are the only thing standing between autonomy and going rogue.
Working on the skill
Editing a phase rule
- Read
SKILL.mdandrules/companion-skills.mdfirst to refresh the contracts. - Make the change. Keep the rule file self-contained — an agent should be able to load this one file plus the two above and execute the phase correctly.
- Verify anchors still match disable links (
grep -E "phase-.*\.md#" rules/companion-skills.md). - If the change affects companion behavior, update
rules/companion-skills.mdin the same PR.
Editing the dispatcher
The dispatcher is aw/SKILL.md — a nested skill, discovered by
scripts/sync-symlinks.sh's recursive walk and linked as ~/.claude/skills/aw
(the same treatment aw-tester-chrome gets; install.sh also
links it directly in --development mode). It is edited like any other skill,
and it is not an agent — do not give it a tools: block or a model: line,
and do not restate the tier table in it. See
the shape design-intent section
for why. It must stay
thin (router + loop only) — see the ~200-line body target and its current
breach under
design rules.
Editing the agent templates
aw-executor.agent.md and aw-tester.agent.md are
what get symlinked into ~/.claude/agents/ as
aw-executor.md and aw-tester.md by install.sh (the aw- prefix is the
autonomous-workflow namespace — keeps the agents grouped together and
unmistakable when listed alongside unrelated agents). Keep both lean — they
should reference SKILL.md and rules/companion-skills.md rather than
duplicate their content.
The agent name: frontmatter values must match the symlinked file
basenames (aw-executor, aw-tester) — Claude Code dispatches by the
frontmatter name, and the routing rule references it by the same string.
If you ever rename the namespace, update all four (frontmatter name,
install.sh symlink target, routing rule dispatch, and every doc reference)
in the same PR.
aw-executor holds Task so its documented fan-outs — research and Phase 3
file-disjoint slices (cap 3), aw-tester spec runs, Phase 7 ci-auto-fix, and
create-pr's review-loop pass — are reachable at all.
It carries no model: line, so it runs on the caller's model. Do not remove the grant without also
removing those behaviours from the phase rules; they were dead letters before.
The deprecated _deprecated-single-agent.md (single-agent) is still present for backward
compat but is not linked by install.sh. Do not add new behavior there.
Testing changes end-to-end
There's no automated test suite for this skill. The validation pattern is:
- Symlink the skill locally (
bash install.sh --globalor--project). - Run a small Lite Mode task — verify Phase 0 + Phase 2 + Phase 5 + Phase 6 companions all fire correctly.
- Run a larger Full Mode task — verify
plan.mdandwalkthrough.mdare generated, the brief validates and the checks gate, stuck-loop respects the mode-aware cap (5 iterations in Full Mode).
If you change the stuck-loop number, mode-detection criteria, or the companion list, do both runs.
aw dispatcher smoke test (run after any dispatcher / tier-routing change)
The dispatcher's two load-bearing runtime behaviors have no static check —
they must be exercised live (markdown can't prove them). Run this after editing
aw/SKILL.md, the tier table, or the routing rule:
- Install the dispatcher skill + the agents:
bash install.sh --developmentand confirm both chains resolve —readlink ~/.claude/skills/aw(the dispatcher) andreadlink ~/.claude/agents/aw-executor.md. Also confirm~/.claude/agents/aw-planner.md(the retired planning agent) and~/.claude/agents/aw.mdare gone (the pre-v3.23 agent symlink; install.sh removes it). A survivingaw.mdmeans twoawentries compete for the same trigger phrases. - Micro routing (single-pass, no split): invoke
/awon a 1-file mechanical change (e.g. fix a typo in a README). Expect:MODE SELECTION: Tier: Micro, noaw-executordispatch, a worktree + draft PR, noplan.md. - Full routing (dispatch from the caller's context — the R1 risk): invoke
/awon a 4-file / architectural task. Expect:Tier: Full, then a short brief (plan.md+ sealedchecks.yaml) written in the caller's window, then the work in that same window — noaw-executordispatch — and one localreview-loopbefore the PR, which must not report itself skipped while a dispatch tool exists. If the harness refuses sub-agent dispatch entirely, confirmawstill writesplan.mdwith sealed checks, reportsreview: not run (sub-agent dispatch unavailable), and does not downgrade to the Lite/Micro single-pass path. - Universal loop + two-scope writes (the R2 risk): run two checks against
LoreKit (
memory.search { q, scopes: ["repo::{owner}/*", "global"], tags: ["loop::aw-lessons"] }to inspect).- Universal lesson: after a run where the lesson is generic (e.g. an Applies when line like
*.tsxormonorepo refactor), confirm the lesson was written to theglobalscope (tagloop::aw-lessons) and NOT torepo::{owner}/{repo}. If it landed in the repo scope, the classifier mis-routed a universal lesson. - Project-bound lesson: run a task that produces a repo-bound lesson (an Applies when line referencing a repo path) and confirm the lesson lands in the
repo::{owner}/{repo}scope — NOT inglobal. If it landed inglobal, the classifier is broken. - Storage delegation: confirm the workflow never creates directories or commits lesson files in the cwd repo — where a
repo::lesson physically lives is LoreKit's control model (remote/ local.lorekit/), not the loop's. The loop must only callmemory.writewith a scope.
- Universal lesson: after a run where the lesson is generic (e.g. an Applies when line like
- Opt-in boundary: in an interactive session, make a casual single-file edit
without a trigger phrase or
/aw. Expect:awdoes not engage.
Steps 3 and 4 are the gate — they cover the only two behaviors that reading the source cannot verify.
Coupled documentation
This skill's behavior is described in three coordinated files. When changing runtime behavior, update all three:
| File | Audience | Purpose |
SKILL.md | Runtime agent | Thin index, mode detection, companion table, install commands |
README.md | End user | Install, customize, disable companions, migrate from v2 |
CLAUDE.md (this file) | Developer / future-you | Intent, design rationale, working on the skill |
Phase rules and companion-skills.md are runtime-agent-facing; install.sh is end-user-facing; this file is contributor-facing.
History
- v3.26.0 — Step 1's tier walk says out loud which of its two halves wins,
after the
tier-routingL2 suite measured 25/30 with all five misses under-tiering (aFulllabelledLite, fourLitelabelledMicro). The scorer was ruled out first, empirically: the run prints each miss's raw reply, and those replies show the model filling in theMODE SELECTION:block with a considered tier, not a parse artifact. So the rubric was the defect, in three specific places:- The walk and the table could disagree, and the table read as the authority. Q4 says "2–3 files, OR any non-trivial logic change ⇒ Lite" while the table's Lite row said "2–3 files AND simple" — a one-file logic change satisfies the walk and fails the row. Step 1 now states that the walk decides and the table only describes its outcomes, and the Lite row carries the one-file case explicitly.
- Micro's bar was one condition, not two. "1 file, purely mechanical" reads as a file count with a parenthetical; it is now "1 file and purely mechanical", with the three worked examples (add a prop and forward it, add a behaviour-changing CLI flag, debounce an input) that are Lite at one file.
- Q2 covered unfamiliar code but not an unknown location. A task whose cause or file set is unknown until it is investigated was being tiered on the guessed size of the eventual patch. Q2 now names the investigation case and the Full row says "cause or location unknown". The design-intent copy of the tier table in this file is gone — it had drifted to contradict Step 1 on both the Lite and the Full row, which is the exact failure the "exactly one home" rule below exists to prevent, and it sat 30 lines above that rule. This section now carries the decision's shape and links Step 1 for the criteria.
- v3.25.0 — Dispatch availability is a capability, not a tool name; and
aw's review recovery stops re-running the dispatch that just failed. Field report from a cloud session: a Full run delivered a draft PR withNOT REVIEWED, and the recovery path fired but recovered nothing. Two independent defects, both empirically confirmed by probing this harness rather than reasoned about:- The capability gates were name checks.
review-loop's Step 0 precondition read "check whetherTaskappears in your available tools", andpr-reviewandawcarried the same literal in eight more places. The Claude Agent SDK harness behind Claude Code on the web and in cloud sessions holds the capability and spells the toolAgent, so the gate concluded "no dispatch available" and skipped the review on a PR that was fully reviewable. The failure hid itself: a skip is a documented legitimate outcome, so nothing downstream contradicted it. Every check now asks whether any available tool dispatches a sub-agent — a tool taking asubagent_type(or equivalent) parameter is the dispatch tool whatever it is called — and each file states the anti-pattern as a code example so the name check reads as a defect rather than as the rule. aw's review recovery was a no-op in the case it exists for. It invokedSkill("review-loop", …)bare, so whenawitself held no dispatch tool the loop skipped at iteration 0 exactly as the executor had. The recovery is now a two-row table keyed onaw's own capability, with the no-dispatch row passing--external-review(deliberately, by the caller, which is the shapereview-loop's caller contract sanctions) so the loop waits for whatever reviewer is posting and still applies, resolves, and converges those threads.--criticalis dropped on that row: it only ever configuredpr-reviewer, and the loop warns and ignores it.- This is not the capability probe rejected in v3.22. That probe's premise
was falsified and it would have gated quality companions failing open.
This reads the name of a tool the context already holds, gates nothing, and
every branch fails closed — toward
--external-review, toward single-context Full — never toward a silent skip. - Also fixed in
review-loop: the sub-step A comment claimed "the loop always ENDS on a review pass"; two of its four exits (the no-progress guard and the cap) fire after a push, not a review. And the post-loop report keyed onITERATION == CAP, which is also true of a report-only run (--no-feedbackforcesCAP=1) and of a clean convergence on the last allowed iteration — both were reported as "cap reached". Exits now set an explicitSTOP_REASONthe report reads instead of re-deriving one from the iteration count.
- The capability gates were name checks.
- v3.24.0 —
awbecomes the only natural-language entry point. v3.23 made the dispatcher a skill but left the parentautonomous-workflowskill's description advertising the same trigger vocabulary, so two skills competed for one request and the harness had nothing to arbitrate with. Losing that race skips tier detection and the universal lessons loop — the dispatcher's entire job. Full rationale and the design rules: design intent.SKILL.md's description rewritten to describe the phase machinery, state that it is not the entry point, and nameaw— quoting no trigger phrase and making noTriggers on/Use whenclaim./autonomous-workflowstill runs the machinery directly for a deliberate bypass.templates/routing.rule.mdgained"implement autonomously"(the phrasing deleted from the parent needed a home —G2dcaught its absence on the guard's first run) and a note stating thatawis the only natural-language destination, why the duplication withaw's description is forced, and thatG2dkeeps the two honest.- New L1
G2d, two halves. Half 1: the parent quotes no trigger phrase and makes no trigger claim — matched on the claiming forms, since the sentence that fixes the problem must name the words it disclaims. Half 2: every phraseawadvertises exists in the routing rule. Its phrase-count sentinel is pinned to the live count (14), not a floor — the loose-floor defect a reviewer caught inG2c, verified by mutation. - Inventory marker
auto→/forautonomous-workflowin the rootCLAUDE.mdandREADME.md;awkeepsauto. - Deliberately NOT changed: the routing rule's positive trigger list stays
in full (it is the live L2
aw-should-triggerrubric — a pointer would gut that suite), the exclusion list, the continuation phrases, the tier table's single home, and every gate.
- v3.23.0 — The dispatcher becomes a skill.
awmoved fromtemplates/aw.agent.md(symlinked to~/.claude/agents/aw.md) toaw/SKILL.md(a nested skill, invoked/aw). Routing behaviour, the tier semantics, the Micro/Lite single-pass path, the lessons loop, the follow-ups rule, and the single-context Full fallback are all unchanged — only the shape moved.aw-planner/aw-executor/aw-testerremain agents. Full rationale and the accepted costs: design intent.- Why:
awwas the third agent §2.2 ofreferences/anthropic-architecture-research.mdwarned about — its context boundary is conditional (real on auto-routing, absent when a developer opens a session to run/aw), unlike the planner/executor boundary, which is unconditional. It was paying three costs for that: a burned delegation rung, a duplicated tier table with a CI guard to police it, and a triplicated tool grant. aw-plannerandaw-executorgainedTask. Four documented behaviours were unreachable by construction while the dispatcher occupied the top rung — Phase 1Explorefan-out, Phase 3 file-disjoint fan-out (cap 3), Phase 7ci-auto-fixfan-out (cap 2), andcreate-pr's Phase 6review-looppass. The last is the one with a field report:aw-lessons::executor-context-lacks- subagent-dispatch-skips-review-loop(seen_count2, confidence 92), whose recorded symptom isNOT REVIEWEDdraft PRs.awadditionally re-runsreview-loopitself when the executor reports the pass as skipped.- The tier table now has one home. L1 Check B byte-compared the
dispatcher's copy against
SKILL.mdStep 1; it is replaced byG2b, which asserts the absence of a second copy plus a link to the canonical one. The L2tier-routingsuite readsSKILL.md § Step 1directly. - New L1
G24b— the skill-shaped counterpart ofG24. A skill cannot grant itself tools, so its obligation is to degrade visibly:aw/SKILL.mdmust state that it inherits the caller's grant and that a missing tool is named inDegraded:.G24's sentinel drops 3 → 2 accordingly. install.shstops linking the agent, links the dispatcher skill in--developmentmode, and addsaw.mdto its legacy-symlink cleanup so an upgrading install does not end up with both anawagent and anawskill competing for the same trigger phrases.scripts/sync-symlinks.shgainsawinAW_SKILLS.- Costs accepted: no
model: opuspinning, Micro/Lite transcripts land in the user's window, and a dangling~/.claude/agents/aw.mdon installs that never re-runinstall.sh. All three are argued in the design-intent section. - Deliberately NOT changed: the planner→executor split (it passes §2.2 on
its own merits), the tier table's content, the
confidence(plan)gate, everychecks.yamlintegrity rule, and the routing rule's trigger vocabulary and exclusion list.
- Why:
- v3.22.0 — Bounded waits, a stateless CI gate, an honest
review-loopskip, and a terminal contract foraw. Field report:awruns on Claude Code for web/mobile stall — long silent stretches, never terminating until the user interrupts. Diagnosis, including the record of a rejected design, inreferences/cloud-stalling-analysis.md.- Every wait is bounded at both levels. The subtle half: the Bash tool
defaults to 120 000 ms and 600 000 is opt-in, so
timeout 1800andtimeout 540fail identically unless the call also passestimeout: 600000— the harness kills it before the innertimeoutfires and the documentedexit 124handling is dead code. All nine external-wait sites now state both, enforced per-site by new L1 check G22 (proximity-scoped so a second site cannot free-ride on a first's mention; count pinned; mutation-tested four ways). - Phase 7 queries CI state instead of carrying it. One stateless
gh pr checks(no--watch) at the current head decides whether to watch at all. Retry caps are counted within one skill invocation; nothing is shared across phases or subagents. New hard invariant watch state is queried, never carried records why, because the first implementation of this change did the opposite and had to be reverted (see below). gh pr checkssemantics are now stated — it exits non-zero while merely pending (so classification is by exit code plus literal stderr match, never by output volume), and it does not wait for checks that do not exist yet (so a bounded registration poll precedes the watch; the old baresleep 10was silently covering this).review-loopself-reports a clean skip when sub-agent dispatch is unavailable, with aNOT REVIEWEDslot increate-pr's report. Deliberately not an in-context substitute —pr-reviewer's independence comes from the isolated context.awgainedAW RUN COMPLETEwith a mandatoryDegraded:line, present even in the Micro/Lite one-line collapse.- Deliberately not built: a capability probe (its premise — that Claude
Code on the web disables
Task— was falsified by probing;Taskwas available andghwas not; and a probe gating quality companions fails open), agh→MCP degradation matrix (a second source of truth that would drift), and a compaction re-anchor (never observed, Full-tier only). (v3.25 refined the first entry rather than reversing it: the premise was falsified in the wrong direction too — a later harness holds the capability under the nameAgent, so the literal-Taskgates these files kept were themselves the bug. The name-agnostic capability check v3.25 installs gates nothing and fails closed, which is what separates it from the probe rejected here.) - A rejected design is recorded, not just removed. The first attempt
threaded a shared watch budget through a state file across
create-pr, Phase 7 and theci-auto-fixfan-out. It took six review rounds, was merged with ten live findings still open, and was reverted. Its failure shape — cross-context mutable state coordinated by prose, in files edited one at a time — is documented in the reference so it is not reinvented.
- Every wait is bounded at both levels. The subtle half: the Bash tool
defaults to 120 000 ms and 600 000 is opt-in, so
- v3.21.0 — User-requested changes are never scope creep (post-completion
improvements welcome). Field report: after a Full run finished (draft PR
open), the user proposed an improvement having seen the whole feature; the
dispatcher accepted the idea but declined to act on it, tagging it "scope
creep" — forcing the user to insist before it was implemented. Root cause:
the only scope-creep guidance was the
safety-guardrails.md"When to Stop and Ask" trigger #3 ("Scope creep detected"), which conflated the agent inventing work with the user asking for work, and there was no defined path for a follow-up arriving after handback. Fix — one conceptual home + coupled surfaces:rules/safety-guardrails.md— trigger #3 narrowed to agent-initiated expansion; new subsection "User-requested changes are never scope creep" (anchoruser-requested-changes-are-never-scope-creep) makes the principle explicit across the whole lifecycle, including post-completion, and defines the fold-in path (re-detect the tier for the delta → Micro/Lite single-pass on the same branch, or Full via the edit-driven iteration loop → gates as normal; "accepted means done"). The only legitimate pause is a genuine blocker/conflict, never scope size.templates/aw.agent.md— new "Follow-ups after completion" routing section: a post-handback improvement is a welcome new iteration; re-detect the tier for the delta only and reuse the existing branch/PR.rules/phase-3-implementation.md— the drift write-back note now states a mid-run user-requested change is conversation drift, not scope creep (fold in; hand back to the planner only if it needs re-planning).rules/diagnostic-surface.md— newpost-completionguards row recording the observed failure (improvement refused / accepted-then-deferred; delta tier not re-detected; a second branch/PR opened instead of reusing).SKILL.md(Core Principle #9, version 3.21.0) andREADME.md(Key Principle #9) surface the principle. Deliberately NOT changed: the scope-creep guard against the agent's own unrequested expansion (still trigger #3), the Phase 0/2 mandatory invariants, and everychecks.yaml/confidencegate — a folded-in delta is verified, tested, and reviewed like any other change.
- v3.20.0 — Scope-alignment interview companion (Phase 0). Wired the new
interviewskill in as a default-on, adaptive Phase 0 companion (Full Mode;--no-interviewskips,--interviewforces even on Micro/Lite).interviewis now the single source of truth for restate-and-diff + the Missing-Information Gate: Phase 0 Step 3a delegates both toSkill("interview"), which researches the codebase, classifies every unknownblockingvsadvisory, interviews the user only for load-bearing unknowns (silent on a crisp request), and writes.agent/{branch}/brief.md+ a readiness verdict. Phase 1's new## Scope Briefstep seeds Requirements / ACs / Existing Code Survey from the brief instead of re-deriving scope. The inline Step 3b/3c procedure is preserved verbatim as the graceful-degradation fallback (companion missing or--no-interview); the gates are identical either way, and ablockedverdict enforces the load-bearing-unknown hard invariant (halts even under--no-confirm). Reconciled the gate vocabulary: the incumbentassume-and-proceedclass was renamedassume-and-proceed→advisoryacrossphase-0-validation.md,diagnostic-surface.md,aw-planner.agent.md,planning-quality-research.md, and this file so both the skill and the workflow speak one vocabulary (no eval or anchor referenced the old token). Coupled surfaces updated in lockstep:phase-0-validation.md(Step 3a +scope-alignmentanchor + checklist + 3b/3c fallback pointers),phase-1-planning.md(## Scope Brief+scope-briefanchor + checklist),companion-skills.md(Phase 0 registry row + disable link),templates/aw-planner.agent.md(Phase 0 companion row + gate delegation note),templates/aw.agent.md(flag pass-through + Micro/Lite force path),diagnostic-surface.md(Phase 0 guard row + new typical gaps),SKILL.md(companion table + Phase 0 quick-ref +argument-hintflags + version 3.20.0),README.md(companion table), and the rootCLAUDE.md/README.mdinventory (interviewentry de-caveated to "wired").interviewdegrades silently if not installed — the inline gate is untouched, andconfidence(plan)remains the only non-removable companion. Deliberately NOT changed: the Phase 0/2 mandatory invariants, theblocking-halts-under---no-confirmhard invariant, and everychecks.yaml/confidencerule. - v3.19.0 — Single-context Full fallback for harnesses without sub-agent
dispatch (e.g. Claude Code on the web, where
Taskis disabled). Before this,aw's Full-tier fallback was under-specified and self-contradictory: the dispatch section said "invoke them yourself if your tools permit" while the Hard rules forbadeawfrom ever usingEdit/Writeon a Full task, so anawrun in the cloud env hitFailed to run agentand had to improvise a justification before doing the work in-context. This makes that emergent behavior the sanctioned, reproducible path: when the split is structurally unavailable,awruns the Full phases in one window — playing the planner role (Phases 0–2, producingplan.md+checks.yaml, clearingconfidence(plan) ≥ 90%) then the executor role (Phases 3–7). It preserves the plan artifact and the confidence gate — the two load-bearing wins of the split — and concedes only context isolation, which the harness has already made impossible. It is explicitly not a downgrade to Lite/Micro single-pass, and never a license to skip an available split (the guard is "can I dispatch?", not preference). The "tell the user to run the agents themselves" text is demoted to a last resort for whenEdit/Write/Bashare also unavailable. Coupled surfaces updated in lockstep:templates/aw.agent.md(Full-tier dispatch section, the Routing table's Full row, and theEdit/WriteHard rule — all three now condition on dispatch availability),templates/routing.rule.md(dispatch-unavailable branch pointing at that section),SKILL.md(v3.19.0; the Templates section states the single-context Full fallback and links the agent definition for the procedure), and this file's thin-router invariant, split-is-Full-only design-intent invariant, and theawdispatcher smoke test (step 3 now exercises the single-context path). Deliberately NOT changed: the tier-detection table (L1 Check B keeps it byte-identical toSKILL.mdStep 1), the preferred dispatch-the-split path whenTaskis available, and everychecks.yaml/confidence(plan)integrity rule. - v3.18.0 — Artifact lightening: checks-primary, lean plan, opt-in snapshots.
Rebalanced the Full-Mode artifacts around the two-jobs distinction above
(within-run handoff vs cross-session resumption). Four coordinated changes:
plan.v{N}.mdsnapshots are now opt-in.aw-create-plan(v2.2.0) writes onlyplan.mdby default (still bumping theversion:frontmatter); the immutable snapshot chain is written only when invoked asSkill("aw-create-plan", "snapshot"). Rationale:.agent/is gitignored scratch, the chain is rarely re-read, and it has no measured task-success benefit (§5.4). The iterate loop's snapshot-diff step became snapshot-mode only; its comment-walk fallback is now the default path.checks.yamlreframed as the primary living contract,plan.mdas the handoff document, everywhere in the docs (SKILL principles, README, overview, artifacts-overview, handoff contract, diagnostic-surface artifacts table).- Executor drift write-back. Phase 3 Step 5 now mandates writing decision/AC
drift back into
plan.md(andchecks.yaml), not just the Progress Log — the stale-plan fix so the durable artifact is consumed, not write-only. Wired into theaw-executortemplate's Universal Rules. - Removed the "No AI co-author tags" rule from this skill (user request):
dropped from SKILL principles, README, both
aw-planner/aw-executor/awtemplates,diagnostic-surface.mdhard invariants, phase-3/4/6 rules,parallel-coordination.md, the worked reference, and this file's invariants. - VS Code extension (v0.73.0):
getBranchChildrenrendersChecksSummaryItemFIRST (above Tasks/Plan) and it defaults toExpandedso the AC rows are visible without a click;PlanSummaryItemdemoted below it; Sessions panel mirrors the order (Checks before Plan). ExtensionCLAUDE.md+ provider test doc updated with the ordering contract. Coupled surfaces updated in lockstep:aw-create-plan/SKILL.md,artifacts-overview.md,planner-executor-handoff.md,phase-1/3/4/6,diagnostic-surface.md,parallel-coordination.md, all three agent templates,references/autonomous-workflow-complete.md,SKILL.md(v3.18.0),README.md, this file, and the rootCLAUDE.md/README.mdinventory. Deliberately NOT changed: the planner→executor split, the cold-readplan.mdguarantee, theconfidence(plan)Core-8 contract (L1 Check C), orchecks.yamlintegrity.
- v3.17.0 — Self-improvement fast tier migrated from
persistent-memoryto LoreKit (MCP-backed shared agent memory). The two former tiers map onto LoreKit scopes —home→global,project-shared→repo::{owner}/{repo}— and theaw-lessonsbucket becomes a LoreKit tag (loop::aw-lessons) plus a key namespace (aw-lessons::<slug>), because LoreKit partitions by repo/branch/global, not named buckets. Reads usememory.listnarrow-to-broad (repo:: then global) filtered by tag; writes classify the scope,memory.searchto dedup, thenmemory.write(same scope + key updates in place → the recurrence UPDATE). The filesystem opt-in ceremony (memory/aw-lessons/INDEX.md) is gone — LoreKit's mode (remote/ local.lorekit/) decides where arepo::lesson physically lives; the loop only picks the scope. INDEX 200-line caps andconsolidateare gone too (LoreKit owns storage and dedups on write); expiry (theexpiresfield, ignored on read once past) remains the decay mechanism. The lesson schema (fivemetafields + four bold fields), the advisory-only semantics, theseen_count >= 3promotion gate, and all five entrenchment guards are unchanged. Coupled surfaces updated in lockstep:self-improvement-loop.md(canonical SSOT),phase-1/3/4/7,companion-skills.md,diagnostic-surface.md, all four agent templates (aw,aw-planner,aw-executor,aw-tester),SKILL.md,README.md, this file, andreferences/self-improvement-walkthrough.md.persistent-memoryis kept as the general-purpose personal-memory skill and now documents the LoreKit backend (rules/scaling-tiers.md). The same migration was applied to every other loop in the repo (fix-bug,batch-linear-tickets,implement-suggestion,ci-auto-fix,test-auto-fix,e2e-pr-stabilizer,optimize-approach,ideate, and thereviewer/pr-revieweragents + thereview-outcomesbus). LoreKit skips silently when itsmemory.*tools are not connected — the fast tier degrades to nothing anddiagnoseis unaffected. - v3.16.0 — Plan-time optimality lens. Wired the
optimize-approachskill's newplanmode into Phase 1 as a default-on companion (Full Mode; quiet early-exit;--no-optimizeto skip), running between the adversarial pre-mortem andconfidence(plan). It asks the one design-level question the other Phase 1 gates assume away — is this the most optimal approach, and if not what is? — at the cheapest moment to switch (the approach is still words, not code). Positioned against the existing plan-time gates, not overlapping them: it consumes the Existing Code Survey verdicts (codebase-fit reuse is the survey's job, rule #10), does not re-listcritical's failure modes, and never re-scoresconfidence(plan). Its net-new value is the approach-level simplicity / performance / robustness judgment plus a materially-better-approach steelman. Advisory — does not gate; adopted proposals trigger a bounded re-plan viaaw-create-plan(one optimality pass per planning cycle — no re-invoke on the plan it revised, theF-plan-loopguard). Coupled surfaces updated in lockstep:phase-1-planning.md(new## Approach Optimalitystep + anchor, order-of-operations note, Contents, Planning Checklist, References),companion-skills.md(registry row + disable link),aw-planner.agent.md(companion table),diagnostic-surface.md(Phase 1 guard row + typical gaps),SKILL.md(companion table + Phase 1 quick-ref + version 3.16.0),README.md(companion table). The skill side addsoptimize-approach/rules/plan-mode.mdplus mode-detection / surface / lessons updates.optimize-approachskips silently if not installed — the lens degrades to nothing and the gate is unaffected. RootCLAUDE.md/README.mdinventory updated. - v3.15.0 — Plan-quality gates + executable checks. Implements the four
mechanisms from
references/planning-quality-research.md(2024–2026 web-research pass; see that file for citations and caveats):- Phase 0: Step 3b restate-and-diff (surface spec-perception deltas
before presenting understanding) and Step 3c Missing-Information Gate
(
blockingvsadvisory;blockinghalts even under--no-confirm— new hard invariant). - Phase 1: dependency-graph-first localization in Step 1; Existing Code
Survey (recorded reuse searches +
EXTEND/WRAP/BUILD NEWverdict per plannedcreate) as a deterministic-trigger Extended plan section; Acceptance Criteria gainAC-{n}IDs,(covers: R{m})traceability annotations, and EARS trigger→response preference. - Phase 2:
aw-create-planv2.1.0 Step 2b derives.agent/{branch}/checks.yaml— one runnable check per criterion (command/grep/judge), statusespending, re-derived per iteration. - Phase 4: new Executable Checks Loop — checks.yaml is the mechanical
termination condition and progress ledger; check definitions are
executor-immutable, four gaming strategies forbidden,
unsatisfiableabort affordance escalates; all-green is necessary-not-sufficient. Self-skips when no checks.yaml (backward compatible). - Gate:
confidencev2.3.0 adds deterministic rules #9 (every[user-stated]requirement covered), #10 (create ⇒ survey), #11 (checks.yaml ID sync; skipped for un-IDed plans like fix-bug fast-lane). - Coupled surfaces updated in lockstep: phase rules 0/1/2/4,
safety-guardrails.md(Executable-Check Integrity section),planner-executor-handoff.md(Core/Extended tables, rule-check list, handoff messages gain aChecks:line, executor entry step 3b),artifacts-overview.md(three-artifact table + tree), all three agent templates,diagnostic-surface.md(guards + 3 hard invariants + artifact row),SKILL.md(v3.15.0, principle #9, artifact table, quick reference),README.md, and L1 evals (l1.mjsruns the actual rule #9/#10/#11 idioms against new fixturesuncovered-req.md,create-no-survey.md,checks-valid.yaml,checks-drifted.yaml;valid-core.mdupgraded to the new AC format). Deliberately NOT added: new Core sections (Core-8 is coupled to rule #2, L1 G2, and fix-bug's fast-lane) and any weakening of existing gates (checks are additive).
- Phase 0: Step 3b restate-and-diff (surface spec-perception deltas
before presenting understanding) and Step 3c Missing-Information Gate
(
- v3.13.2 — Agent-template discoverability + role-accurate filenames. The
three agent definitions in
templates/are symlinked verbatim byinstall.sh(no substitution ever happens), so the old*.template.mdnaming both mislead — they aren't fill-in templates — and hid the agents from search: a repo lookup foraw/aw-planner/aw-executorfound nothing because the runtime names lived only inside file contents. Renamed each file so its name states what it is and matches the installed agent:dispatcher.template.md→aw.agent.md,planner.template.md→aw-planner.agent.md,executor.template.md→aw-executor.agent.md. Applied the same role-suffix logic to the rest oftemplates/:routing-rule.template.md→routing.rule.mdand the deprecated single-agent templateagent.template.md→_deprecated-single-agent.md. The directory staystemplates/(it means "source files this skill installs into your Claude config"). Pure rename — no behavior change; agentname:frontmatter, install paths (aw.md,aw-planner.md,aw-executor.md,autonomous-workflow-routing.md), and the legacy-cleanup block (still matches the pre-aw-autonomous-planner.md/autonomous-executor.mdlink targets) are all unchanged. Coupled surfaces updated in lockstep:install.sh(template_required+ symlink targets),SKILL.mdTemplates table, this file,rules/planner-executor-handoff.md,references/anthropic-architecture-research.md, the deprecated file's banner, and the L1/L2 evals + eval README that read the dispatcher template by path. RootREADME.md/CLAUDE.mdadditionally add the threeawagents to their agent inventories and featureawas the flagship entry point. Note: renaming the deprecated single-agent file dangles the symlink for pre-v3.3 single-agent installs that never re-raninstall.sh(negligible — those predate theawagents andinstall.shno longer recreates that link). L1: 69/69. - v3.12 — Adaptive dispatch + universal loop. Added a third agent,
aw(templates/aw.agent.md, linked asaw.md) — a thin, opt-in dispatcher that readsaw-lessons, detects the tier, and routes. Added a Micro tier (1-file mechanical: skip planning + quality companions) below Lite/Full, so mode detection is now 3-tier (Micro | Lite | Full); Micro reuses the Lite phase path. The planner→executor split is now Full-only — Micro/Lite run single-pass inaw's context (research: always-planning wastes compute and degrades long-horizon tasks; single-threaded continuity wins for simple/sequential work). The self-improvement loop's intake-read and exit-write are hoisted to the dispatcher so every tier contributes/benefits (phase-level reads/writes become the Full-tier specialization) — planning depth and learning coverage decoupled. Routing rule now dispatchesawinstead of "planner first" (fixing the Lite-has-no-plan.md impedance mismatch).awis opt-in: invoked via a trigger phrase or/aw, never a wrapper on casual edits. Coupled surfaces updated:install.sh(linksaw.md+ 3-agent summary),routing.rule.md,SKILL.md(3-tier detection + dispatcher in Templates + version 3.12.0),phase-0-validation.md(3-tier MODE SELECTION), this file,README.md,diagnostic-surface.md, and the root inventory. Research: Learning When to Plan (arXiv 2509.03581); Cognition vs Anthropic on single-vs-multi-agent. - v3.11 — Two-tier self-improvement. Added a fast tier of episodic
lessons on top of the existing
diagnoseslow tier. Newrules/self-improvement-loop.mdowns the contract:persistent-memoryis wired as an optional companion that reads the committedaw-lessonsscope at Phase 1 (lessons applied as plan constraints) and writes lessons at Phase 4 stuck-loop escalation and Phase 7 end-of-run. A lesson reachingseen_count >= 3(or taggedstructural) becomes promotion-eligible: the workflow suggests/create-skill diagnose autonomous-workflow, which readsaw-lessonsas evidence and applies a source change only behind the unchangedconfidence(analysis) ≥ 90 %+ user-approval gate. Lessons are advisory — they never auto-change behavior (the entrenchment guard against self-reinforcing error). The committed scope is seeded at~/.agent-memory/aw-lessons/. Coupled surfaces updated:companion-skills.md(3 rows + Self-Improvement Loop section),phase-1-planning.md(lessons-read),phase-4-testing.md(lessons-write),phase-7-ci-gate.md(lessons-write),diagnostic-surface.md(guards + advisory-only invariant), both agent templates,SKILL.md(Self-Improvement section + companion table + install sets + version 3.11.0), andREADME.md. RootCLAUDE.md/README.mdinventory updated.persistent-memoryskips silently if not installed — the fast tier degrades to nothing anddiagnoseis unaffected. Research basis: CoALA episodic→procedural promotion, ExpeL trajectory-distilled lessons, Agentic Context Engineering (incremental deltas, not rewrites), and the Reflexion / SSGM self-reinforcing-error guards. - v3.10 — Plan template tiered into Core + Extended; rationale grounded in
empirical evidence. The
aw-create-plantemplate no longer forces all ~14 sections on every Full-Mode task. Core (TL;DR, Requirements, Decisions, Acceptance Criteria, Implementation Order, File Changes, Verification, Progress Log) is always emitted; Extended (Background, Technical Approach, Patterns, Edge Cases, API / Interfaces, Tests, Dependencies, Risks) is emitted only when each section'sInclude whentrigger holds — omitted, not stubbed. Root cause / motivation: the over-detailed-upfront-plan failure mode is empirically real (overthinking, inverse-scaling, and as-needed-decomposition literature), now documented inreferences/anthropic-architecture-research.md§5. The Core set is exactly what the executor reads cold and the confidence gate enforces, so resumption and gating are unchanged; the win is smaller plans on simpler Full-Mode tasks. Coupled surfaces updated in lockstep:skills/workflow/aw-create-plan/SKILL.md— tier table in Step 2, per-sectionInclude whentriggers, two-tier validation checklist, omit-don't-stub Common-Failures row.skills/quality/confidence/SKILL.md— plan-mode rule check #2 now requires the 8 Core sections by name (also fixes a latent bug: it counted## Summarywhile the template emits## TL;DR, so the check never matched the human- review heading); LLM dimensions no longer penalize a legitimately-omitted Extended section.rules/planner-executor-handoff.md— handoff contract split into a Core (always) table and an Extended (conditional) table; the executor must not bail when an Extended section is absent.references/anthropic-architecture-research.md— new §5 (empirical evidence, confidence-tiered) + renumbered §6 references; the plan's justification reframed from "single source of truth" to cross-session resumption.rules/diagnostic-surface.md— Phase 2 guard wording updated to name the Core sections. No taxonomy row added (the taxonomy is append-only and no new real failure was observed).
- v3.9 — Reviewer self-review sub-mode. Added Rule 0 (authorship pre-check) to
agents/reviewer.mdMode Detection:ME=$(gh api user --jq .login)vsAUTHOR=$(gh pr view ... --jq .author.login). WhenME == AUTHOR, the run enters PR (self-review) sub-mode: Step 4 auto-fix re-enabled, Steps 5.1–5.6 (pending GitHub comments) replaced by Step 5.8 (inline terminal report).--criticaladversarial findings flow into the inline-report (Must-fix → Critical bucket, Should-fix → High bucket) rather than a separate channel. Cross-review behavior unchanged. Phase 7 Auto Review dispatch prompt and log updated to reflect inline-report deliverable. Root cause: Phase 7 always self-authors its PRs (aw-executor opens them), so "pending review" was enforcement theater — comments visible only to the same user who opened the PR. - v3.8 — Sub-Agent Resource Discipline. Replaced the "Phase 3 is not
parallelized" blanket prohibition with "controlled fan-out under per-slice
scoping" (cap 3 concurrent, file-disjoint slices). Added the
Sub-Agent Resource Disciplinerule (rules/parallel-coordination.md#sub-agent-resource-discipline): sub-agents must use scoped validation commands only; whole-projecttsc,lint,build,testare forbidden inside sub-agents and reserved for orchestrator-only boundaries (Phase 4 Step 6, Phase 6 pre-PR). Root cause: N concurrent whole-projecttscprocesses scale peak RSS ~2.9x per process, crashing developer hosts on multi-slice tasks. AddedF2taxonomy row torules/diagnostic-surface.mdand updated all 7 coupled surfaces that previously asserted "Phase 3 is not parallelized". Enforcement is via diff review at maintenance time and the LLM-readable rule at runtime — no shipped script (skills stay markdown-only per the repo contract). - v3.7 — Diagnose Mode relocated to
create-skill. The--diagnoseflag is gone from this skill; the retrospective self-improvement loop is now/create-skill diagnose autonomous-workflow. The seven-step procedure, output report format, confidence gate, and apply / PR flow moved intoskills/authoring/create-skill/rules/diagnose-mode.mdso the same capability works against any diagnosable skill (fix-bug, batch-linear-tickets, future ones). What stays here is a declared contract —rules/diagnostic-surface.md— that the generic engine reads to parameterize itself: phase model, failure taxonomy (F1 +F-novel, unchanged, append-only), existing-guards-per-phase table, hard invariants, source root, artifacts. Behavior is preserved end-to-end:--applystill gates onconfidence(analysis) ≥ 90 %plus explicit user confirmation; one proposal per report; earliest-phase-fix wins; diagnose never modifies user product code. For users, the only surface change is the invocation:/autonomous-workflow --diagnosebecomes/create-skill diagnose autonomous-workflow. - v3.6 — Self-improvement, gated everywhere. Two coordinated changes:
- Diagnose Mode. New
--diagnoseflag on the orchestrator runs a retrospective self-analysis after a workflow run produces wrong code. Outputs.agent/{branch}/diagnose-{ts}.mdcontaining a failure classification, a phase-attribution matrix walk, and one applyable unified-diff proposal targeting this skill's source. The proposal is gated bySkill("confidence", "analysis") ≥ 90 %; below the threshold,--applyis refused and the report becomes a discussion artifact.--applyalways asks for confirmation even with the gate passing — Auto mode does not bypass this. Procedure originally lived inrules/diagnose-mode.md; in v3.7 it was relocated toskills/authoring/create-skill/rules/diagnose-mode.md(see v3.7 above). The failure taxonomy is intentionally seeded with F1 +F-novelonly and grows append-only from real confidence-gated, user-approved diagnoses (no speculative categories). Diagnose Mode never modifies user product code. test-provenance-guardautofix in the loop, behind a confidence gate. The Phase 4 invocation passes--fix, so the guard self-heals autonomously when it can — but the skill MUST clearSkill("confidence", "code") ≥ 90 %on the proposed extract-and-rewrite before mutating any file, and the three existing post-heal mechanical gates (build, target test, mutation re-verify) afterwards. Either gate failing ⇒ no autonomous refactor; the finding is reported asheal-skipped-low-confidenceorheal-failed, and the existing Phase 4 stuck-loop /confidence(analysis)/holistic-analysiscascade takes over. The--no-confidence-gateoverride is reserved for human-driven slash invocations and is never set inside the loop.
- Diagnose Mode. New
- v3.5 — Plan versioning.
aw-create-plannow writes an immutableplan.v{N}.mdsnapshot on every invocation and mirrors it intoplan.md(the canonical "latest" pointer). Initial creation producesplan.v1.md+plan.md; user-requested iteration and Phase 4 auto-replan both bump to the next version. Older snapshots are preserved untouched as audit trail. The Phase 4 stuck-loop protocol now re-invokesaw-create-planafterholistic-analysisinstead of surgically editingplan.mdin place. The VS Code extension surfaces previous versions as expandable children of the Plan node so reviewers can compare iterations. - v1.x — Initial skill in
gw-tools.git. Monolithic SKILL.md. - v2.x — Split into phase rules + companion artifacts (
create-plan,create-walkthrough,confidence). Still ingw-tools.git. - v3.0 — Migrated to
agent-skills.git. Companion-skills registry pattern..agent/artifact directory (was.gw/). 3-iteration stuck-loop limit (was 20). Phase 7 = CI Gate + Optional Cleanup (was just Cleanup). Optional companions skip silently. - v3.1 —
gwmade optional (recommended), with a nativegit worktreefallback.ghremains hard-required. Phase 2 detectsgwat Step 0 and emits a one-time warning when falling back, listing the features the user is missing (auto-copy, pre/post-checkout hooks, smart cleanup, shell-integratedgw cd). The workflow is now usable in repos that haven't adoptedgw. - v3.3 — Split into two agents (planner + executor) connected by
plan.md. The split is along the Phase 2 → Phase 3 context boundary:aw-planner— runs phases 0-2 (validation, planning, worktree + plan.md generation). Tool budget excludes Edit/Write on production code. Terminal deliverable:.agent/{branch}/plan.md, gated onconfidence(plan) ≥ 90%.aw-executor— runs phases 3-7 (implementation, testing, docs, PR, CI). Reads plan.md from cold; bails if missing or invalid rather than re-planning. Terminal deliverable:.agent/{branch}/walkthrough.md+ draft PR.- Handoff contract — see
rules/planner-executor-handoff.md. Two messages: high-confidence auto-handoff (≥ 90%) and user-approval (< 90%). Each agent has a single, gated, terminal artifact — when the artifact exists and the gate passed, the agent is done. This pattern matches Anthropic's "structured handoff artifacts" recommendation; full citations are inreferences/anthropic-architecture-research.md. - The agents share
companion-skills.mdand the phase rules — the split is an architectural lever, not a behavior change. templates/_deprecated-single-agent.md(the original single-agent template) is preserved as a backward-compat artifact for users with existing installs, but is no longer linked byinstall.sh. New installs useaw-planner.agent.md+aw-executor.agent.md.
- v3.2 — Quality refinements based on field-alignment review:
- Multi-signal
confidence(plan)gate. Theconfidenceskill'splanmode now combines LLM dimensional scoring with deterministic rule checks (file paths resolve, requirements tagged, timestamps are ISO 8601, etc.). A failed rule caps the gate at 89% regardless of LLM score — catches the "high-confidence-but-hallucinated" failure mode. - Acceptance Criteria in
plan.md. New mandatory section in theaw-create-plantemplate. Phase 4 testing now has explicit pass/fail conditions to gate against (sprint-contract pattern from Anthropic's harness-design guidance). - Auto-replan on stuck-loop. Phase 4 stuck-loop detection now
auto-invokes
holistic-analysiswhenconfidence(analysis) < 90%, regenerates the affectedplan.mdsection, and resumes once. One-shot guard prevents infinite recursion. - Mode-aware iteration cap. 3 iterations for Lite, 5 for Full. Lite keeps the tight loop; Full gives well-scoped tasks one extra attempt before mandatory escalation.
- Per-iteration self-reflection (lightweight evaluator-optimizer). Before each iteration ≥2, the agent runs a brief two-question self-check ("Is this attempt different from the last?" / "Did I understand why my previous fix didn't work?"). If either fails, jump to stuck-loop detection early — no wasted iterations.
- Mode detection: complexity primary, file count tie-breaker. Three sequential questions in Phase 0 (architectural? unfamiliar? 4+ files?) replace the conflated "4+ files OR complex" criterion. Complexity decides first; file count is the fallback.
docs updateopt-out lever. Per-task skip conditions documented (pure dependency bumps, test-only changes, config-only changes, user override). Default remains always-on; the skip is logged.
- Multi-signal
- v3.4 — Workflow-exclusive companions and agents grouped under an
aw-prefix so they cluster in the harness's/-listing. Renamed:create-plan→aw-create-plan,create-walkthrough→aw-create-walkthrough,review-quality-gate→aw-review-quality-gate,autonomous-planner→aw-planner,autonomous-executor→aw-executor. The orchestrator itself (autonomous-workflow) keeps its full name as the user-facing entry. General-purpose skills used outside the workflow (confidence,ci-auto-fix,create-pr, etc.) are unchanged. Pure rename — no behavior changes.
The npm package @gw-tools/autonomous-workflow-agent still exists at the
old location for SDK users who prefer a programmatic import. It will be
deprecated in a future release once this v3 skill is stable.
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.

