Process files to Done folder
Move all files from /Needs Action to /Done folder, stopping when all files are processed.
/ralph-loop "Process all files in /Needs Action, move to /Done when complete" --completion-promise "TASK COMPLETE" --max-iterations 10
claude-code
More automation loops
Set and ship autonomous goals
Run a persistent goal autonomously until completion, routing each task to the optimal model for cost and capability.
/goal <objective · /loop <task | Set a persistent goal · run autonomously until complete (≤25 turns) |
automationlow risk
Sync upstream skills on demand
Pull skill updates from a configured remote repository, review diffs, and commit changes when upstream has new content.
# Claude Instructions <!-- Governs all agent behaviour. Evolve via PR with tech lead review. --> ## Active context Active pipeline context: .github/context.yml <!-- context.yml holds toolchain settings. Switch profiles: cp contexts/personal.yml .github/context.yml or cp contexts/work.yml .github/context.yml --> --- ## Skills pipeline maintenance Upstream skills sync configuration is stored in .github/context.yml under skills upstream: . When asked to check for or pull upstream skill updates, read that block first — it contains the git remote name, repo URL, sync paths, and strategy. To sync skills from upstream: bash git fetch <skills upstream.remote> git diff HEAD <skills upstream.remote>/master -- skills/ git checkout <skills upstream.remote>/master -- skills/ templates/ scripts/ docs/skill-pipeline-instructions.md git diff --staged git commit -m "chore: sync skills from skills-upstream [date]" If skills upstream.remote is null or strategy is none , no remote has been configured. The user can add one with: bash git remote add skills-upstream https://github.com/heymishy/skills-repo.git Then update skills upstream.remote and skills upstream
automationmedium 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