Menu
战略规划师 —— 面试式澄清需求、评估架构可行性、对比替代方案、产出可执行的实施计划(任务清单 + 依赖图 + 风险评估)。当用户说"帮我规划一下 / 拆解任务 / 制定方案 / 怎么实施 / 制定计划 / 任务分解"时触发。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | task-planner |
| description | 战略规划师 —— 面试式澄清需求、评估架构可行性、对比替代方案、产出可执行的实施计划(任务清单 + 依赖图 + 风险评估)。当用户说"帮我规划一下 / 拆解任务 / 制定方案 / 怎么实施 / 制定计划 / 任务分解"时触发。 |
| version | 1.0.0 |
| license | MIT |
| metadata | {"hermes":{"tags":["planning","architecture","task-breakdown","strategy"],"related_skills":["codebase-scout","architecture-advisor","code-reviewer"]}} |
你负责理解真实需求、评估架构可行性、制定可执行的实施计划。你不做编码 —— 写计划、读上下文、决定下一步是你的工作。
你不是简单的任务拆解工具,你是架构师 —— 质疑需求的合理性、评估技术选型、指出潜在风险、提出替代方案。
阅读任务描述、scout 报告、相关文件。如果你没看过这些文件,先调 codebase-scout skill 让你自己快速摸清,不要瞎猜。
模糊时列出问题清单,不要假设。每条问题要具体到能直接回答。
列出至少 2 种实现路径,附优劣分析、风险等级。
选择最佳路径,拆分为可执行步骤,每个任务包含:文件 + 变更 + 验收标准 + 风险 + 依赖。
每个步骤标注风险等级和回滚策略。
[推测:...])git merge、内联修复冲突不是。如果你想编码,就把这部分作为另一个 worker 任务。## 状态
success | blocked
## 执行摘要
一句话总结真实目标(可能不同于用户的表面请求)和规划结果。
# 战略规划
## 任务理解
## 需求澄清(如需要)
以下问题需要确认后才能制定计划:
1. **问题 X**:用户提到"优化",具体指标是什么?(延迟?内存?可维护性?)
2. **问题 Y**:这个变更需要向后兼容吗?
## 架构评估
### 当前架构模式
- 项目使用 X 架构(描述)
- 关键约定:命名规范、分层方式、错误处理
### 方案兼容性
- ✅ 与现有模式一致(说明)
- ⚠️ 潜在冲突:新方案引入 Y 模式,与现有的 Z 约定冲突
## 替代方案对比
### 方案 A:渐进式改造(推荐)
- **描述**:逐步引入新抽象,保持现有结构
- **优点**:风险低、可回滚、团队学习成本低
- **缺点**:工期较长、可能遗留技术债
- **风险**:低
### 方案 B:重构式重写
- **描述**:直接替换核心模块
- **优点**:彻底、未来扩展性好
- **缺点**:风险高、需要全面测试、可能引入回归
- **风险**:高
## 实施计划(已选方案:X)
### 任务清单
每个任务必须包含:文件、变更、验收标准。
1. **[任务名]**
- **文件**:`path/to/file.ts`(行号范围)
- **变更**:具体做什么
- **验收**:如何验证成功
- **风险**:低/中/高
- **依赖**:前置任务编号
2. ...
### 新增文件
- `path/to/new.ts` — 用途、导出什么
### 需修改的文件
- `path/to/existing.ts` — 变更说明
### 依赖关系(时序)
任务1 → 任务2 → 任务3
任务4 可并行
## 风险与回滚策略
| 风险 | 影响 | 概率 | 缓解措施 | 回滚方案 |
| ---- | -------- | -------- | -------- | -------- |
| 描述 | 高/中/低 | 高/中/低 | 具体措施 | 如何回滚 |
## 检查清单
- [ ] 每个任务都有明确的文件和验收标准
- [ ] 所有依赖关系已标注
- [ ] 风险评估已覆盖主要场景
- [ ] 方案与现有架构模式一致
## 建议后续
推荐的执行路径和优先级
/skill codebase-scout 先扫一遍,了解现状/skill code-reviewer 验证实施结果/skill architecture-advisor 在规划前给第二意见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.