菜单
子任务派发规范 —— 定义 hermes 主会话如何把任务拆给 delegate_task 子 agent,以及子 agent 应如何产出标准化的 handoff 报告。适合在需要把大任务并行化、或需要独立验证的子任务时加载使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Diagnose and fix the dual-channel memory problem in Hermes Agent — when `memory.provider: holographic` (or any external provider) is configured but the agent keeps writing only to `memories/MEMORY.md`, bypassing it. Covers why agents default to the markdown file, the four root causes of routing failure, and three remediation options (SOUL.md rules / disable MEMORY.md / mirror via code). Triggers on 'memory 不生效', 'holographic 没在用', 'agent 都写到 MEMORY.md', '双 memory 系统', 'memory tool vs fact_store', 'on_memory_write', 'memory drift', 'Mirrors 不到', or any 'why is my agent ignoring the configured memory provider' question.
Use when the user works inside ~/Projects/Config/Guix-configs and mentions '改 dotfiles', 'blue home', 'guix system reconfigure', 'shepherd service', 'stow 死链', 'blue stow', 'AGENTS.md 翻新', 'fcitx', 'IME 没输入法', 'Electron 没输入法', 'wireplumber', '二轨 dotfiles', '恢复被删除的 dotfiles', or related. Ten sub-protocols — dotfiles deploy verification, worker delegation, multi-line edit safety, Guix service debugging, GNU Stow mutable config, restoring deleted dotfiles, ISO 移植, 需求澄清, 模块归属陷阱.
跨 agent KB 健康度维护。**触发信号**：每周/长会话后例行维护 / 卡片 >50 张 / 检索质量明显下降 / 用户触发 `/agenote-curate` / 发现重复卡片或矛盾结论 / 新增了对话抽取源。**当上述任一信号出现时立即调用本 skill** 做健康检查+去重+归档+权重重分配+reconcile 多源 memory。基础用法见 `agenote-base`；会话中单次经验记录见 `agenote-review`。
Maintain the personal Guix channel at ~/Projects/Config/jeans (Just Enough AI-geNerated Slops). Use when the user asks to "fix the CI build failure issue", "升级 X 包", "add a package", "check upstream updates", "跑 maak upgrade", "修复 auto-update 流水线的 issue
How to author a Hermes Agent skill the right way. Covers the two non-negotiable structural principles every skill must follow — **self-contained** (all runnable artifacts ship inside the skill directory so backup = usable) and **progressive disclosure** (SKILL.md is a thin router; details live under `references/`, `templates/`, `scripts/`) — the directory layout, file-type rules, decision trees for what goes in SKILL.md vs. a support file, **which of the 12 existing categories a new skill belongs to (never top-level `<skill-name>/`)**, and a checklist before declaring a skill done. Trigger when: writing a new skill, refactoring an existing skill's structure, wondering 'should this go in SKILL.md or references()' / 'which category directory should this skill live into', preparing a skill for backup/share, noticing a self-contained violation, or auditing existing skills. Also trigger when the user complains something is 'too verbose' or 'in the wrong place' — those are progressive-disclosure violations.
When the user says '校对文档 / 检查文档是否还有效 / sync doc with code / 扩写 README / 改写文档 / 把这个 PLAN/plan/任务书做成文档 / 文档并入主文档', or when a `refs/*.md` document may be drifting from the tool/CLI/源码 it describes, or when a PLAN file needs to become a user-facing reference doc. Covers three entry points — check, rewrite, plan-to-doc — backed by a `scripts/doc-check.py` checker that catches silent drift between a doc and its source-of-truth (CLI flags, MCP tool names, file paths). Trigger when the user names a doc path and asks whether it's still accurate, when adding a new CLI/MCP/API surface that old docs don't mention, or when a PLAN/任务书/thread needs to graduate into a stable reference.
| name | worker-handoff |
| description | 子任务派发规范 —— 定义 hermes 主会话如何把任务拆给 delegate_task 子 agent,以及子 agent 应如何产出标准化的 handoff 报告。适合在需要把大任务并行化、或需要独立验证的子任务时加载使用。 |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["delegation","subagent","handoff","parallel-tasks","worker"],"related_skills":["task-planner","codebase-scout","code-reviewer"]}} |
这个 skill 不是给主 agent 自己用的工作流,而是给主会话派发子 agent 时的统一规范。
加载本 skill 后,你应当按以下规范来:
delegate_task 派给子 agent,在 context 里附上下方的"Worker 行为规范"和具体的 Handoff 模板| 场景 | 模式 |
|---|---|
| 独立子任务 | 用 delegate_task(tasks=[...]) 并行派 |
| 链式任务 | A 完成后根据其 handoff 再派 B |
| 大任务 | 先 task-planner 拆解,再批量派 worker |
子 agent 收到任务后,按以下规范工作:
terminal 跑测试、lint、类型检查throw new Error("not implemented"),除非在明确断言辅助函数中| 级别 | 含义 | 主会话响应 |
|---|---|---|
live-ui-verified | 实际复现 bug 并确认修复消除(真实浏览器/二进制/CLI) | 信任为已发布 |
unit-test-verified | 目标测试覆盖变更路径并通过,无实际复现 | 非 UI bug 可接受 |
type-check-only | 仅类型检查/构建通过,无测试或复现 | 弱,仅适合纯类型变更 |
not-verified | 未端到端验证(如纯重构,或环境阻塞) | 需要 code-reviewer 复审 |
这些情况需要回到 task-planner 或 architecture-advisor 重新评估。
## Status
success | partial | blocked
## 执行摘要
- 高层摘要,按文件列出如有用
## Branch
`<实际分支名>` (或 "(no branch)" 如果没有代码产出)
## What I did
- 高层摘要,按文件列出如有用
## Measurements
- <metric>: <before> <op> <after>
每行格式:`<指标名>: <之前> <op> <之后>`,op 为 `→` / `<=` / `<` / `>` / `>=` / `==` 之一。如果没有定量标准,写 `(none)`。
## Verification
live-ui-verified | unit-test-verified | type-check-only | not-verified
## 实施报告
### 完成内容
一句话总结做了什么。
### 变更文件
| 文件 | 变更类型 | 摘要 |
| ----------------- | -------- | ------------ |
| `path/to/file.ts` | 修改 | 做了什么修改 |
| `path/to/new.ts` | 新增 | 用途 |
### 文档更新
- 更新了哪些文档(README / 注释 / CHANGELOG)
### 关键决策
- **决策 X**:为什么选择方案 A 而不是 B(如果存在选择)
- **决策 Y**:如何处理某边界条件
### 验证结果
- ✅ 测试通过:`npm test` — 结果(覆盖率:X%)
- ✅ 类型检查:`tsc --noEmit` — 结果
- ✅ Lint 通过:`eslint ...` — 结果
## Notes, concerns, deviations, findings, thoughts, feedback
- 任何规划者需要知道的信息:假设、意外、决策、不变量破坏、不清楚的需求、对任务范围的看法
## 建议后续
- 规划者应考虑发布的后续任务
## 遗留风险/问题
- ⚠️ [风险描述] — 建议后续处理
对于每个 worker 返回的 handoff:
success:决定重试、修复还是澄清not-verified 必须送 code-reviewer当 worker 返回 Status: blocked 或失败时,根据失败模式决定:
| 失败模式 | 策略 |
|---|---|
cap-hit / oom | 缩小范围重试:拆分更窄的任务、更紧的 toolsets、更精简的 context |
network-drop | 原样重试,视为瞬时故障 |
tool-error | 换模型重试 |
unknown | 原样重试一次,再失败则放弃 |
同一任务重试 2 次后,优先放弃(从计划中删除,围绕它重新规划)而不是第 3 次尝试,除非有具体证据表明下次会成功。
delegate_task(
goal="<具体目标>",
context="""worker 行为规范 + handoff 模板(如上) + 任务专属约束""",
toolsets=['coding'] # 或具体子集
)
delegate_task(tasks=[
{"goal": "子任务 A", "context": "...", "toolsets": ["coding"]},
{"goal": "子任务 B", "context": "...", "toolsets": ["coding"]},
])
每个子任务应该目录不重叠或明确不冲突,否则会打架。
type-check-only 和 not-verified 必须送 code-reviewer