Execute production plans autonomously
Run a multi-phase task plan end-to-end with failure recovery, cross-verification gates, and crash-resume tracking until completion.
--- name: autoplex description: Production-grade autonomous plan execution engine for Claude Code. NOT a simple ralph-style while loop — autoplex is an execution system with five unique mechanisms: (1) failure-type-aware adaptive retry that rewrites prompts based on 5 detected failure modes (context overflow, rate limit, budget, API error, generic), (2) per-task 6-step methodology injection (context load, parallel research subagents, implementation, verification, cross-verification, commit) embedded in every prompt, (3) phase-level cross-review quality gates via independent claude -p sessions with multi-agent verification, (4) crash-resumable progress tracking via progress.md ledger, (5) per-task budget allocation with dynamic +$3/+$5 adjustment on retry. Each task runs in a completely fresh headless session — zero context leakage between tasks. Use when: (1) user has a task plan.md with phased tasks and wants to execute them autonomously, (2) user says "run the plan", "execute tasks", "automate the phases", "run overnight", or similar, (3) user wants to batch-execute tasks from a planning-with-files session without babysitting, (4) user references
claude-code
More automation loops
Wire up C2 LSP container semantics
Continuously verify and adjust C2's fetch, LSP environment, and cache mounts until container semantics validate correctly.
/loop semantics — the verify→review→tweak loop, ContainerRw lifecycle, reaping, merge hand-off are unchanged; C2 makes the fetch/verify/lsp env + commands + cache mounts + image language-selected
automationmedium risk
Draft weekly release notes
Every Friday at 2pm, draft release notes from merged PRs into releases/DRAFT.md and verify all links resolve.
/schedule every Friday at 2pm, draft release notes from the PRs merged since the last draft: group changes into features, fixes, and docs, write one plain-English line per change with the PR link, and save to releases/DRAFT.md. Draft only — a human edits and publishes; never post or send anywhere. Verify every PR link resolves and every merged PR since the last run is covered before saving. Stop after 1 pass per run.
automationlow risk
Parallel Codex Legion With Integration Judge
Split a large mechanical job into 2–5 independent Codex lanes, each isolated in its own worktree with a frozen acceptance bar and binding judge, then block the final merge behind a full integration judge.
Dispatch a parallel Codex legion for a large mechanical job. Split the work into 2–5 genuinely independent lanes, one lane per piece.
First announce a muster table with:
- each lane,
- the exact files that lane may touch,
- the frozen acceptance check for that lane.
Do not proceed until I approve the split.
Before dispatch, the orchestrator must freeze and record each lane’s acceptance bar. After dispatch, each worker treats `.git` as read-only.
Each lane must run in its own git worktree with:
- a frozen acceptance bar recorded before code changes,
- a strictly disjoint may-touch manifest,
- its own sandbox,
- read-only `.git` state for the worker.
If any lane’s file footprint overlaps another lane, refuse the split and serialize the work instead.
When a lane finishes, run a fresh-context judge against that lane’s frozen bar. The judge must return binding PASS or FAIL. Allow at most 2 retries per lane; stop after 2 failed attempts, then escalate loudly.
Merge lanes in a fixed order. After merging, require a mandatory integration judge that reruns the full test suite across the combined result. Do not commit or merge unless the integration judge returns PASS.
Hard cap: 5 workers. If there are more than 5 pieces, run later waves. Never merge without the integration judge.
automationmedium risk