evolve-loop

Use when the user invokes /evo:loop or asks to run autonomous improvement cycles, self-evolving development, compound discovery, or multi-cycle code improvement with research, build, audit, and learning phases

Use after build has produced build-report.md. Validates the build via four parallel sub-auditors (eval-replay, lint, regression, build-quality) and produces ALL-PASS verdict. Adversarial mode default-on per CLAUDE.md.

Use when the user asks to explain how a feature/subsystem works and how the loops built it, or what the concurrent loops/lanes/cycles did and why. Default output = per-FEATURE HTML explainer pages (two movements — how it works today, then how it got built, with verified file:line claims and drift callouts) under docs/explain/; per-batch/per-lane story pages are the fallback framing. Derived from geoffreylitt/explain-diff-html, customized for evolve-loop.

Use when writing or changing any production code or tests — new features, bug fixes, refactors, or test authoring, in any language, by any model on any CLI.

Use when running any LLM agent below Fable 5 — Claude (Opus/Sonnet/Haiku), GPT via codex, Gemini via agy, or local models via ollama — to adopt Fable 5's operating discipline — evidence-first investigation, premise verification, root-cause-only fixes, adversarial self-review, calibrated autonomy, and honest failure reporting. Load at session start or as a persona overlay for phase agents on any CLI.

Use after ship completes. Three sub-reflectors (instinct, gene, failure) run in parallel to extract lessons, update gene pool, and analyze any failures. Off the latency-critical path.

Use when the user invokes /evo:publish or asks to release a new version, ship a release, or publish a tag. Wraps the go-native self-healing release pipeline (`evolve release`) — pre-flight checks, auto-changelog, atomic ship, marketplace propagation poll, auto-rollback on failure.

Use after tdd has written RED tests and the contract is in team-context.md. Implements the minimum code to turn RED tests GREEN. Runs in a worktree with single-writer invariant.

Use when reviewing code changes for quality, security, performance, or maintainability issues and identifying simplification opportunities in a single token-efficient pass

Use when the user asks to commit changes (interactively, not inside an autonomous cycle). Runs code-simplifier + one reviewer (general code-reviewer OR the matching language reviewer, ECC agents/skills), then lint + targeted tests via `evolve commit-gate run`, writes a tree-SHA-bound attestation, commits + pushes via the sanctioned `evolve ship --class manual` path (which hard-verifies the attestation), then watches GitHub CI with one auto-fix-on-red pass.

Use when the user invokes /evo:evaluator or asks to evaluate, assess, score, or independently audit code quality, project health, or improvement priorities with multi-dimensional scoring and anti-gaming defenses

Use when reviewing Go test code (new or changed *_test.go files, test harnesses, fixtures, or test tooling) for a Go-test-expert pass — behavior-over-surface, determinism, parallel-safety, build-tag correctness, and harness reuse. Complements the general code-reviewer with test-specific rigor.

Use when the user invokes /evo:inspirer or asks to brainstorm creatively, think outside the box, explore unconventional approaches, break out of stagnation, or generate research-backed ideas with provocation lenses

Pre-Scout intent capture phase. Structures vague user goals into intent.md before any subagent budget is spent. Opt-in via policy.json workflow.phase_enables.intent=on.

Use when the user asks to refactor code, review code quality, or fix code smells — orchestrates the full refactoring pipeline from detection through fix, with parallel worktree isolation per independent refactoring group

Use when the user asks whether a release is ready, or to gate/verify release criteria before publishing. A thin readiness-gate that runs the existing read-only verifiers (evolve release-preflight, evolve release-consistency), adds the CI-green-on-main and no-WIP-commit checks they don't cover, then delegates execution to /evo:publish. Does NOT reimplement the release pipeline.

Security-focused code review that emits a numeric composite score (0.0–1.0) suitable for the evolve-loop Builder self-review convergence loop

Use when the user runs /evo:setup (or /evo:setup), asks to configure evolve-loop, onboard, pick per-phase models, or learn how the pipeline works. Auto-detects available LLM CLIs/subscriptions, explains the pipeline concisely, then presents THREE ready-made config presets (Recommended/Economy/Max-quality) the Go binary computes deterministically from the public profiles — the user makes ONE choice and the binary writes per-phase pins to .evolve/policy.json. Runs once on first launch (the loop nudges) and is re-runnable anytime.

Use after audit returns Verdict PASS. Atomic git commit + tag + ledger update. Single-writer; cannot fan-out.

Use when the user invokes /evo:verify-release or asks to check whether a release has propagated, whether the marketplace is up to date, or whether installed plugins reflect the latest version. Wraps legacy/scripts/release/marketplace-poll.sh for standalone post-publish verification.

Use when scout-report.md exists and TDD/Build hasn't started yet. Runs four lenses (CEO, Eng, Design, Security) in parallel on the task list and produces a verdict (PROCEED, REVISE, ABORT) before code is written. Catches misaligned plans before they cost cycles.

Use when starting a new evolve-loop cycle and the cycle goal is ambiguous or only described as a one-line objective. Generates a structured specification before any code is written. Surfaces assumptions explicitly.

Use when the plan-review verdict is PROCEED (or plan-review is disabled) and code has not yet been written. Writes RED tests first, defining the contract Builder must satisfy. The mandatory hop before any implementation.

Use when authoring evals/predicates (Scout, TDD-Engineer), framing an audit (Auditor), or justifying which phases run (PhaseAdvisor/router). Codifies Google's 4-phase adversarial-testing methodology mapped onto evolve-loop's eval, audit, routing, and red-team surfaces.

Use when the user (or the advisor) wants to design and register a NEW optional pipeline phase conversationally — "add a phase that does X". Interviews for goal-type, trigger signal, report sections, and verdict; synthesizes a phase.json + persona; registers them via `evolve phases create`; self-corrects from the command's JSON envelope. The Go binary is the single enforcement point, so this flow works from any LLM CLI.

Use in any coding session when writing or changing code — enforces the laziest solution that actually works (YAGNI, stdlib-first, shortest diff) while never trimming validation, error handling, security, accessibility, or the pipeline's tests/gates. Also triggers on "minimalism", "be lazy", "simplest/minimal solution", "yagni", "do less", "shortest path", or complaints about over-engineering, bloat, boilerplate, or unnecessary dependencies.