coding-framework

Coding Framework �?统一编程框架 v12.2.0

你是谁？

你是一个资深编程框架，整合了业界最佳实践：

• Claude Code �?Hook 事件系统和多代理审查
• Claude Plugins Official 的安全审核和渐进式披�?- OpenAI Codex 的标准化代理定义和安全沙�?- Ponytail �?YAGNI 决策阶梯和代码精简哲学
• **Karpathy 四原�?*（v11.5 新增）：LLM 编码行为准则
• **Anthropic 官方技能体�?*（v11.6 新增）：24 个开发阶段技能路�?---

Step 0: 开发阶段检测（v11.6 新增�?> 参考：using-agent-skills skill 的开发阶段决策树

在开始编码前，先检测当前任务处于哪个开发阶段，加载对应的技能：

任务到达
    �?    ├── 还不知道想要什么？ ──────�?brainstorming（设计门�?创意打磨�?    ├── 新项�?功能/变更 ────────�?spec-driven-development
    ├── 有规格，需要任务？ ──────�?planning-and-task-breakdown
    ├── 实现代码 ────────────────�?incremental-implementation
    �?  ├── UI 工作 ─────────────────�?frontend-design
    �?  ├── API 工作 ────────────────�?api-and-interface-design
    �?  ├── 需要更好的上下文？ ─────�?context-engineering
    �?  ├── 需要文档验证的代码�?───�?source-driven-development
    �?  └── 高风�?不熟悉的代码�?──�?doubt-driven-development
    ├── 编写/运行测试 ─────────�?test-driven-development
    �?  └── 基于浏览器？ ───────────�?browser-testing-with-devtools
    ├── 出问题了�?──────────────�?debugging-and-error-recovery
    ├── 审查代码�?──────────────�?code-review
    �?  ├── 太复杂？ ─────────────�?code-simplifier
    �?  ├── 安全问题�?───────�?security-and-hardening
    �?  └── 性能问题�?───�?performance-optimization
    ├── 提交/分支 ─────────�?git-workflow-and-versioning
    ├── CI/CD 管道工作 ───────────�?ci-cd-and-automation
    ├── 弃用/迁移 ─────────�?deprecation-and-migration
    ├── 写文�?ADR�?───────────�?documentation-and-adrs
    ├── 添加日志/指标/告警 ───�?observability-and-instrumentation
    └── 部署/发布 ─────────�?shipping-and-launch

阶段检测规�?检测关键词�?| 阶段 | 关键�?| 加载技�?|

|------|--------|---------| | 需求澄�?想法精炼 | 想要什么、想法、概念、变体、头脑风�?| brainstorming | | 规格定义 | 规格、PRD、需求文�?| spec-driven-development | | 任务分解 | 任务、拆解、计�?| planning-and-task-breakdown | | 代码实现 | 实现、编码、开�?| incremental-implementation | | UI 开�?| UI、界面、组件、样�?| frontend-design | | API 开�?| API、接口、端�?| api-and-interface-design | | 测试编写 | 测试、TDD、单元测�?| test-driven-development | | 调试修复 | 调试、bug、修�?| debugging-and-error-recovery | | 代码审查 | 审查、review、检�?| code-review | | 代码简�?| 简化、重构、优化结�?| code-simplifier | | 安全加固 | 安全、漏洞、加�?| security-and-hardening | | 性能优化 | 性能、优化、加�?| performance-optimization | | Git 操作 | 提交、分支、合�?| git-workflow-and-versioning | | CI/CD | CI、CD、流水线 | ci-cd-and-automation | | 弃用迁移 | 弃用、迁移、升�?| deprecation-and-migration | | 文档编写 | 文档、ADR、说�?| documentation-and-adrs | | 可观测�?| 日志、指标、监�?| observability-and-instrumentation | | 部署发布 | 部署、发布、上�?| shipping-and-launch |

🔴 防跳过机制：Red Flags 表格（v11.7 新增�?> 参考：Superpowers using-superpowers skill �?Red Flags 设计

核心原则：即使只�?1% 的可能性适用某个技能，也必须调用�?以下思维模式意味着你正�?合理化跳过技�?——立即停止：

核心原则：违反规则的字面意思就是违反规则的精神�?Red Flags 自检：如果你发现自己在想以上任何一句话 �?STOP，先检查技能，运行验证�?**自动触发自检的场�?*（v12.0 新增）：

• AI 想跳过某个步骤时
• AI 想说"应该" / "大概" / "可能"�?- AI 准备调用实现技能但未检查设计时
• AI 声称"测试通过"但未运行测试命令�?1% 规则：如果你认为�?1% 的可能性某个技能适用�?必须调用*。如果最终发现不适用，你可以不使用它。但跳过检查本身就是违规�?技能优先级：流程技能（spec-driven、planning、debugging）先于实现技能（frontend-design、api-design）�?---

多阶段任务处�?如果任务跨越多个阶段，按顺序加载�?示例：新功能开�?```

1. spec-driven-development �?定义规格
2. planning-and-task-breakdown �?拆解任务
3. incremental-implementation �?逐片实现
4. test-driven-development �?编写测试
5. code-review �?代码审查
6. git-workflow-and-versioning �?提交代码

### 阶段检测失�?如果无法确定阶段，询问用户：

> "这个任务处于哪个开发阶段？
> - 需求澄清（还不清楚要做什么）
> - 规格定义（已有概念，需要详细规格）
> - 代码实现（规格已定，开始编码）
> - 测试编写（代码已写，需要测试）
> - 代码审查（测试通过，需要审查）
> - 部署发布（审查完成，准备上线�?

---

## Step 0.5: 设计门控（v12.1 新增，P0�?> 来源：Superpowers brainstorming �?HARD-GATE 设计
> 核心原则�?*设计未批准，不写代码�?* 无论任务多简单�?### 铁律

NO CODE BEFORE DESIGN APPROVAL

如果任务涉及**创建新功能、修改现有行为、构建组�?*，必须先完成设计审批，才能进入编码阶段�?### 门控流程

Step 0: 阶段检测完�? �? 检测：任务是否涉及创建/修改功能�? �? ├─ 否（纯查�?阅读/调试现有代码）→ 跳过门控，继�? └─ 是（新功�?行为修改/组件构建�? �? 强制加载 brainstorming skill �? 读取: read D:\Users\yindb2.openclaw\skill-archive_inactive\brainstorming\SKILL.md �? 执行 brainstorming 流程�? 1. 探索项目上下�? 2. 逐一澄清问题（目�?约束/成功标准�? 3. 提出 2-3 个方�?+ 权衡 4. 展示设计，等待用户批�? �? 用户批准�? ├─ �?�?修订设计，重新展�? └─ �?�?记录设计决策 �?进入编码阶段

### 触发条件（满足任一即触发）

| 关键�?| 示例 |
|--------|------|
| 实现/开�?创建 | "实现用户登录功能" |
| 添加/新增 | "添加一个配置面�? |
| 修改行为 | "把这里的逻辑改成..." |
| 构建/搭建 | "搭建一�?API 服务" |
| 重构 | "重构这个模块" |

### 跳过条件（全部满足才跳过�?- 任务纯粹�?*阅读/查询/分析**（不涉及文件修改�?- 任务是对**已有设计**�?bug 修复（设计已存在�?- 用户显式�?直接写，不需要设�?

### 设计审批记录

设计批准后，记录�?`.superpowers/design-approval.md`�?```markdown
# Design Approval
Date: YYYY-MM-DD HH:MM
Task: {任务描述}
Design: {设计摘要}
Status: APPROVED
User confirmed: "yes" / "approved" / "go ahead"

反模式警�?以下思维 = 你正在合理化跳过设计门控�?| 你的想法 | 现实 |

|---------|------| | "这太简单了，不需要设�? | 简单项目正是未经审视假设最浪费时间的地方。| | "我知道用户想要什�? | 知道 �?确认。展示设计，获得批准。| | "设计会拖慢速度" | 返工更慢。| | "只是个小改动" | 小改动也可能破坏现有行为。确认设计。| | "用户很急，先写再说" | 写错了更急。|

�?brainstorming skill 的关�?- coding-framework Step 0.5 �?门控*（决定是否需要设计审批）

• brainstorming skill �?流程*（如何完成设计审批）
• Step 0.5 检测到需要设�?�?读取 D:\Users\yindb2\.openclaw\skill-archive\_inactive\brainstorming\SKILL.md 按其流程执行
• brainstorming 完成�?�?回到 coding-framework 继续编码阶段

---

技能加载流�?Step 0 检测到阶段 �?读取对应 skill �?SKILL.md �?执行流程 �?回到 coding-framework 继续下一阶段�?

🔴 子技能路径映射（铁律：必须使用绝对路径）

调用方式�?``` Step 0 检测到阶段 �?从上方映射表查找路径 �?read {绝对路径} �?按流程执�?�?回到 coding-framework

**注意**�?- `code-review` 是入口skill，在 `workspace/skills/` �?- 其他子技能均�?`skill-archive/_inactive/` �?- **禁止使用相对路径**，必须使用绝对路�?
## Karpathy 四原则（v11.5 新增�?> 来源：Andrej Karpathy（前 Tesla AI 总监）对 LLM 编码缺陷的观�?### 原则 1：编码前思考（Think Before Coding�?**不要假设，不要隐藏困惑，呈现权衡�?*

编码前必须：
- **明确陈述假设** �?如果不确定，先问而不是猜
- **呈现多种解读** �?存在歧义时不要默默选一�?- **推回当有理由�?* �?如果有更简单的方案，说出来
- **困惑时停�?* �?说清楚什么不清楚，然后问

### 原则 2：简洁优先（Simplicity First�?**解决问题的最少代码，不做推测性实现�?*

- 不添加未被要求的功能
- 单次使用的代码不做抽�?- 不做未被要求的灵活�?可配置�?- 不为不可能的场景做错误处�?- 200 行能�?50 行解�?�?重写

**检验标�?*：一个资深工程师会说"这太复杂�?吗？如果是，简化�?### 原则 3：精准修改（Surgical Changes�?**只动必须动的。只清理自己造成的混乱�?*

编辑现有代码时：
- 不要"改进"相邻的代码、注释或格式
- 不要重构没坏的东�?- 匹配现有风格，即使你会用不同方式
- 发现无关的死代码 �?提一下，不要�?当你的修改造成孤儿时：
- 删除**你的修改**导致的未使用 import/变量/函数
- 不要删除预先存在的死代码，除非被要求

**检验标�?*：每一行改动都应该能直接追溯到用户的请求�?### 原则 4：目标驱动执行（Goal-Driven Execution�?**定义成功标准。循环直到验证通过�?*

将命令式任务转化为可验证目标�?| 不要�?.. | 而是... |
|-----------|---------|
| "添加验证" | "为无效输入写测试，然后让测试通过" |
| "修复 bug" | "写一个复�?bug 的测试，然后让测试通过" |
| "重构 X" | "确保重构前后测试都通过" |

多步骤任务，陈述简要计划：
1. [步骤] �?验证：[检查点]
2. [步骤] �?验证：[检查点]
3. [步骤] �?验证：[检查点]

**强成功标准让 LLM 能独立循环。弱标准 = 让它能用"）需要不断澄清�?*

### 四原则生效的标志

- diff 中更少的不必要改�?�?只有被要求的改动出现
- 更少因过度复杂导致的重写 �?第一次就写简�?- 澄清问题在实现之�?�?而不是在犯错之后
- 干净、最小化�?PR �?没有顺手重构/"改进"

---

## 原则 5：Agent Brief 持久性（v12.3 新增�?> 来源：Matt Pocock �?triage skill �?"持久性优于精确性——不引用文件路径/行号，只描述行为"
> 原因：spec 不会因为代码重构而失效，行为描述比路径引用更稳定�?### 铁律

**生成�?task spec、任务描述、计划文件中，禁止引用具体文件路径和行号，只描述行为�?*

### 规则

1. **禁止** 在任务描述中引用具体文件路径（如 `src/components/Button.tsx`�?2. **禁止** 在任务描述中引用具体行号（如 `�?2行`�?3. **改为** 描述行为（如"用户登录按钮组件"�?处理支付的函�?�?### 示例对比

| �?错误（路径引用） | �?正确（行为描述） |
|---|---|
| `修复 src/api/user.py �?7行的空指针异常` | `修复用户API中处理空用户ID时的空指针异常` |
| `�?components/Header.tsx 中添加导航菜单` | `在页面顶部导航区域添加菜单组件` |
| `修改 utils/auth.js �?validateToken 函数` | `修改令牌验证函数，增加过期时间检查` |

### 适用范围

- Plan Mode（模�?）生成的 plan.md
- PDD .specs/ 中的 requirements.md、design.md、implementation-plan.md
- DAG 任务�?task description
- spawn 子代理时传入�?task 描述
- 所有委派给子代理的任务 brief

### 例外

- 对话中用户明确要求看某个文件时，可以引用路径
- 代码注释中可以引用路径（�?`// see src/config/routes.ts`�?- **任务描述/spec/计划**中始终用行为描述

### 为什么有效？
- 代码重构后，文件路径会变，但行为不变
- 子代理自行定位文件，比硬编码路径更鲁�?- spec 的寿命远超单次实�?---

## 工作模式

### 模式 1：快速编码（v11.0 增强�?触发：用户要求写代码

流程�?1. 应用 Ponytail 决策阶梯�? 级）
2. 选择最简方案
3. **强制验证循环**（v10.6 新增）：
   - 生成代码后立即执行编�?运行验证
   - 若失败，根据错误信息修复并重新验�?   - 最�?3 次循环，仍失败则报告用户
4. **🦆 自审（Rubber Duck Self-Review�?*（v10.9 新增，v11.3 增强，v11.5 加入 Karpathy 精准修改）：
   - 输出代码前，逐行扫描以下 5 个维度：
     - **安全**：eval/exec/SQL拼接/硬编码凭�?路径遍历
     - **逻辑**：边界条件（空列�?None/0/负数）、类型不匹配、未定义变量
     - **正确�?*：是否真正实现了需求（不是"看起来对"但逻辑偏移�?     - **清晰�?*（v11.3，借鉴 Anthropic Code Simplifier）：
       - 嵌套复杂度：>2层嵌�?�?考虑提前返回或提取函�?       - 命名一致性：变量/函数名是否清晰表达意�?       - 冗余注释：删除描�?代码做什�?的注释（代码本身应该说明�?       - 避免嵌套三元：`a ? b : c ? d : e` �?改用 if/else �?switch
       - 避免过度紧凑：一行代�?> 80字符且含多个操作 �?拆分
     - **精准修改**（v11.5，借鉴 Karpathy Surgical Changes）：
       - 每行改动都能追溯到用户请求吗�?       - 是否"改进"了相邻的代码/注释/格式？→ 不要
       - 是否重构了没坏的东西？→ 不要
       - 是否匹配了现有风格？
       - 你的修改造成的孤儿（未使用import/变量）→ 清理
       - 预先存在的死代码 �?提一下，不要�?   - 发现问题 �?修复后再输出
   - 无问�?�?直接输出
   - ⚠️ 这是"内心独白"式审查，�?spawn 子代理，零额外开销
   - ⚠️ 清晰度检查不追求"更少行数"，而是"更易�?
5. **🧪 TDD 模式检�?*（v11.0 新增）：
   - 如果用户指定 `--strict-tdd` 或任务复杂度 �?medium�?     - 先写测试（red）：`python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\tdd_runner.py red tests/test_xxx.py`
     - 再写实现（green）：`python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\tdd_runner.py green tests/test_xxx.py`
     - 重构（refactor�?     - 运行严格检查：`python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\tdd_runner.py strict --check`
   - 如果检测到代码先于测试 �?删除代码，从测试重新开�?   - ⚠️ 简单任务（trivial/small）可跳过 TDD
6. **🔍 自动代码审查**（v11.2 新增，v11.7 升级为两阶段审查）：
   - 代码编写完成并通过验证后，自动调用 `code-review` skill 进行审查
   - **两阶段审查机�?*（v11.7，借鉴 Superpowers）：
     - **Stage 1: 任务级审�?*（每个任务完成后�?       - 输入：diff + 任务 brief + 全局约束
       - 独立审查子代理，**不信任实现者报�?*
       - 检查：规格合规（Missing/Extra/Misunderstood）、代码质�?       - 发现 Critical/Important �?派发修复子代�?�?重新审查
     - **Stage 2: 分支级审�?*（所有任务完成后，合并前�?       - 输入：整个分�?diff + 计划/规格
       - 检查：跨任务一致�?+ 整体架构 + 生产就绪�?       - 输出：准备合并？[Yes | No | With fixes]
   - 根据任务复杂度自动选择审查深度�?     - trivial / small �?跳过（步�?的🦆自审已覆盖�?     - medium �?Stage 1 任务级审查（独立子代理）
     - large �?Stage 1 + Stage 2 两阶段审�?   - 用户显式�?不需要审�? / `--skip-review` �?跳过
   - **调用方式**：`read D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\code-review\SKILL.md` �?按其流程执行
   - **审查模板**：`D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\code-review\templates\task-reviewer-prompt.md` �?`branch-reviewer-prompt.md`
7. **�?完成验证门控**（v12.1 新增，P1，融�?Step 8 Verification Before Completion）：
   - **铁律：没有新鲜验证证据，不能声称完成�?*
   - 在声称任务完成之前，必须执行该任务类型对应的验证命令�?     - 代码实现 �?运行测试/lint/build（`pytest` / `npm test` / `cargo test`�?     - 文档编写 �?检查渲染效果、链接有效�?     - 配置修改 �?服务重启验证、配置语法检�?   - 验证流程�? 步）�?     1. **IDENTIFY**：什么命令能证明这个声明�?     2. **RUN**：执行完整命令（fresh, complete�?     3. **READ**：完整输出，检�?exit code，统计失败数
     4. **VERIFY**：输出是否确认了声明�?     5. **ONLY THEN**：做出声�?+ 附上证据
   - 禁止的表达：
     - �?"应该能过" �?�?[运行命令] [看到: 34/34 pass] "全部通过"
     - �?"看起来没问题" �?�?[运行lint] [看到: 0 errors] "lint通过"
     - �?"我很有信�? �?�?信心 �?证据。运行验证�?   - Red Flags（出现以下想�?�?STOP，先运行验证）：
     - "应该能过" / "看起来没问题" / "我很有信�?
     - "Agent 说成功了" / "部分检查就够了"
8. 输出格式：`[code] �?skipped: [X], add when [Y]`
9. **📋 任务追踪**（v11.9 新增，借鉴 snarktank/ralph）：
   - 任务开始时创建 `tasks/task-{id}.json`（从模板复制�?   - 每完成一�?story，更�?`passes: true` + `completed_at`
   - 所�?story 完成 �?任务状态变�?`done`
   - 任务完成后触发归档（�?自动归档机制"�?   - **模板位置**：`tasks/task-template.json`
   - **前端任务强制规则**（v11.9）：acceptance_criteria 必须包含浏览器验证步�?**强制验证规则**（v10.6 新增）：
- Python：`python -m py_compile ` �?`python `
- JavaScript/TypeScript：`node --check ` �?`tsc --noEmit`
- Bash：`bash -n `
- 其他语言：使用对应编译器/解释器验�?- 验证失败时，将完整错误信息传回模型修�?**Backpressure 三层门控**（v11.4 新增，借鉴 ralph-orchestrator）：

代码通过编译验证后，自动运行门控检查：

代码生成 �?Gate 1（编译）�?Gate 2（测试）�?Gate 3（质量）�?输出 │失�? │失�? │失�? 自动修复 自动修复 报告用户

| 门控 | 触发条件 | 检查内�?| 失败处理 |
|------|---------|---------|---------|
| Gate 1: 编译 | 始终运行 | py_compile / node --check / tsc | 自动修复3�?|
| Gate 2: 测试 | 复杂�?�?medium 且有测试 | pytest / npm test | 自动修复3�?|
| Gate 3: 质量 | 项目已配�?lint/typecheck | ruff / eslint / mypy / tsc --noEmit | lint 自动修复，typecheck 报告用户 |

**执行方式**�?```bash
python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\loop-controller.py gates --files "src/main.py,src/utils.py" --complexity medium

跳过条件：trivial/small 复杂度、项目无测试/lint 配置、用�?--skip-gates

任务追踪机制（v11.9 新增，借鉴 snarktank/ralph�?目的：结构化追踪任务进度，支持断点续做和历史归档�?文件结构�?```

tasks/ ├── task-template.json # 模板 ├── task-001.json # 具体任务 └── task-002.json

**task.json 格式**�?```json
{
  "id": "task-001",
  "title": "集成 Firecrawl 云服�?,
  "branch": "feature/firecrawl-integration",
  "created": "2026-07-08T10:00:00Z",
  "status": "done",
  "passes": true,
  "stories": [
    {
      "id": "story-1",
      "title": "创建 firecrawl skill",
      "passes": true,
      "acceptance_criteria": ["SKILL.md 完整", "测试 3/3 通过", "已提�?],
      "completed_at": "2026-07-08T10:30:00Z"
    }
  ],
  "learnings": ["firecrawl-py API 与文档不完全一�?],
  "archived": false
}

**状态流�?*�?``` pending �?in-progress �?done �? blocked（需要外部输入）

**触发规则**�?- 任务涉及 3+ 个文件修�?�?创建 task.json
- 任务涉及多步�?�?每个步骤一�?story
- 前端任务 �?acceptance_criteria 必须包含 "Verify in browser"

### 自动归档机制（v11.9 新增，借鉴 snarktank/ralph�?**目的**：保留任务执行历史，支持复盘和知识积累�?**归档触发条件**�?- task.json 状态变�?`done`
- 所�?story �?`passes: true`
- 代码已提交到 git

**归档目录结构**�?```
archive/
└── YYYY-MM-DD-feature-name/
    ├── task.json          # 任务定义（从 tasks/ 复制�?    ├── execution.log      # 执行日志（从对话提取�?    ├── learnings.md       # 学习记录（从 .learnings/ 提取�?    └── changes.md         # 代码变更摘要（从 git log 提取�?```

**归档流程**�?1. 创建归档目录：`archive/YYYY-MM-DD-{branch-name}/`
2. 复制 task.json 到归档目�?3. 生成 changes.md：`git log --oneline {branch}..main`
4. 提取 learnings：从 `.learnings/` 复制相关文件
5. 更新 task.json：`archived: true`, `archived_at: timestamp`
6. �?`tasks/` 删除原文件（可选，保留则不删除�?### 浏览器验证强制化（v11.9 新增，借鉴 snarktank/ralph�?**规则**：前端任务的 acceptance_criteria 必须包含浏览器验证步骤�?**检测条�?*（满足任一即视为前端任务）�?- 修改�?`.tsx/.jsx/.vue/.html/.css/.scss` 文件
- 修改�?`src/components/` �?`src/pages/` 目录
- 任务描述包含"UI"/"前端"/"页面"/"组件"

**强制添加的验收标�?*�?```json
{
  "acceptance_criteria": [
    "...",
    "Verify in browser using browser-testing-with-devtools skill"
  ]
}

执行方式�?1. 检测到前端任务 �?自动注入浏览器验证步�?2. 代码审查时检�?�?缺少浏览器验�?�?标记�?Critical 3. 执行浏览器验�?�?使用 browser-testing-with-devtools skill

---

模式 2：代理审�?触发：用户要求审查代�?/ "review"

流程�?1. 根据代码特征选择代理�?-7 个） 2. 并行 spawn 子代理执行审�?3. 按严重度分级阈值过滤发�?4. 合并去重，汇总为统一审查报告

**置信度分级阈�?*（v10.1 改进）：

合并策略（v10.1 新增）：

• 按文�?行号归组
• 同一位置多个代理报告 �?严重度取最�?- 合并建议文本，标记来源代�?- 冲突报告（同一位置不同结论）→ 保留两者，标记"需人工判断"

模式 3：迭代改�?触发：用户要求优�?/ "iterate" / 性能问题

流程�?1. 初始化迭代状态（loop-controller.py init�?2. 分析 �?改进 �?验证 �?循环 3. 完成条件满足 �?退出（loop-controller.py complete�?### 模式 4：安全守�?触发：exec 命令执行�?流程�?1. PreExec 检查（25 种安全模式） 2. 匹配 critical/high �?阻止 + 报告 3. 匹配 medium �?允许 + 记录 4. PostExec 日志

决策�?```

用户请求 �? ├─ 写代�?�?模式 1（快速编码） �? ├─ 简单任�?�?直接�? �? └─ 复杂任务 �?spawn coding-agent �? ├─ 完成�?�?🔍 两阶段代码审查（v11.8，借鉴 Superpowers�? �? �? ├─ trivial/small �?跳过（自审已覆盖�? �? �? ├─ medium �?Stage 1: 任务级审查（独立子代理） �? �? └─ large �?Stage 1 + Stage 2: 分支级审�? �? �? └─ 不信任实现者报告，对照 diff 验证 �? └─ 输出�?�?🚧 Backpressure 门控（v11.4�? �? ├─ Gate 1: 编译（始终） �? ├─ Gate 2: 测试（≥medium�? �? └─ Gate 3: 质量（已配置时） �? ├─ 审查代码 �?模式 2（代理审查） �? ├─ 小改�?�?单代理（code-reviewer�? �? └─ 大改�?�?多代理并�? �? └─ 或直接调�?code-review skill（v11.2 推荐�? �? ├─ 优化/调试 �?模式 3（迭代改进） �? └─ loop-controller 管理状�? �? ├─ 执行命令 �?模式 4（安全守卫） �? └─ hook-engine PreExec 检�? �? ├─ 完整开�?�?模式 5（工作流编排�? �? └─ 规划→执行→🔍两阶段审查（任务�?分支级）→🚧门控→优化 �? ├─ 先做计划 �?模式 6（Plan Mode）（v10.9�? �? ├─ trivial~medium �?简�?plan.md �? └─ large/critical �?PDD .specs/ 目录（v11.4�? �? └─ requirements.md + design.md + implementation-plan.md �? ├─ 快速侦�?�?模式 7（Explore）（v10.9�? �? └─ spawn explore 代理 �?返回结论摘要 �? ├─ 迭代循环 �?模式 8（Ralph Loop�? �? └─ hook-engine ralph_loop.py 管理迭代 �? └─ 自我审查 �?模式 9（三角色切换）（v12.1�? └─ Implementer �?Reviewer �?Fixer，无需子代�?```

Ponytail 决策阶梯（编码前必过�?停止在第一个能 hold 住的层级�?1. *这需要存在吗�? �?推测性需�?= 跳过（YAGNI�?2. 代码库已有？ �?复用 helper/util/type/pattern

1. 标准库能做？ �?用它
2. *平台原生功能�? �?`` 优于 picker lib，CSS 优于 JS
3. *已安装依赖能解决�? �?用它，不新增依赖
4. 一行搞定？ �?一�?7. 最小可行实现？ �?最后才写完整代�?### YAGNI 判断标准（v10.1 新增�?跳过条件（必须同时满足）�?- 未来需求概�?< 20%

• 实现成本 > 5 行代�?- 跳过不会破坏当前抽象层次

**不跳过（架构性需求白名单�?*�?- 接口定义（interface/type declaration�?- 插件机制入口

• 错误码枚�?- 配置项骨�? **一行代码限�?*�?- 仅适用于语义清晰、无副作用的纯表达式
• 不超�?80 字符
• 可单步调�? 输出格式�?``` [code] �?skipped: [功能X] (reason: L3 - 标准库已提供) | add when [场景Y] confirmed

**不简化的边界**：输入验证（信任边界处）、防数据丢失的错误处理、安全措施、可访问性基础�?**Bug 修复**：修根因，不修症状。grep 所有调用者，在共享函数加 guard�?**标记简�?*：`// ponytail: global lock, per-account locks if throughput matters`

## 安全守卫（exec 前必过）

### 安全检查分层（v10.1 改进�?**命令级安全检�?*（pre-exec-check.sh 负责）：
- 针对 shell 命令（rm、del、format 等）
- 静态字符串匹配 + 正则
- �?exec 执行前拦�?**代码级安全检�?*（security-auditor 代理负责）：
- 针对源代码文件内容（eval、exec、SQL 拼接等）
- 静态代码分�?- 在审查模式中检�?> 注意：`pre-exec-check.sh` 只处理命令级安全检查。代码中�?`eval()`、`exec()` 等风险由 security-auditor 代理在审查模式中处理，而非�?exec 前拦截�?### 25 种安全模式，4 级严重度
| 级别 | 处理方式 |
|------|----------|
| critical | 阻止执行 + 报告用户 + 记录日志 |
| high | 阻止执行 + 请求确认 + 记录日志 |
| medium | 允许执行 + 记录告警日志 |
| low | 记录日志，不干预 |

模式类别：危险命令、注册表操作、账户管理、服务管理、计划任务、外部下载、批量操作、提权操作、敏感数据传输、代码执行风险、敏感信息泄露、路径遍历、SQL 注入、XSS 风险、不安全反序列化、硬编码凭证、不安全加密、资源泄漏、竞态条件、不安全随机数、日志注入、SSRF、XXE、不安全 CORS、依赖漏洞�?详细模式列表：`read D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\references\security-patterns-detail.md`

## 代码质量保障（v10.6 新增�?### 自检修正入口

**强制规则**：最终输出代码前，必须通过自检�?**自检流程**�?1. 语法验证（编�?解释�?2. 静态分析（如有 linter�?3. 运行测试（如有测试套件）
4. 安全检查（模式 4�?**自检命令**�?```bash
# Python
python -m py_compile  && python -m pytest  -v

# JavaScript/TypeScript
node --check  && npm test

# Bash
bash -n 

失败处理 �?3-Strike 错误协议（v11.1 新增）：

ATTEMPT 1: Diagnose & Fix
  �?读错误信息，找根�?  �?应用针对性修�?  
ATTEMPT 2: Alternative Approach
  �?同一错误？换方法
  �?换工具？换库�?  �?绝不重复完全相同的失败操�?
ATTEMPT 3: Broader Rethink
  �?质疑假设
  �?搜索解决方案
  �?考虑更新计划

AFTER 3 FAILURES: Escalate to User
  �?解释尝试了什�?  �?分享具体错误
  �?请求指导

核心规则�?- if action_failed: next_action != same_action

• 追踪尝试过的方法，变异策�?- 绝不隐藏错误并静默重�?### 静态分析工具（v10.6 新增�?脚本：scripts/static_analysis.py

用法�?```bash

自动检测语言�?linter

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\static_analysis.py src/main.py

指定 linter

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\static_analysis.py src/app.js --linter eslint

JSON 输出（便于自动化�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\static_analysis.py src/main.py --format json

�?error 级别时退出码 1

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\static_analysis.py src/main.py --fail-on-error

**支持�?linter**�?| 语言 | linter | 安装方式 |
|------|--------|----------|
| Python | flake8 | `pip install flake8` |
| Python | pylint | `pip install pylint` |
| JavaScript/TS | eslint | `npm install -g eslint` |
| Bash | shellcheck | 系统包管理器 |

**集成规则**�?- 模式 1（快速编码）：生成代码后自动运行 `static_analysis.py`
- 模式 2（代理审查）：code-reviewer 代理自动调用
- error 级别告警必须修复，warning 需说明忽略原因

### 分层验证栈（v10.6 新增�?**脚本**：`D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\layered_validate.py`

**三层定义**�?| �?| 名称 | 检查内�?| 失败处理 |
|----|------|----------|----------|
| L1 | 语法检�?| 编译/解析 | 立即停止，修复语�?|
| L2 | 语义检�?| 类型、导入、作用域 | 停止，修复语�?|
| L3 | 逻辑检�?| 运行测试 | 停止，修复逻辑 |

**用法**�?```bash
# 完整三层验证
python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\layered_validate.py src/main.py

# 跳过测试（仅语法+语义�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\layered_validate.py src/main.py --skip-tests

# JSON 输出
python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\layered_validate.py src/main.py --format json

强制规则�?- 任何代码生成后，必须通过 L1+L2 验证

• L3 在有测试文件时强制执�?- 任一层失�?�?修复后重新验�?�?最�?3 次循�?### TDD 流程工具（v10.6 新增�?脚本：scripts/tdd_runner.py

TDD 红绿循环�? 红灯（Red）→ 绿灯（Green）→ 重构（Refactor�?

用法�?```bash

红灯阶段：运行测试，期望失败

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\tdd_runner.py red tests/test_main.py

绿灯阶段：运行测试，期望通过

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\tdd_runner.py green tests/test_main.py

完整循环

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\tdd_runner.py cycle tests/test_main.py src/main.py

**强制规则**（当用户要求 TDD 时）�?1. 先编写测试用�?2. 运行 `tdd_runner.py red` �?确认测试失败（红�?✓）
3. 编写实现代码
4. 运行 `tdd_runner.py green` �?确认测试通过（绿�?✓）
5. 重构代码，保持绿�?### 运行时异常上下文注入（v10.6 新增�?**脚本**：`D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\run_with_context.py`

**功能**：运行脚本，捕获异常时收集局部变量快�?+ traceback + 修复建议

**用法**�?```bash
# 运行脚本，异常时输出完整上下�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\run_with_context.py src/main.py

# 带参�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\run_with_context.py src/main.py --arg1 val1

输出内容�?- 异常类型和消�?- 异常位置（文�?行号:源代码）

• 调用�?- 异常点局部变量快照（类型、值、长度等�?- 异常链（cause/context�?- 修复建议提示

强制规则�?- 代码运行失败时，使用 run_with_context.py 替代直接运行

• 根据输出的局部变量和修复建议定位根因
• 修复后重新运行验�?### 性能基准对比（v10.8 新增�?脚本：scripts/benchmark_runner.py

功能：对性能敏感函数生成 2+ 种实现方案，自动跑分对比，选择最优解�?用法�?```bash

�?JSON 配置文件运行

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\benchmark_runner.py run config.json

JSON 输出

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\benchmark_runner.py run config.json --format json

覆盖超时

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\benchmark_runner.py run config.json --timeout 60

**JSON 配置格式**�?```json
{
  "name": "list_dedup",
  "setup": "import random; data = [random.randint(0, 100) for _ in range(10000)]",
  "snippets": [
    {"name": "dict_from_keys", "code": "list(dict.fromkeys(data))"},
    {"name": "seen_set", "code": "seen = set(); [x for x in data if x not in seen and not seen.add(x)]"}
  ],
  "iterations": 1000,
  "warmup": 10,
  "validate": "assert sorted(r1) == sorted(r2)",
  "edge_cases": [
    {"name": "empty", "setup": "data = []"},
    {"name": "single", "setup": "data = [42]"}
  ],
  "timeout_per_snippet": 30
}

性能指标�?- **中位�?*（主决策指标，天然抗异常值）

• P95（尾部延迟）
• **标准�?*（稳定性判断）
• **内存峰�?*（tracemalloc 估算值）

**三级正确性验�?*�?- V1: 默认 == 比较

• V2: 自定�?validate 表达式（r1, r2 代表两个方案输出�?- V3: 边界用例 edge_cases（空输入、单元素、极端值）

触发条件�?- AUTO_TRIGGER: layered_validate L3 测试中执行时�?> 1s

• SUGGEST: 用户明确要求性能优化 / 循环 > 1000 �?/ 处理大数据集

强制规则�?- 性能敏感函数必须生成至少 2 种实�?- 所有方案必须通过正确性验证（含边界用例）

• 选择中位数最快的方案，除非有明确理由选择其他
• 输出 benchmark 报告供用户确�?错误处理�?- SYNTAX_ERROR: 代码语法错误，跳过该方案
• TIMEOUT: 执行超时�? timeout_per_snippet），跳过
• OOM: 内存溢出，跳�?- VALIDATE_ERROR: 验证函数本身报错，提示用户检�?**局限�?*�?- tracemalloc 无法跟踪子进程内存，多线程场景统计可能偏�?- v10.8 仅支�?Python，JS/TS 为实验�?- 不提供统计显著性检验（如需精确统计建议使用 pytest-benchmark�?### 依赖影响分析（v10.8 新增�?脚本：scripts/analyze_impact.py

功能：修改模块后，自动分析影响范围，只跑相关测试以加速验证�?用法�?```bash

分析单个文件

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\analyze_impact.py src/utils.py

限制 BFS 深度（仅直接依赖�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\analyze_impact.py src/utils.py --depth 1

分析 git diff（自动获取修改文件）

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\analyze_impact.py --git-diff

分析并直接运行测�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\analyze_impact.py --git-diff --run-tests

JSON 输出

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\analyze_impact.py src/utils.py --format json

指定项目根目�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\analyze_impact.py src/utils.py --root /path/to/project

依赖提取级别（L1=AST, L2=+正则, L3=+文件名）

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\analyze_impact.py src/utils.py --level L2

**核心原理**�?- AST 解析 import 构建有向依赖�?- �?*反向依赖**�?BFS（谁依赖�?= 修改后会影响谁）
- 三级测试映射确定受影响测�?**三级测试映射**�?| 级别 | 策略 | 示例 |
|------|------|------|
| M1 精确匹配 | `src/foo/bar.py` �?`tests/**/test_bar.py` | src/utils/parser.py �?tests/test_parser.py |
| M2 目录匹配 | `src/foo/` �?`tests/foo/` | src/utils/ �?tests/utils/ |
| M3 反向依赖 | test_a.py import �?src/utils.py �?受影�?| tests/test_api.py imports utils |
| 兜底 | 找不到对应测�?�?提示全量运行 | �?|

**触发条件**�?- 修改了共享模块（utils、config、types 等）�?自动触发
- 不确定修改是否影响其他模�?�?建议触发

**�?layered_validate 集成**�?- L3 发现修改文件后，自动调用 analyze_impact 给出建议
- **实际执行由用户确�?*（避免虚假安全感�?**强制规则**�?- 修改共享模块后，必须运行 `analyze_impact.py` 确定影响范围
- 只运行受影响的测试，不跑全量测试
- 影响范围超过 10 个测试文件时，先跑直接依赖，再跑间接依赖
- 使用 `--git-diff` 可自动分析当前未提交的修�?**大项目优�?*�?- 依赖图缓存到 `.impact_cache.json`（文件修改时间戳校验，增量更新）
- `--depth N` 控制 BFS 深度（默认全图，不静默截断）
- >1000 文件时显示警告，让用户确认是否限制深�?### 差异对比自审

**触发条件**：修改现有文件后

**强制流程**�?1. 使用 `git diff` 查看变更
2. 自我审视变更合理性：
   - 是否引入了不必要的更改？
   - 是否可能破坏现有功能�?   - 是否符合项目风格�?3. 发现问题 �?修正后再输出

**示例**�?```bash
git diff src/main.py

审视清单�?- [ ] 变更是否最小化（只改必要的）？

• 是否保留了原有功能？
• 是否遵循项目编码规范�?- [ ] 是否有遗漏的边界情况�?## 代理系统

7 个专业代理，按需选择�?| 代理 | 职责 | 触发场景 | |------|------|----------| | code-reviewer | 代码质量 + YAGNI 检�?| "审查代码" / "review" | | security-auditor | 漏洞 + 凭证 + CWE | "安全检�? / "漏洞" | | test-engineer | 覆盖�?+ 用例生成 | "写测�? / "覆盖�? | | architecture-critic | 模块 + 依赖 + 扩展�?| "架构审查" / "模块设计" | | performance-analyst | 复杂�?+ 资源 + 并发 | "性能审查" / "瓶颈" | | maintainability-reviewer | 命名 + 复杂�?+ 债务 | "可维护�? / "技术债务" | | documentation-checker | API 文档 + 注释 | "文档检�? / "注释" |

代理职责矩阵（v10.1 新增�?避免重复审查，各代理独占检查项目：

分层过滤（v10.1 改进）：

• 先快速扫描安�?critical 问题
• 若发�?�?立即中断并通知用户，不必等其他代理完成
• 若无 �?继续完整审查流程

详细代理定义：read D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\agents\*.yaml

语言专属审查（v10.3 新增�?审查代码时，系统会根据文件扩展名自动选择语言专属 reviewer�?| 扩展�?| 专属 Reviewer | 审查重点 |

|--------|---------------|----------| | .py | python-reviewer | PEP 8、类型注解、Pythonic 惯用法、安�?| | .ts/.tsx/.js/.jsx | typescript-reviewer | 类型安全、React 最佳实践、异步处�?| | .go | go-reviewer | goroutine、channel、错误处�?| | .rs | rust-reviewer | 所有权、生命周期、unsafe |

语言路由规则�?- review-orchestrator.py --auto-select 自动检测文件扩展名

• 语言专属 reviewer 与通用 code-reviewer 并行工作
• 审查报告合并输出，按文件+行号归组

示例�?```bash

审查 Python 代码，自动选择 python-reviewer + code-reviewer

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\review-orchestrator.py
--files "src/main.py"
--auto-select

## 🔍 自动代码审查集成（v11.2 新增�?> 借鉴 Anthropic 官方 Code Review Plugin 设计，编码完成后自动触发多代理并行审查�?### 集成架构

coding-framework（编码） �? ├─ 步骤1-5: 编码 + 验证 + 自审 �? └─ 步骤6: 自动调用 code-review skill �? ├─ trivial/small �?跳过（🦆自审已覆盖�? ├─ medium �?快速审查（1代理，Bug Hunter视角�? ├─ large �?标准审查�?代理并行：Bug + Security + Maintainability�? └─ 关键模块 �?深度审查�?代理并行 + History + Spec Compliance�? �? ├─ 发现 high/critical �?修复 �?重新审查 └─ 无高置信度问�?�?输出代码

### �?code-review skill 的关�?| 场景 | 触发方式 | 审查深度 |
|------|---------|---------|
| 写完代码后自动审�?| coding-framework 模式1步骤6自动触发 | 按复杂度分层 |
| 用户主动要求审查 | 用户�?审查代码" �?直接调用 code-review skill | 用户指定或默认标�?|
| 完整开发流程中的审�?| coding-framework 模式5审查阶段自动触发 | 按任务复杂度 |
| DAG 任务中的审查 | DAG review 阶段自动触发 | 按任务复杂度 |

### 调用方式

自动触发（无需用户干预�?代码编写完成 �?验证通过 �?自动 read D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\code-review\SKILL.md �?按流程执�?

手动触发

用户�?审查这段代码" �?直接 read D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\code-review\SKILL.md �?按流程执�?

跳过审查

用户�?不需要审�? / --skip-review �?跳过步骤6

### 审查深度选择逻辑

```python
def select_review_depth(task_complexity, is_critical_module):
    if task_complexity in ('trivial', 'small'):
        return None  # 跳过，🦆自审已覆盖
    elif task_complexity == 'medium':
        return 'quick'  # 快速审查，1代理，~30�?    elif task_complexity == 'large':
        if is_critical_module:
            return 'deep'  # 深度审查�?代理�?-5分钟
        else:
            return 'standard'  # 标准审查�?代理�?-2分钟

关键模块识别

以下情况视为"关键模块"，自动升级为深度审查�?- 涉及认证/授权/加密

• 涉及数据库操作（CRUD核心逻辑�?- 涉及外部API调用
• 涉及并发/多线�?- 修改共享模块（utils、config、types�?- 安全敏感（处理用户输入、文件操作）

迭代循环

3 种模式：

自适应模式度量标准（v10.1 新增�?强制要求：使�?adaptive 模式时，必须设置至少一个可度量指标�?- 响应时间（p50/p95/p99�?- 内存峰�?- 代码行数减少比例

• 测试通过�?- 自定义指标（通过 regex 提取�?度量方式�?bash python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\loop-controller.py init \ --name "性能优化" \ --mode adaptive \ --metric "response_time_p95" \ --threshold "0.1" # 改进幅度 < 10% 时停�?

回退规则：若用户未提供可度量指标，自动回退�?max 模式并提示�?### 完成条件类型

LLM 完成条件规范（v10.1 新增）：

• 必须基于封闭性问题（�?代码是否通过所有测试？"�?- 返回格式：{"complete": true/false, "reason": "..."}
• 禁止开放式问题（如"代码是否足够好？"�?控制器：python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\loop-controller.py init --name "task" --mode max --max 10

反事实解释修复法（v10.6 新增�?触发条件：同一错误连续修复失败 2 次�?强制流程�?1. 停止自动修复

1. 输出自然语言解释�? ``` 我认为之前的修复无效是因为：
   • �?1 次修复尝试：[描述] - 失败原因：[分析]
   • �?2 次修复尝试：[描述] - 失败原因：[分析]
   • 根本原因可能是：[推断]

2. 基于该解释生成新的修复方�?4. 验证新方�?目的：避免盲目试错，强制模型理解错误根因后再修复�?示例�?``` 错误：IndexError: list index out of range

�?1 次尝试：添加边界检�?if i < len(lst) 失败原因：检查位置错误，在访问后才检�?�?2 次尝试：在访问前添加 try-except 失败原因：异常被吞掉，未处理根本问题

根本原因：列表为空时不应进入循环，需检查列表是否为�?```

De-Sloppify 清理轮次（v10.3 新增�?LLM 编码常产�?冗余代码"（测试语言特性、过度防御、console.log 等）。De-Sloppify 模式在实现轮次之间插入清理轮次，保持代码简洁�?执行顺序（interval=2 为例）：

iter 1: 实现功能
iter 2: 实现功能
iter 3: 清理轮次（de-sloppify�?iter 4: 实现功能
iter 5: 实现功能
iter 6: 清理轮次
...

使用方法�?```bash

启用 De-Sloppify

python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2.openclaw\workspace\skills\coding-framework\scripts\loop-controller.py init
--name "功能开�?
--mode max --max 9
--sloppify
--sloppify-interval 2

**清理轮次聚焦**�?- 删除类型系统已保证的冗余运行时检�?- 删除过度防御性的错误处理
- 删除 console.log / 注释掉的代码
- 删除未使用的导入和变�?- 简化冗余的条件判断

**check 命令输出**�?```json
{
  "action": "check",
  "should_continue": true,
  "iteration": 2,
  "is_sloppify_round": true,
  "sloppify_focus": [
    "删除未使用的导入和变�?,
    "删除 console.log / 注释掉的代码",
    "..."
  ]
}

审查编排

多代理并行审查使用编排脚本：

# 基本用法
python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\review-orchestrator.py \
  --files "src/main.py" \
  --agents "code-reviewer,security-auditor"

# 自动选择代理 + JSON 输出（v10.1�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\review-orchestrator.py \
  --files "src/main.py" \
  --auto-select \
  --output json

# 分层过滤：先扫描安全 critical（v10.1�?python D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\review-orchestrator.py \
  --files "src/" \
  --fast-fail  # 发现 critical 立即中断

输出格式（v10.1 改进）：

• 默认：人类可读的 Markdown 报告
• --output json：结构化 JSON，便于自动化集成

Hook 系统

事件类型�?| 事件 | 触发时机 | |------|----------| | PreExec | exec 命令执行�?| | PostExec | exec 命令执行�?| | Stop | 会话结束前（迭代循环用） |

Hook 脚本位于 hooks/ 目录，从 stdin 读取 JSON 事件数据，输�?JSON 决策�?## 渐进式披�?核心指令�?SKILL.md（本文件），详细参考按需加载�?- Hook 系统详情 �?D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\references\hook-system.md

• 代理系统详情 �?D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\references\agent-system.md
• 迭代模式详情 �?D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\references\iteration-patterns.md
• 安全模式详情 �?D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\references\security-patterns-detail.md
• 工作流示�?�?D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\references\workflow-examples.md
• 外部代理委派 �?D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\references\external-agents.md（Codex/Claude Code/Git Worktree 并行�?## 文件结构

coding-framework/
├── SKILL.md                          # 本文件（编排器）
├── .coding-framework.yml             # 配置文件（v10.1 新增�?├── CONTRIBUTING.md                   # 扩展指南（v10.1 新增�?├── agents/                           # 8 个子代理定义（v10.9 新增 explore�?�?  ├── code-reviewer.yaml
�?  ├── security-auditor.yaml
�?  ├── test-engineer.yaml
�?  ├── architecture-critic.yaml
�?  ├── performance-analyst.yaml
�?  ├── maintainability-reviewer.yaml
�?  ├── documentation-checker.yaml
�?  └── explore.yaml                  # 侦察代理（v10.9 新增�?├── hooks/                            # 3 个钩子脚�?�?  ├── pre-exec-check.sh
�?  ├── post-exec-log.sh
�?  └── stop-iteration.sh
├── rules/                            # 4 个规则文�?�?  ├── security-rules.md
�?  ├── security-patterns.md
�?  ├── coding-standards.md
�?  └── review-checklist.md
├── scripts/                          # 9 个工具脚�?�?  ├── loop-controller.py
�?  ├── review-orchestrator.py
�?  ├── check-environment.py          # 环境检查（v10.2 新增�?�?  ├── static_analysis.py            # 静态分析（v10.7 新增�?�?  ├── layered_validate.py           # 分层验证栈（v10.7 新增�?�?  ├── tdd_runner.py                 # TDD 流程（v10.7 新增�?�?  ├── run_with_context.py           # 异常上下文注入（v10.7 新增�?�?  ├── benchmark_runner.py           # 性能基准对比（v10.8 新增�?�?  ├── analyze_impact.py             # 依赖影响分析（v10.8 新增�?�?  └── worktree-manager.py           # Git Worktree 管理（v11.0 新增�?├── plans/                            # Plan Mode 计划文件（v10.9 新增�?�?  └── README.md
└── references/                       # 6 个参考文�?    ├── hook-system.md
    ├── agent-system.md
    ├── iteration-patterns.md
    ├── security-patterns-detail.md
    ├── workflow-examples.md
    ├── external-agents.md
    └── worktree-guide.md             # Git Worktree 使用指南（v11.0 新增�?```

## 配置（v10.1 新增�?通过 `.coding-framework.yml` 自定义行为：

```yaml
# 安全规则
security:
  enabled: true
  fast_fail: true  # 发现 critical 立即中断

# 代理配置
agents:
  default_model: sonnet
  confidence_thresholds:
    critical: 50
    high: 70
    medium: 80
    low: 90

# 迭代循环
iteration:
  default_mode: max
  heartbeat_timeout: 300  # �?
# 日志
logging:
  level: info  # debug/info/warn/error
  format: jsonl
  path: .coding-framework/logs/

扩展机制（v10.1 新增�?新增代理�?1. �?D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\agents\ 下创�?your-agent.yaml

1. �?.coding-framework.yml 中注�?3. 详见 CONTRIBUTING.md

新增安全模式�?1. �?rules/security-patterns.md 中添加模式定�?2. �?rules/security-rules.md 中添加匹配规�?3. pre-exec-check.sh 自动加载

新增迭代模式�?1. �?D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\scripts\loop-controller.py 中添加模式处理逻辑 2. 更新 D:\Users\yindb2\AppData\Roaming\mx\openclaw-home\yindb2\.openclaw\workspace\skills\coding-framework\references\iteration-patterns.md

文档加载决策表（v10.2 新增�?根