CC Rules - 编程工作流规范

借鉴业界顶级 AI 编程工具的工作流模式，为 OpenClaw 注入结构化的软件开发行为规范。

激活条件

当用户涉及以下场景时自动激活本 Skill：

• - 编写、修改、重构代码
• 项目架构分析和设计
• Git 操作（commit、branch、merge）
• 调试和排查 Bug
• 代码审查（review）
• 项目初始化和配置

核心规则

一、Plan Mode — 先想后做

面对非平凡的编码任务，必须遵循 探索 → 理解 → 规划 → 确认 四步流程。

什么时候必须进入 Plan Mode

• - 添加新功能（不只是修个 typo）
• 存在多种实现方案需要选择
• 修改会影响 3 个以上文件
• 需要做架构决策（选什么框架、用什么模式）
• 用户需求不够清晰需要先搞明白
• 重构或大规模改动

什么时候可以跳过 Plan Mode

• - 用户给了非常具体的指令，照做就行
• 只改一两行的小修复
• 纯粹的研究/探索任务
• 用户明确说直接做或不用规划

Plan Mode 流程

1. 1. 只读探索

- 用 Glob/Grep 定位相关文件 - 用 Read 阅读关键代码 - 用 exec 跑 git log/diff/status 了解现状 - ⚠️ 此阶段禁止修改任何文件

1. 2. 理解架构

- 找到类似功能作为参考 - 梳理代码依赖关系 - 识别项目的编码规范和约定

1. 3. 输出方案

- 分步骤描述实现计划 - 标明需要修改哪些文件 - 说明选择某种方案的理由 - 预判可能的风险和挑战

1. 4. 等待确认

- 方案需要用户批准后才动手 - 用户可以要求修改方案 - 用户可以说直接开始跳过确认

Plan Mode 输出格式

实现方案：[任务名称]

背景

简述现状和要解决的问题

方案概述

一句话说清楚怎么做

实施步骤

1. 1. 修改 path/to/file1.ts — 做什么，为什么
2. 修改 path/to/file2.ts — 做什么，为什么
3. 新建 path/to/file3.ts — 做什么，为什么
4. 运行测试验证

关键文件

• - path/to/file1.ts — 核心逻辑
• path/to/file2.ts — 配置入口

风险点

• - 某处改动可能影响 XX 功能

---

二、任务追踪 — 做到哪了心里有数

复杂任务（3 步以上）必须创建任务清单。

状态规则

状态	含义	规则
⏳ 待办 (pending)	还没开始	按优先级排列
🔄 进行中 (in_progress)

正在做 | 同一时间只能有一个 | | ✅ 完成 (completed) | 做完了 | 完成后立刻标记，不要攒着 | | ❌ 阻塞 (blocked) | 卡住了 | 写清楚卡在什么，怎么解决 |

使用规则

• - 开始工作前标记为 in_progress
• 完成后立即标记 completed，不要等做完一批再标
• 遇到阻塞不要硬做，标记 blocked + 新建一个解阻塞任务
• 如果过程中发现新任务，追加到清单里
• 不相关的任务从清单中移除

任务描述格式

每个任务需要两个形式：

• - content: 命令式描述（修复登录验证逻辑）
• activeForm: 进行时描述（正在修复登录验证逻辑）

---

三、只读探索模式 — 搞懂再动手

当需要理解代码但不需要修改时，进入只读探索模式。

允许的操作

• - read — 阅读文件内容
• exec 中的只读命令：ls、cat、head、tail、find、grep
• exec 中的 git 只读命令：status、diff、log、show、blame

禁止的操作

• - write — 创建文件
• edit — 修改文件
• exec 中的写入命令：mkdir、touch、rm、cp、mv、git add、git commit
• 重定向写入：>、>>、tee
• 安装依赖：npm install、pip install 等

探索输出

探索完成后总结：

• - 项目结构概述
• 相关文件列表和各自职责
• 代码调用链路
• 发现的问题或改进建议

---

四、Git 安全协议 — 不作死

绝对禁止（除非用户明确要求）

• - git push --force / git push -f
• git reset --hard
• git checkout . / git restore .
• git clean -f / git clean -fd
• git branch -D
• git rebase -i（需要交互式输入）
• --no-verify / --no-gpg-sign（跳过 hooks）
• git commit --amend（除非用户明确说修改上一次 commit）

Commit 流程

1. 1. 并行执行：

- git status （查看变更文件） - git diff （查看具体改动） - git log --oneline -10 （了解项目 commit 风格）

1. 2. 分析变更：

- 概括改动性质（新功能 / 增强 / 修复 / 重构 / 测试 / 文档） - 排除含敏感信息的文件（.env、credentials.json 等） - 写 1-2 句 commit message，聚焦为什么改而不是改了什么

1. 3. 执行提交：

- 用 git add 按文件名逐个添加（不用 git add -A） - commit message 用 HEREDOC 格式传递 - 提交后 git status 验证

1. 4. 如果 pre-commit hook 失败：

- 修复问题 → 重新 stage → 创建新 commit - 不要用 --amend（会覆盖之前的 commit）

Commit Message 规范

类型: 简短描述（1行，不超过72字符）

• - 新功能: feat: 添加用户注册接口
• Bug修复: fix: 修复登录超时未重试的问题
• 重构: refactor: 拆分订单服务为独立模块
• 文档: docs: 更新 API 接口文档
• 测试: test: 补充用户模块单元测试
• 配置: chore: 升级依赖版本

不要提交的文件

• - .env、.env.local、含密钥的配置文件
• node_modules/、pycache/、venv/
• IDE 配置（.idea/、.vscode/ 除非是团队共享的）
• 大型二进制文件（用 .gitignore 排除）

---

五、多文件变更策略 — 有序不乱

当一个任务涉及多个文件时：

1. 1. 先改被依赖的（底层模块、类型定义、工具函数）
2. 再改依赖方（上层业务逻辑、UI 组件）
3. 最后改配置和入口
4. 每改完一个逻辑单元就验证一次，不要攒到最后

---

六、代码写完之后 — 善后

完成编码后：

1. 1. 检查是否需要更新相关文档
2. 检查是否有遗漏的 TODO
3. 如果改了接口/类型，检查调用方是否需要同步修改
4. 跑一遍测试（如果项目有的话）
5. 检查 lint / format 是否通过