📚 工程方法 全难度 📦 community

othmanadi-planning-with-files

参考 Manus 的 Agent 方法论,特别适合多步骤复杂任务。

📄 相关文章

📊 评分明细

📦 打包完整度
2.1 2.1 / 2.5
🎯 实用性
2.1 2.1 / 2.5
📖 文档清晰度
1.7 1.7 / 2
👥 社区影响力
1.3 1.3 / 1.5
🔗 集成度
1.3 1.3 / 1.5

🎯 适用场景

免费项目管理设计模式

othmanadi-planning-with-files 快速入门

把”复杂任务”拆成”文件 + 计划”,让 AI Agent 跨上下文窗口也能不丢思路。

这是什么?解决什么问题?

LLM 的上下文窗口是有限的(Claude Sonnet/Opus 是 200K token,听起来大,但如果你塞进 10 个文件全文,马上就不够)。Agent 处理长任务时,最常见的痛点就是”做到一半忘了开头说的什么”——这并不是模型”笨”,而是上下文被新信息覆盖,旧计划”掉”了。
othmanadi-planning-with-files(社区别名)出自 OthmanAdi 仓库,核心理念借鉴了 Manus Agent 的方法论:用文件作为计划的载体。具体做法是:在动手前,AI 先把整个任务拆解成多个子步骤,写入 .plan.md 文件;每完成一步,更新一次文件状态。这样即使上下文窗口滑动丢失了早期对话,只要读一下 .plan.md 就能”接续”。
这种”文件即计划”的方法,解决了几个核心问题:跨上下文窗口续命、多 Agent 协同(共享同一份 plan 文件)、人类可介入(人随时打开文件 review)、可回溯(完成过程都写在 commit 历史里)。
适合:多步骤复杂任务(迁移、重构、新功能立项)、长会话(超过 1 小时)、需要中途切换 Agent 的工作流。

准备工作

  1. Claude Code / Cursor / 任何支持 Skill 的 AI 客户端
  2. Git 仓库:方便跟踪 plan 文件变更
  3. 项目根目录:.plan.md 放在 docs/ 或项目根
  4. 可选:markdownlint 校验 plan 文件格式

3 步快速上手

第 1 步:安装 Skill

npx skills add OthmanAdi/planning-with-files --skill othmanadi-planning-with-files<br>
```<br>
仓库:https://github.com/OthmanAdi/planning-with-files<br>
### 第 2 步:验证 Skill<br>
向 AI 询问:<br>
```<br>
用 othmanadi-planning-with-files Skill,解释一下"文件即计划"的核心思想<br>
```<br>
如果 AI 提到了"plan 文件"、"状态追踪"、"跨会话续命"等关键词,说明 Skill 加载成功。<br>
### 第 3 步:用 Skill 写第一个 plan<br>
```<br>
我要把项目从 JavaScript 迁移到 TypeScript,这是个 5 步骤的复杂任务,<br>
请用 othmanadi-planning-with-files Skill 帮我生成 .plan.md,涵盖:<br>
1. 配置文件准备 2. 类型定义 3. 代码迁移 4. 测试 5. 清理<br>
```<br>
AI 会输出结构化的 plan 文件,带每步的子任务、风险、依赖关系。<br>
## 常见踩坑<br>
1. **plan 写得太粗**:3 句话的 plan 等于没 plan,要每步有"具体动作 + 完成标准"。<br>
2. **plan 没更新状态**:AI 写完 plan 就不管了,做完一步不更新 → 状态全错。Skill 默认会强制每步末尾更新 `[x]`。<br>
3. **plan 和实际偏离**:做到一半发现 plan 不合理,没回头改 plan,导致后续步骤对不上。要"边做边迭代 plan"。<br>
4. **plan 文件太多**:每个 task 都建新 plan,git 仓库里堆了 20 个 plan 文件,反而混乱。建议一个项目共用一个 `MASTER_PLAN.md` + 子 plan。<br>
5. **没考虑回滚**:plan 里只写了"怎么做",没写"出问题了怎么回滚",线上事故后手忙脚乱。Skill 会主动建议加 "Rollback Plan" 段。<br>
6. **复杂度过高**:把 50 步骤塞进一个 plan,人 review 不动。Skill 会主动建议"超过 20 步要拆 plan"。<br>
## 初级用法<br>
1. **新功能立项**:写 plan 时包含"目标、范围、里程碑、风险、依赖"。<br>
2. **重构任务**:写 plan 时加"行为不变性验证"、"测试基线"两段。<br>
3. **跨会话续命**:长任务中途关闭,下次开新会话先说"读一下 .plan.md,继续上次的任务"。<br>
## 高级玩法<br>
1. **多 Agent 协同**:父 Agent 写 plan,派子 Agent 执行,每个子 Agent 完成后更新 plan 中的自己部分。<br>
2. **人类 review 介入**:把 plan 文件提 PR,人类 reviewer 评论"这一步应该先做 X",Agent 根据反馈调整 plan。<br>
3. **复盘归档**:项目结束后把 .plan.md 移到 `docs/history/`,作为决策记录留档,新成员上手时回顾。<br>
## 小技巧<br>
- plan 模板用 Markdown checkbox `- [ ]` / `- [x]`,Skill 解析更准确。<br>
- 每步加 "Done when..." 描述,完成标准明确,避免主观争议。<br>
- 用 `git log --all -- .plan.md` 看 plan 的演化历史,复盘"实际路径 vs 计划路径"。<br>
- plan 文件不要 commit 到主分支的"代码" commit,单独开 `docs:` 类型 commit,review 时显眼。<br>
- 大任务拆成多个 plan 串联(plan-001 → plan-002),每个 plan 完成后归档,避免单个文件过大。<br>
- 把"踩过的坑"也写进 plan,下次类似任务直接参考,plan 越用越聪明。<br>
## 常见问题 FAQ<br>
**Q1: 这个 Skill 跟 othmanadi-planning-with-files 有什么关系?必须装吗?**<br>
A: Skill 是给 AI Agent 用的"技能包",能告诉 Agent 怎么按特定规范工作。**不是必须装**——如果你的项目规模小、要求不高,不装也能用。但装上能让 Agent 输出的质量更高、更符合最佳实践,推荐装。<br>

**Q2: 这个 Skill 适合哪些 AI Agent?Cursor?Claude Code?其他?**<br>
A: othmanadi-planning-with-files 来自 community,主要面向支持 Skill 机制的 Agent。常见兼容 Agent 包括 Claude Code、Cursor、OpenCode、Windsurf 等。具体兼容性请查 Skill 官方文档。<br>

**Q3: 装了这个 Skill 后,会拖慢 Agent 响应吗?**<br>
A: 会的——Skill 通常会增加 prompt 长度,导致响应变慢、token 消耗增加。但质量提升明显。建议:1) 只装项目必需的 Skill;2) 用 Skill 启动/加载/卸载机制按需加载;3) 定期清理不用的 Skill。<br>

**Q4: 怎么验证 Skill 装对了?**<br>
A: 在 Agent 中输入"列出已加载的 Skill"或类似命令。如果 Skill 出现在列表里,说明装对了。然后用 Skill 跑一个相关任务,看输出是否符合 Skill 规范。<br>

## 参考链接<br>
- [Skill 仓库](https://github.com/OthmanAdi/planning-with-files)<br>
- [Manus Agent 方法论(原始灵感)](https://manus.im/)<br>
- [Anthropic Claude 长上下文技巧](https://docs.anthropic.com/)<br>
- [OpenAI Planning 模式](https://platform.openai.com/docs/guides/function-calling)<br>
- [Markdown checkbox 规范](https://github.blog/changelog/2022-05-26-unordered-task-lists-are-now-supported-in-markdown/)

idea-refine Skill 多维度简评

类别:上下文工程 / 任务规划 仓库:OthmanAdi/planning-with-files 维护者:OthmanAdi


一、核心定位与价值

planning-with-files 的核心思想来自 Manus 的上下文工程方法论——用文件系统替代易失的 Context Window,把抽象的”上下文工程”变成可落地的 3 文件工作流。

关键洞见:真正限制 AI 能力的不是模型参数,而是”上下文管理”——通过结构化的文件系统持久化,可以让 AI 在处理复杂多步骤任务时保持专注。

6 大核心原则

原则核心原理解决的问题
文件系统即外部记忆用磁盘替代易失 Context Window,仅保留路径指针上下文丢失
注意力操纵重复读取关键文件,强制刷新模型注意力中间迷失
失败痕迹保留显式记录错误尝试,通过反思避免死循环重复犯错
少样本过拟合规避受控变体防止机械性幻觉模式僵化
稳定前缀优化固定文件结构降低 Token,最大化 KV-Cache 命中率成本失控
只增不改上下文追加而非修改,维护上下文连贯性信息丢失

适用场景

  • 复杂多步骤任务
  • 长会话(超过 50 轮)
  • 频繁上下文溢出
  • 复杂项目(> 1 周)

不适用场景

  • 简单问答
  • 1 行修改
  • 短会话

二、3 文件工作流(核心)

2.1 文件结构

# 项目目录
my-project/
├── task_plan.md    # 指令寄存器:目标 / 状态 / 错误日志
├── findings.md     # 知识库:调研数据 / 中间成果
└── deliverable.md  # 成果输出:最终产物

2.2 task_plan.md(指令寄存器)

作用:Agent 的”中央处理器”,不存储具体知识,只维护元数据

# Task Plan

## Goal
[用户需求 → 1 句话目标]

## Milestones
- [x] Phase 1: 需求澄清
- [ ] Phase 2: 架构设计
- [ ] Phase 3: 实施
- [ ] Phase 4: 测试
- [ ] Phase 5: 部署

## Sub-tasks
- [x] 1.1 收集需求
- [x] 1.2 风险评估
- [ ] 2.1 架构图
- [ ] 2.2 技术选型
...

## Errors / Blockers
- 2026-06-15 14:30: API 限流,需等待 1 小时
- 2026-06-15 15:00: 找到 workaround:加 retry 逻辑

## Key Decisions
- 选 PostgreSQL 而非 MongoDB:团队熟悉 + 强一致性需求
- 用 TanStack Query 而非 SWR:生态更广

## Read-Before-Decide
每次重要决策前必读此文件

关键规则:

  • 每次关键决策前必读(Read-Before-Decide)
  • 失败显式记录(避免重复)
  • 状态用复选框([x] / [ ])

2.3 findings.md(知识库)

作用:存储所有调研数据 + 中间成果。

# Findings

## 技术调研
### TensorFlow 优化
- XLA 编译加速
- 静态图模式 batch_size 建议 64
- 官方文档: https://...

### 数据库选型对比
| DB | 性能 | 团队熟悉度 | 运维成本 |
|---|---|---|---|
| Postgres | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| MongoDB | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
| ClickHouse | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |

## 错误案例
- API 超时 → 加 retry + exponential backoff
- 内存爆炸 → 流式处理 + chunking

## 用户反馈
- 用户 A:希望支持暗黑模式
- 用户 B:移动端体验差
- 用户 C:需要导出 CSV

设计哲学:“Store, Don’t Stuff”——不要在 Context 中塞入太多信息,只保留关键结论。

2.4 deliverable.md(成果输出)

作用:最终产物的唯一载体。

# Deliverable

## 项目名称
[项目名]

## 版本
v1.0.0 - 2026-06-15

## 核心功能
- 功能 1
- 功能 2
- 功能 3

## 技术栈
- Next.js 14
- PostgreSQL 16
- TailwindCSS 3

## 部署说明
```bash
git clone ...
pnpm install
pnpm dev

已知限制

  • 不支持 IE11
  • 文件上传最大 10MB

---

## 三、与 Context Window 限制的斗争

### 3.1 4 大 LLM 致命痛点 + 3 文件解法

| 痛点 | 症状 | 3 文件解法 |
|---|---|---|
| **易失性记忆** | 多轮对话后变量定义遗忘 | 文件系统持久化,即使会话重置仍能恢复 |
| **目标漂移** | 50 步执行后忘记原始目标 | 强制 Read-Before-Decide |
| **错误隐藏** | API 调用失败后默默重试死循环 | Error Persistence 机制 |
| **上下文过载** | 5000 字协议全文塞进 Context | 数据卸载,仅保留关键结论 |

---

## 四、三层缓存模型

[1] Working Memory(工作记忆)

  • 当前 Context Window
  • 高频访问
  • 容量有限 ↓ [2] Short-term Memory(短期记忆)
  • task_plan.md + findings.md
  • 中频访问
  • 容量大(磁盘) ↓ [3] Long-term Memory(长期记忆)
  • 历史项目 + 知识库
  • 低频访问
  • 容量无限

---

## 五、与其他 Skill 配合

| Skill | 配合方式 |
|---|---|
| **superpowers/brainstorming** | 用 brainstorming 探索需求后,planning-with-files 落地 |
| **superpowers/writing-plans** | writing-plans 的 task 拆解可写入 task_plan.md |
| **superpowers/verification-before-completion** | 在 deliverable.md 标注验证状态 |
| **OpenSpec** | OpenSpec 输出可整理到 findings.md |

完整工作流:

[1] brainstorming (需求探索) ↓ [2] 初始化 3 文件

  • task_plan.md (目标 / 阶段)
  • findings.md (知识调研)
  • deliverable.md (成果占位) ↓ [3] writing-plans (任务拆解 → 写入 task_plan) ↓ [4] 实施
  • 每步更新 task_plan 状态
  • 失败记录到 Errors
  • 新知识写入 findings ↓ [5] 验证
  • verification-before-completion
  • 更新 deliverable ↓ [6] finishing-a-development-branch (合并)

---

## 六、5 大反模式

### 6.1 3 文件全塞 Context

```python
# ❌ BAD - 把整个 task_plan / findings / deliverable 塞进 Context
prompt = f"任务计划:\n{task_plan}\n调研:\n{findings}\n成果:\n{deliverable}\n请..."
# Context 爆炸

解决:只读必要部分,用 Read 工具按需读。

6.2 任务粒度太粗

# ❌ BAD
- [ ] 实现贪吃蛇游戏
# ✅ GOOD
- [ ] 1.1 画网格
- [ ] 1.2 蛇移动逻辑
- [ ] 1.3 食物生成
- [ ] 1.4 碰撞检测
- [ ] 1.5 分数记录
- [ ] 1.6 难度选择 UI

6.3 不更新 task_plan

解决:每步完成后立即更新

6.4 Errors 字段不写

# ✅ GOOD
## Errors / Blockers
- 2026-06-15 14:30: API 限流 429
  解决:加 retry with exponential backoff
- 2026-06-15 16:00: 内存爆炸 4GB
  解决:流式处理

6.5 deliverable.md 永远空

解决:每完成里程碑,更新 deliverable


七、安装

# Clone 仓库
git clone https://github.com/OthmanAdi/planning-with-files.git

# 复制 skill 到 Claude 配置目录
cp -r planning-with-files/skills/* ~/.claude/skills/

# 或通过 npx
npx skills add othmanadi/planning-with-files

八、Q&A

Q: 跟 writing-plans 区别? A: writing-plans 是 1 个 plan;planning-with-files 是持续 3 文件工作流。

Q: 跟 OpenSpec 区别? A: OpenSpec 一次性 propose+archive;planning-with-files 持续追加。

Q: 必须用 Claude 吗? A: 任何支持 Skills 的 Agent 都可。目前已支持 Claude Code、Cursor、Codex、Gemini CLI、GitHub Copilot 等多个平台。

Q: 中文支持? A: 完美。3 文件可全中文。


本文基于官方文档和公开资料整理,未经过 MagicNetWorld 实测。

参考资料

📊 评分与标签

评分说明

总分 8.4/10 · P_优选

📊 可观测社区指标(数据核验日期:2026-07-23)

📦 可安装性 2.2/2.5

  • 仓库包含多 Agent 目录、脚本和模板,可按宿主环境加载;功能完整也带来更多文件与脚本依赖。
  • 对比 Superpowers Executing Plans、Anthropic Skills:本项安装边界与依赖透明度按官方资料计分,未把平台账号或宿主能力误算为 Skill 自身能力。

🎯 实用性 2.3/2.5

  • 通过 task_plan、findings、progress 等持久文件维持多步骤任务状态,并提供恢复与完成检查脚本。
  • 对比 Superpowers Executing Plans、Anthropic Skills:评分关注本项能解决的具体任务与约束,不以仓库热度代替实际功能证据。

📖 文档质量 1.7/2.0

  • SKILL.md、examples、reference 和模板齐全,且提供 PowerShell 与 Shell 脚本,跨平台说明充分。
  • 对比 Superpowers Executing Plans、Anthropic Skills:能从公开资料复核的安装、边界和示例计入本维度,无法复核的宣传性描述未计分。

👥 社区活跃 1.0/1.5

  • GitHub API 返回 ★25,627、Fork 2,157,仓库在 2026-07-22 仍有更新。
  • 社区分只反映核验日可观察的仓库级信号;与 Superpowers Executing Plans、Anthropic Skills 的规模差异不直接推导输出质量。

🔗 兼容性 1.2/1.5

  • 提供 Claude、Codex、Cursor、Kiro、OpenCode、Pi 等多种布局;宿主对 hooks 与脚本能力支持不同。
  • 对比 Superpowers Executing Plans、Anthropic Skills:兼容性按已公开支持的协议、平台和运行条件计分,不推定未声明的客户端可用。

评分依据可追溯至公开来源,每项分数均有明确理由和数据支撑。

局限与使用边界

  • 文件账本会增加仓库噪声和维护成本;小任务不一定值得启用,敏感发现也不应写入可公开提交的文件。
  • 本评分是公开资料审查,不代表在所有宿主、账号权限和生产数据集上完成独立实测。

🏷️ 标签说明

  • 免费: 该标签对应条目公开描述与仓库能力边界。来源:主要核验来源
  • 项目管理: 该标签对应条目公开描述与仓库能力边界。来源:主要核验来源
  • 设计模式: 该标签对应条目公开描述与仓库能力边界。来源:主要核验来源

📋 来源核验记录

  • ✅ 已核验:主要官方来源
  • ✅ 已核验:GitHub 仓库或登记地址
  • ✅ 已核验:GitHub API 元数据
  • ⚠️ 间接来源:站内 JSON 的名称、标签与固定总分仅用于一致性校验,维度证据以以上公开来源为准。
  • ❌ 已删除死链:无;若登记仓库返回 404,已在正文明确标注并未引用其社区数字。