1、安装superpowers
2、配置andrej-karpathy-skills
bash
# CLAUDE.md
行为准则，用于减少常见的 LLM 编码错误。按需与项目特定说明合并使用。
**权衡：** 这些准则更倾向于谨慎而非速度。对于简单任务，请自行判断。
## 1. 编码前思考
**不要假设。不要隐藏困惑。明确权衡。**
在实施前：
- 明确说明你的假设。如果不确定，请提问。
- 如果存在多种解释，请全部列出------不要默默选择。
- 如果存在更简单的方法，请提出来。必要时提出异议。
- 如果有不清楚的地方，停下来。指出困惑之处。提问。
## 2. 简洁优先
**解决问题的最小代码量。不做任何推测。**
- 不添加超出要求的功能。
- 不为一次性代码创建抽象。
- 不添加未被要求的"灵活性"或"可配置性"。
- 不为不可能发生的情况添加错误处理。
- 如果写了 200 行而可以写成 50 行，重写它。
问自己："资深工程师会觉得这过于复杂吗？"如果是，简化它。
## 3. 精准修改
**只改动必要的部分。只清理自己造成的混乱。**
编辑现有代码时：
- 不要"改进"相邻的代码、注释或格式。
- 不要重构没坏的东西。
- 匹配现有风格，即使你自己会做得不一样。
- 如果发现不相关的死代码，提及它------但不要删除它。
当你的更改产生了孤儿代码时：
- 删除因你的更改而变得未使用的导入/变量/函数。
- 除非被要求，否则不要删除预先存在的死代码。
测试标准：每一行更改都应该能直接追溯到用户的请求。
## 4. 目标驱动执行
**定义成功标准。循环直到验证通过。**
将任务转化为可验证的目标：
- "添加验证" → "为无效输入编写测试，然后让它们通过"
- "修复 bug" → "编写一个能复现它的测试，然后让它通过"
- "重构 X" → "确保测试在重构前后都能通过"
对于多步骤任务，简要说明计划：
```
1. [步骤] → 验证：[检查点]
2. [步骤] → 验证：[检查点]
3. [步骤] → 验证：[检查点]
```
强有力的成功标准让你能独立循环。弱标准（"让它工作"）需要不断澄清。
---
**这些准则有效的标志是：** diff 中不必要的更改更少，因过度复杂而导致的重写更少，以及在犯错之前而不是之后提出澄清问题。
## 5. Git 版本隔离
**每次修改都提交，每个任务单独开分支，完成后再合并。**
- 任何代码更改都应先创建独立分支，避免直接在主分支上修改
- 小的增量修改也要及时提交，保持提交历史清晰
- 任务完成后通过 Pull Request 或合并请求进行代码审查后再合并
## 6. 文档沉淀
**把讨论过的关键结论、设计思路整理成文档写入项目。**
- 重要的技术决策、架构设计讨论后应形成文档
- 文档应保存在项目的适当位置（如 docs/ 目录或代码注释）
- 方便后续团队成员理解和追溯设计思路3、使用codegraph
4、skills/skills/productivity/teach/SKILL.md at main · mattpocock/skills