| name | fres-cont-loop-runn |
| description | Hermes 中文优先的轻量自主循环技能:每轮新上下文、状态写文件、Git 留痕、小任务推进、测试/构建/验收作为回压门禁。 当用户说一直跑、循环做、分小步、断点续跑、跑到完成、像 Ralph 那样、别塞爆上下文时使用。
|
| tags | ["自主循环","新上下文","断点续跑","小任务","回压门禁","ralph"] |
| version | 1 |
Fresh Context Loop Runner
Goal
- Execute long implementation work as small resumable loops.
- Keep the orchestrator thin; let each fresh agent do the real work.
- Persist state on disk so context loss is survivable.
Use this when
- 用户要“自主循环推进”“一直做直到完成”“分小步反复推进”“断点续跑”“每轮重新读状态”“像 Ralph 那样跑”。
- 用户明确嫌大上下文臃肿,希望把任务切成小验收单元。
- 任务可拆成小步,且至少有一个可执行验证命令。
Do not use this when
- The task is a simple one-shot edit.
- There is no clear stop condition.
- There is no rollback path.
- The user asked for pure planning only; route to
plan or /plan instead.
Core pattern
- State lives on disk.
.hermes-loop/tasks.json or project-native equivalent tracks work items.
.hermes-loop/progress.md records durable learnings and gotchas.
.hermes-loop/loop.lock records active loop identity if a long loop is running.
- Git is memory.
- Start from a clean or understood worktree.
- Commit or snapshot after a verified work item.
- Do not stack fixes on top of a known-bad attempt.
- Fresh context is reliability.
- Each iteration re-reads task state, relevant docs, changed files, and verification output.
- Do not rely on chat memory for completion state.
- Backpressure beats prescription.
- Give agents success criteria and gates, not giant step scripts.
- Gates: tests, typecheck, lint, build, browser verification, review checklist.
- Small work items only.
- Each item should fit in one context window and one verification loop.
- Split anything that smells like "build the whole dashboard".
Minimal state schema
{
"objective": "short goal",
"verify": ["command 1", "command 2"],
"items": [
{
"id": "T1",
"title": "small deliverable",
"acceptance": ["observable criterion"],
"status": "pending|in_progress|done|blocked",
"notes": "compact handoff note"
}
]
}
Loop procedure
- Inspect repo docs and nearest agent docs.
- Create or update
.hermes-loop/tasks.json with small items.
- For each iteration:
- read
.hermes-loop/tasks.json, .hermes-loop/progress.md, recent git log, and current diff
- choose the highest-priority pending or blocked item that is now actionable
- make the smallest change that satisfies one item
- run verification commands
- if pass: mark item done, append progress note, commit/snapshot if appropriate
- if fail: record blocker and exact failing evidence; either fix once or mark blocked
- Stop when all items are done, verification passes, or a real blocker is recorded.
Hermes execution options
- For current-session loops, use normal tools and keep state files updated.
- For long-running background loops, route to
/background <self-contained prompt> when available.
- For independent fresh agents, spawn
hermes chat -q '<self-contained iteration prompt>' or use delegate_task for bounded subtasks.
- Use worktrees for parallel loops that edit code.
Self-contained iteration prompt template
Workdir: <repo>
Read first: local agent docs, .hermes-loop/tasks.json, .hermes-loop/progress.md, git diff, git log -5.
Pick exactly one pending task.
Make the smallest change.
Run: <verify commands>.
Update .hermes-loop/tasks.json and .hermes-loop/progress.md.
Stop after one task or one blocker. Report changed files and verification result.
Verification
- A task is not done until its acceptance criteria and repo checks pass.
- For UI tasks, include browser verification when available.
- If checks are slow, run the narrow check first, then broad check before final.
Pitfalls
- Do not turn the loop runner into a second platform.
- Do not add complex retry policy; fresh context plus state files handles most recovery.
- Do not let multiple loops edit the same files without worktree or lock discipline.
- Do not update global memory with loop progress; use repo state files.
- Do not mark done from natural language alone; require proof bundle or command output.