auto-test-code

Files (18)

• CHANGELOG.md
• README.md
• SKILL.md
• config.yaml
• A_ROUND_REVIEW_TEMPLATE.md · references/
• BOUNDARY_CHECKLIST.md · references/
• CODE_SMELLS.md · references/
• CRITICAL_THINKING_FOR_CODE.md · references/
• DESIGN_ANTI_PATTERNS.md · references/
• SECURITY_PATTERNS.md · references/
• SECURITY_TAXONOMY.md · references/
• create_session.py · scripts/
• verify_session.py · scripts/
• B_ROUND_CODE_QUALITY_TEMPLATE.md · templates/
• CODE_REVIEW_TEMPLATE.md · templates/
• SESSION_TEST_PLAN_TEMPLATE.md · templates/
• SESSION_TEST_REPORT_TEMPLATE.md · templates/
• SESSION_TEST_RUN_TEMPLATE.md · templates/

SKILL.md (first lines)

# auto-test-code（批判性思维驱动的代码自审查技能）

## 目标

当用户明确要求"测试代码"、"运行代码审查"或"进行代码自检"时使用。通过多轮 A 轮批判性代码审查 + B 轮代码质量原则检查，系统化发现、记录、修复程序代码中的问题，并将计划/过程/结果统一沉淀到目标代码根目录的 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/` 隔离工作区。⚠️ 不适用：用户只是想优化功能（应直接修改）、只是询问代码问题（应直接回答）、没有明确"测试代码"意图。

## 流程

### 输入

输入为待审查的代码项目根目录；可选输入包括用户指定的 A 轮次数、运行 ID、测试/审查参数、配置文件和排除目录。必须覆盖核心源代码、配置/构建脚本及测试代码，并排除 `tmp/`、依赖和缓存目录；触发与不适用边界以本 Skill 的 `## 目标` 为准。

### 执行步骤

#### 工作流程

##### 隔离工作区硬规则

- 每次 skill 执行开始时，必须先在目标项目根目录创建当次专用工作区：`.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/`。
- 所有由 skill 生成的计划、报告、日志、辅助脚本与中间产物，**只能**写入当前 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/` 工作区内。
- 运行可能产生缓存或临时文件的命令时，优先将工作目录、`TMPDIR`、`XDG_CACHE_HOME`、`PYTHONPYCACHEPREFIX` 等重定向到当前 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/` 工作区。
- 除了用户明确要求的源码修复外，不得把 skill 相关文件写到 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/` 之外的位置，以免污染源软件项目。

##### 概览

```
用户输入（目标代码路径）
  ↓
[A轮 × N]：静态分析 → 动态推理 → 安全分类审查 → 计划 → 优化 → 轻量测试
  ↓
B轮：代码质量原则检查 → 针对性优化 → 轻量验证
  ↓
完成（文档齐全 + 问题闭环）
```

##### A 轮代码审查（可重复 N 次）

###### A.1 初始化会话（生成测试 ID + 目录）

目标：创建本轮的 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/` 会话骨架（计划/过程/结果都在同一目录）。

推荐使用确定性脚本：

```bash
# 在目标代码根目录内执行（选择你实际的安装路径）
RUN_ID=YYYY-MM-DD-HH-MM
python3 ~/.codex/skills/auto-test-code/scripts/create_session.py --code-root . --run-id "$RUN_ID" --kind a --id vYYYYMMDDHHMM
# 或
RUN_ID=YYYY-MM-DD-HH-MM
python3 ~/.claude/skills/auto-test-code/scripts/create_session.py --code-root . --run-id "$RUN_ID" --kind a --id vYYYYMMDDHHMM
```

最低要求：
- `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/` 存在
- `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/vYYYYMMDDHHMM/REVIEW.md`、`TEST_PLAN.md`、`TEST_RUN.md`、`TEST_REPORT.md` 和 `_artifacts/` 存在

###### A.2 批判性分析与计划生成（写入 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/` 会话目录）

目标：使用**批判性思维**发现代码中的系统性问题，写成可执行计划，按 P0/P1/P2 排序。

输出：`.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/vYYYYMMDDHHMM/REVIEW.md`

⚠️ **批判性思维是核心要求**：
- **必须使用「刁钻角度」思考**（详见 `references/CRITICAL_THINKING_FOR_CODE.md`）
- **必须发现至少 3 个系统性问题**（算法设计/边界条件/并发安全/内存安全/安全漏洞/设计质量）
- **禁止列出"不痛不痒"的表面问题**（如"缺少注释"等 P2 级别问题不应占多数）

**质量要求**（强制）：
- 每轮至少发现 10 个问题（P0 + P1 + P2 总和）
- 鼓励达到 15-20 个问题
- **P0 + P1 占比必须 ≥ 60%**
- **系统性问题 ≥ 3 个**（算法/边界/并发/内存/安全/架构/设计）

**核心要求**：
- **独立评估原则**（强制）：
  - 每轮 A 轮必须基于目标代码的**当前工作状态**独立分析
  - **不查看**历史 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/` 工作区中的审查文件
  - 每轮都是一次完整的、无偏见的系统性审查
- **审查范围**（强制）：
  - 必须审查：核心源代码文件（以 `config.yaml:a_round_check.independent_review.scan_patterns` 为准）
  - 必须审查：配置文件、构建脚本、测试代码
- 排除范围：`tmp/` 等 skill 产物目录，以及 `node_modules/`、`venv/`、`__pycache__/` 等依赖/缓存目录；目标项目的测试代码仍属于必须审查范围
- **全维度覆盖**（强制）：每轮必须覆盖所有审查维度（以 `config.yaml:a_round_check.dimensions` 为准）；不得以“本轮不聚焦”为由跳过任何维度
- **深挖维度**（可选）：可在全覆盖基础上额外指定 1-2 个**深挖维度**，对该维度使用刁钻角度做更细致分析；多轮时建议轮换深挖点
- **刁钻角度**：在深挖维度上必须使用至少一个刁钻角度（空输入/超大输入/恶意输入/竞态条件/资源耗尽/权限绕过/供应链污染）
- **优先级依据**：P0/P1/P2 必须有明确的判定标准
  - P0: 崩溃风险、可利用安全漏洞、未授权访问、敏感信息泄露、数据损坏、死锁/活锁、内存泄漏
  - P1: 性能问题、边界条件缺陷、逻辑错误、资源泄漏、需要前置条件或组合利用的安全风险
  - P2: 代码风格、可读性、冗余代码
- **可追溯性**：每个问题必须包含位置、现象、影响、修复建议、验证方法

**批判性思维框架**（必读）：
- `references/CRITICAL_THINKING_FOR_CODE.md` ⚠️ **核心文档，必须使用**
  - 框架 1: 静态分析视角（算法设计/数据结构/代码复杂度/设计质量）
  - 框架 2: 动态推理视角（边界条件/异常处理/资源管理）
  - 框架 3: 问题质量标准（黄金公式 + 质量检查清单）
  - 框架 4: 设计质量视角（架构/扩展性/API/状态/建模/耦合/模式）
  - 框架 5: 安全漏洞分类视角（CWE/OWASP/STRIDE/七大王国/CVSS）
- `references/A_ROUND_REVIEW_TEMPLATE.md` ⚠️ 代码审查计划模板
- `references/CODE_SMELLS.md` 代码异味识别指南
- `references/SECURITY_PATTERNS.md` 安全漏洞模式库
- `references/SECURITY_TAXONOMY.md` 安全漏洞分类审查体系（必须用于安全维度）
- `references/DESIGN_ANTI_PATTERNS.md` 设计反模式识别指南

###### A.3 执行优化与轻量测试（写入 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/`）

目标：按计划逐项修复，并用轻量测试验证。

输出：
- 过程：`.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/vYYYYMMDDHHMM/TEST_RUN.md`
- 结果：`.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/vYYYYMMDDHHMM/TEST_REPORT.md`

轻量测试原则：
- 只验证"核心路径"与"本轮变更点"
- 每条结论必须有可复现证据（命令输出、日志、对比结果）
- 中间产物放入 `.bensz-api/task-{yyyymmdd-hhmm}-{简短描述}/auto-test-code/{yyyy-mm-dd-hh-mm}/output/tests/vYYYYMMDDHHMM/_artifacts/`

可选增强：

From huangwb8/skills, MIT.

More from huangwb8/skills