Hermes 中文优先的轻量自主循环技能:每轮新上下文、状态写文件、Git 留痕、小任务推进、测试/构建/验收作为回压门禁。 当用户说一直跑、循环做、分小步、断点续跑、跑到完成、像 Ralph 那样、别塞爆上下文时使用。
Scanned 9/9/2026
Install to Claude Code
npx -y skills add Undermybelt/hermes-skills --skill fres-cont-loop-runn --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Fres Cont Loop Runn?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/undermybelt-fres-cont-loop-runn)More formats (shields.io, HTML) on the badges page.
---
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
1. 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.
2. 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.
3. 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.
4. Backpressure beats prescription.
- Give agents success criteria and gates, not giant step scripts.
- Gates: tests, typecheck, lint, build, browser verification, review checklist.
5. 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
```json
{
"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
1. Inspect repo docs and nearest agent docs.
2. Create or update `.hermes-loop/tasks.json` with small items.
3. 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
4. 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
```text
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.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!