@wwkit/harness 1.0.21 → 1.0.22

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wwkit/harness",
-  "version": "1.0.21",
+  "version": "1.0.22",
   "author": "bluesliu <langcai163@163.com>",
   "description": "WebWork abilities for opencode",
   "type": "module",
@@ -44,7 +44,7 @@
     "ajv": "^8.17.0",
     "cheerio": "^1.0.0",
     "json5": "^2.2.3",
-    "@wwkit/shared": "1.0.16"
+    "@wwkit/shared": "1.0.17"
   },
   "devDependencies": {
     "jest": "^29.7.0"

package/readme/development.md

@@ -17,7 +17,7 @@ wwkit/
 
 ```
 plugin.js                 # 包入口（"main"），仅把 skills/ 注册进 config.skills.paths
-agents/*.md               # 主代理（lint / scrum / fastcode），frontmatter 含权限块；extract / revise / query / pytest 现为纯 skill（pytest 合并原 pyut+pyit）；旧 work/work-explore/work-general、work-* skill、todo agent、todo-* skill 均已删除
+agents/*.md               # 主代理（scrum / fastcode），frontmatter 含权限块；extract / revise / query / pytest / lint 现为纯 skill（pytest 合并原 pyut+pyit；lint 合并原 lint agent + 7 个 lint-* skill）；旧 work/work-explore/work-general、work-* skill、todo agent、todo-* skill 均已删除
 skills/<name>/SKILL.md    # 技能定义
 skills/<name>/references/ # 工作流：*.md（LLM 指令）、*.js（ESM 辅助脚本）、*.json5（schema）
 commands/*.md             # opencode 命令（/tl 翻译）

package/{agents/lint.md → skills/lint/SKILL.md}

@@ -1,20 +1,56 @@
 ---
+name: lint
 description: |
-  通用多语言语法检查指挥官。协调语言探测→适用性检查→环境检查→配置生成→规则分析→自动修复→AI修复的完整流程。
+  自包含多语言语法检查 skill：协调语言探测→适用性检查→环境检查→配置生成→规则分析→自动修复→AI修复的完整流程。
   二元制评分：0 违规=100（达标），1+ 违规=0（不达标）。v1 支持 JS/TS 和 Python。
-  触发词：lint、语法检查、代码规范、eslint、ruff。
-mode: subagent
+  子工作流（language-detect/suitability-check/env-ensure/config-setup/rules-analyze/tool-fix/ai-fix）位于 references/ 下，由主流程用 read 加载并按其指令执行，不再调用独立 skill。
+  调用方直接传原始任务消息，skill 自解析自包含。内部用 todowrite 管理 8 步。触发词：lint、语法检查、代码规范、eslint、ruff。
+license: MIT
+metadata:
+  workflow: sequential
 ---
 
-你是通用多语言语法检查指挥官（lint）。你负责协调一套完整的 lint 检查-修复-复检流程，确保目标代码的语法规范达到 100% 通过率。
+# lint 技能
+
+## 核心约束（最高优先级）
+
+- **MUST**：收到任务消息后，先 todowrite 落单 8 步，再逐步执行。
+- **MUST**：每步完成立即 todowrite 勾单。
+- **MUST**：子工作流通过 `read` 加载 `references/xxx.md` 并按其指令执行，**不再调用独立 skill**（原 lint-* 子 skill 已合并入 references/）。
+- **禁止**：混合语言（v1 按主语言处理，不支持混合）。
+- **禁止**：修改 lint 配置文件（配置生成由 references/config-setup.md 负责）。
+- **禁止**：使用 WebFetch 或任何网络请求。
+
+## 第一步硬指令（自检）
+
+解析入参前，强制自检：
+> 我是否已用 todowrite 落单 8 步？
+> - 未落单 → 立即 todowrite 创建清单。
+> - 已落单 → 继续。
+
+## 输入参数（自包含）
+
+入参为调用方传入的**原始任务消息**，可能是以下任一形态：
+
+- **JSON 对象**：`{root_dir, target_dir}`，直接取字段值。
+- **key=value**：`root_dir=/path/to/project, target_dir=/path/to/project/src`，按 `,` 和 `=` 拆分为字段。
+- **纯文本 prose**：从文本中出现的路径推断 root_dir/target_dir。
+- **命令风格**：`lint /path/to/project` 或 `lint /path/to/project /path/to/project/src`，第一段为 root_dir，第二段（可选）为 target_dir。
+
+字段清单：
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| root_dir | string | 否 | 工程根目录，默认当前工作目录 |
+| target_dir | string | 否 | 检查目标目录，默认 root_dir 全量 |
 
 ## 你的职责
 
 1. 接收用户输入的工程根目录和检查目标目录
-2. 调用 lint-language-detect 探测主语言
-3. 调用 lint-suitability-check 筛选可 lint 文件
-4. 调用 lint-env-ensure 检查并安装 linter 工具
-5. 调用 lint-config-setup 生成或补全 lint 配置文件
+2. 读取 references/language-detect.md 探测主语言
+3. 读取 references/suitability-check.md 筛选可 lint 文件
+4. 读取 references/env-ensure.md 检查并安装 linter 工具
+5. 读取 references/config-setup.md 生成或补全 lint 配置文件
 6. 协调规则分析 → 工具修复 → AI 修复的外层 loop
 7. 管理 loop 次数和退出条件（轮尾独立验证）
 8. 输出最终检查报告并写入 `{report_dir}/lint_report-{HHMMSS}.md`
@@ -23,7 +59,7 @@ mode: subagent
 
 - target_score: **100**（二元制：0 违规=100，1+ 违规=0）
 - outer_max: **3**（外层 loop 最大轮次）
-- inner_max: **3**（lint-ai-fix 内部 loop 最大轮次，skill 内部管理）
+- inner_max: **3**（references/ai-fix.md 内部 loop 最大轮次，自管理）
 
 ## TodoWrite 任务清单纪律（强制）
 
@@ -73,7 +109,7 @@ Step 1 入参校验通过后，立即用 `todowrite` 一次性创建以下 8 项
 
 #### 产出
 
-Step 1 结束后，确定以下变量，传递给后续所有 skill：
+Step 1 结束后，确定以下变量，传递给后续所有子工作流：
 - `root_dir`：工程根目录
 - `target_dir`：检查目标目录
 - `report_dir`：报告输出目录，格式为 `{root_dir}/.webwork/harness/lint/{YYYY-MM-DD}/`
@@ -89,11 +125,11 @@ Step 1 结束后，确定以下变量，传递给后续所有 skill：
 
 ### Step 2：语言探测
 
-调用 **lint-language-detect** 技能，传入参数：
+读取 `references/language-detect.md` 并按其指令执行，传入参数：
 - root_dir: 工程根目录路径
 
 **产出**：
-- `primary_language`：主语言（`jsts` 或 `python`），传递给后续所有 skill
+- `primary_language`：主语言（`jsts` 或 `python`），传递给后续所有子工作流
 
 **退出条件**：
 - 检测到主语言 → 继续 Step 3
@@ -101,7 +137,7 @@ Step 1 结束后，确定以下变量，传递给后续所有 skill：
 
 ### Step 3：适用性检查
 
-调用 **lint-suitability-check** 技能，传入参数：
+读取 `references/suitability-check.md` 并按其指令执行，传入参数：
 - root_dir: 工程根目录路径
 - target_dir: 检查目标目录路径
 - primary_language: 从 Step 2 获得的主语言
@@ -116,7 +152,7 @@ Step 1 结束后，确定以下变量，传递给后续所有 skill：
 
 ### Step 4：环境检查
 
-调用 **lint-env-ensure** 技能，传入参数：
+读取 `references/env-ensure.md` 并按其指令执行，传入参数：
 - root_dir: 工程根目录路径
 - primary_language: 主语言
 
@@ -134,7 +170,7 @@ Step 1 结束后，确定以下变量，传递给后续所有 skill：
 
 ### Step 5：配置生成
 
-调用 **lint-config-setup** 技能，传入参数：
+读取 `references/config-setup.md` 并按其指令执行，传入参数：
 - root_dir: 工程根目录路径
 - primary_language: 主语言
 
@@ -152,7 +188,7 @@ Step 1 结束后，确定以下变量，传递给后续所有 skill：
 
 ### Step 6：规则分析（外层 loop 开始）
 
-调用 **lint-rules-analyze** 技能，传入参数：
+读取 `references/rules-analyze.md` 并按其指令执行，传入参数：
 - target_dir: 检查目标目录路径
 - root_dir: 工程根目录路径
 - primary_language: 主语言
@@ -166,7 +202,7 @@ Step 1 结束后，确定以下变量，传递给后续所有 skill：
 
 #### 轮尾调用（所有 Round，独立验证）
 
-- 在 tool-fix + ai-fix 完成后，agent **独立调用** lint-rules-analyze 获取 `final_count`
+- 在 tool-fix + ai-fix 完成后，主流程**独立调用** references/rules-analyze.md 获取 `final_count`
 - 此调用是权威验证，不信任 tool-fix/ai-fix 的内部 linter 结果
 
 **退出条件**（仅在轮尾调用时检查）：
@@ -180,13 +216,13 @@ Step 1 结束后，确定以下变量，传递给后续所有 skill：
 
 ### Step 7：工具修复
 
-调用 **lint-tool-fix** 技能，传入参数：
+读取 `references/tool-fix.md` 并按其指令执行，传入参数：
 - target_dir: 检查目标目录路径
 - root_dir: 工程根目录路径
 - primary_language: 主语言
 - config_file_path: 配置文件路径
 
-skill 内部执行 `--fix`，然后复跑 linter 获取 `remaining_violations`。
+子工作流内部执行 `--fix`，然后复跑 linter 获取 `remaining_violations`。
 
 **产出**：
 - `tool_fixed_count`：自动修复数
@@ -198,14 +234,14 @@ skill 内部执行 `--fix`，然后复跑 linter 获取 `remaining_violations`
 
 ### Step 8：AI 修复（内部 loop，skill 自管理）
 
-调用 **lint-ai-fix** 技能，传入参数：
+读取 `references/ai-fix.md` 并按其指令执行，传入参数：
 - remaining_violations: 从 Step 7 获得的剩余违规列表
 - target_dir: 检查目标目录路径
 - root_dir: 工程根目录路径
 - primary_language: 主语言
 - config_file_path: 配置文件路径
 
-skill 内部管理 fix→语法验证→linter 复检 的 loop（max 3），agent 不关心内部 loop 状态。
+子工作流内部管理 fix→语法验证→linter 复检 的 loop（max 3），主流程不关心内部 loop 状态。
 
 **产出**：
 - `ai_fixed_count`：AI 修复数
@@ -213,7 +249,7 @@ skill 内部管理 fix→语法验证→linter 复检 的 loop（max 3），agen
 - `manual_items`：人工处理项列表
 
 **退出条件**：
-- 输出后 → 标记第 7 项 `completed`，标记第 8 项 `in_progress`，回到 Step 6 轮尾评分（agent 独立调用 lint-rules-analyze 做权威验证）
+- 输出后 → 标记第 7 项 `completed`，标记第 8 项 `in_progress`，回到 Step 6 轮尾评分（主流程独立调用 references/rules-analyze.md 做权威验证）
 
 ## Loop 控制状态机
 
@@ -224,7 +260,7 @@ skill 内部管理 fix→语法验证→linter 复检 的 loop（max 3），agen
   round 3: tool-fix → ai-fix → rules-analyze(轮尾,独立验证)
 
   注意：round 1 基线检查 violation_count=0 时直接达标退出，不进入 loop。
-  注意：轮尾 rules-analyze 是 agent 独立调用，不信任 tool-fix/ai-fix 的内部 linter 结果。
+  注意：轮尾 rules-analyze 是主流程独立调用，不信任 tool-fix/ai-fix 的内部 linter 结果。
   注意：round 2+ 的 round_start_count 由上一轮轮尾退出条件设置（round_start_count = final_count），
         无需单独的轮首 rules-analyze 调用。
 
@@ -241,7 +277,7 @@ skill 内部管理 fix→语法验证→linter 复检 的 loop（max 3），agen
 
 内层 loop (lint-ai-fix 内部, max 3):
   fix → 语法验证 → linter 复检 → fix → ...
-  skill 自管理，agent 只接收最终输出
+子工作流自管理，主流程只接收最终输出
 ```
 
 ## 状态跟踪
@@ -361,8 +397,37 @@ skill 内部管理 fix→语法验证→linter 复检 的 loop（max 3），agen
 
 1. v1 只处理 JS/TS（含 Vue）和 Python，按主语言处理，不支持混合语言
 2. 二元制评分：0 违规=100（达标），1+ 违规=0（不达标）
-3. 轮尾必须独立调用 lint-rules-analyze 做权威验证（方案 B）
-4. lint-ai-fix 的内部 loop 由 skill 自管理，agent 只接收最终输出
+3. 轮尾必须独立调用 references/rules-analyze.md 做权威验证（方案 B）
+4. references/ai-fix.md 的内部 loop 自管理，主流程只接收最终输出
 5. 修复对象是源码自身，必须有语法验证 + git 回滚保护
-6. 不修改 lint 配置文件（配置生成由 lint-config-setup 负责）
+6. 不修改 lint 配置文件（配置生成由 references/config-setup.md 负责）
 7. 遵循 AGENTS.md：ESM 脚本、CommonJS e2e 测试、无网络请求
+
+## references/ 目录结构
+
+子工作流与资源文件均位于 `references/` 下，由主流程用 `read` 加载：
+
+```
+references/
+├── language-detect.md       # Step 2 语言探测子工作流
+├── detect-language.js       # 语言探测 ESM 脚本（language-detect.md 引用）
+├── suitability-check.md     # Step 3 适用性检查子工作流
+├── env-ensure.md            # Step 4 环境检查子工作流
+├── config.md                # 环境检查配置清单（env-ensure.md 引用）
+├── config-setup.md          # Step 5 配置生成子工作流
+├── languages/
+│   ├── js.md                # JS/TS ESLint 规则清单（config-setup.md 引用）
+│   └── py.md                # Python Ruff 规则清单（config-setup.md 引用）
+├── rules-analyze.md         # Step 6 规则分析子工作流
+├── tool-fix.md              # Step 7 工具修复子工作流
+└── ai-fix.md                # Step 8 AI 修复子工作流
+```
+
+子工作流 .md 之间互不直接调用，均由主流程在对应 Step 用 `read` 加载后按其指令执行。子工作流内部对其他子工作流的引用以 `references/xxx.md` 路径或 Step 编号形式标注。
+
+## 工具使用约束
+
+- 写文件一律用 `write` 工具；读文件用 `read` 工具。
+- 加载子工作流用 `read` 读取 `references/xxx.md`，按其指令执行（**不再通过 skill tool 调用独立子 skill**）。
+- 需要中间数据时，用 `write` 工具写入临时文件，再以 stdin 重定向传给 node。
+- 禁止使用未授权的 `cp`/`rm`/`mv` 等命令；需要复制、移动或删除临时文件时，一律用允许的 `node -e` 的 fs 模块完成。

package/skills/{lint-ai-fix/SKILL.md → lint/references/ai-fix.md}

@@ -1,10 +1,7 @@
----
-name: lint-ai-fix
-description: |
-  对 linter 无法自动修复的违规进行 AI 语义修复。内部管理 fix→验证→复检 的 loop（max 3），
-  每次修改后做语法验证，失败则 git checkout 回滚并记人工处理项。agent 只接收最终输出。
-  适用：lint agent 的 AI 修复阶段，处理 lint-tool-fix 的剩余违规。
-  不适用：linter --fix 可修复的违规（使用 lint-tool-fix）、规则检查（使用 lint-rules-analyze）。
+> **原 skill**: `lint-ai-fix`（已合并入 lint）
+> **适用**: lint agent 的 AI 修复阶段，处理 Step 7（references/tool-fix.md）的剩余违规。
+> **不适用**: linter --fix 可修复的违规（Step 7 / references/tool-fix.md）、规则检查（Step 6 / references/rules-analyze.md）。
+
 ---
 
 # Lint AI 语义修复
@@ -17,7 +14,7 @@ description: |
 
 | 参数 | 必填 | 类型 | 说明 |
 |------|------|------|------|
-| remaining_violations | 是 | array | lint-tool-fix 输出的剩余违规列表 |
+| remaining_violations | 是 | array | Step 7（references/tool-fix.md）输出的剩余违规列表 |
 | target_dir | 是 | string | 检查目标目录路径 |
 | root_dir | 是 | string | 工程根目录路径 |
 | primary_language | 是 | string | 主语言（`jsts` 或 `python`） |
@@ -77,7 +74,7 @@ inner_round 3: 逐条修复 → 语法验证 → linter 复检
 
 ## 阶段三：linter 复检
 
-对所有修改的文件重新执行 linter 检查（同 lint-rules-analyze 命令），获取当前违规数。
+对所有修改的文件重新执行 linter 检查（同 references/rules-analyze.md 命令），获取当前违规数。
 
 ## 阶段四：退出判断
 
@@ -138,4 +135,4 @@ inner_round 3: 逐条修复 → 语法验证 → linter 复检
 2. 不要修改非违规文件的代码
 3. 不要跳过语法验证
 4. 不要在语法验证失败时不回滚
-5. 不要执行网络请求
+5. 不要执行网络请求

package/skills/{lint-config-setup/SKILL.md → lint/references/config-setup.md}

@@ -1,10 +1,7 @@
----
-name: lint-config-setup
-description: |
-  生成或补全 lint 配置文件。读取语言规则清单，按初始启用规则生成 eslint.config.js 或 ruff.toml。
-  已有配置文件时只追加缺失的启用规则，不覆盖用户自定义规则。
-  适用：lint agent 的配置生成阶段，在规则分析前确保配置文件存在且包含初始规则集。
-  不适用：非 lint 场景的配置生成、手动配置调优。
+> **原 skill**: `lint-config-setup`（已合并入 lint）
+> **适用**: lint agent 的配置生成阶段，在规则分析前确保配置文件存在且包含初始规则集。
+> **不适用**: 非 lint 场景的配置生成、手动配置调优。
+
 ---
 
 # Lint 配置生成
@@ -29,12 +26,12 @@ description: |
 
 ## 阶段一：加载规则清单
 
-读取 `references/languages/{primary_language}.md`，解析规则清单表格：
+读取 `languages/{primary_language}.md`，解析规则清单表格：
 
 | 主语言 | 规则文件 | 配置文件名 |
 |--------|---------|-----------|
-| jsts | `references/languages/js.md` | `eslint.config.js` |
-| python | `references/languages/py.md` | `ruff.toml` |
+| jsts | `languages/js.md` | `eslint.config.js` |
+| python | `languages/py.md` | `ruff.toml` |
 
 提取所有"初始启用"标记为 ✓ 的规则。
 
@@ -103,4 +100,4 @@ select = ["F401", "F811", "F841", "E711"]
 1. 不要覆盖用户已有的自定义规则
 2. 不要修改非配置文件
 3. 不要写入初始未启用的规则
-4. 不要执行网络请求
+4. 不要执行网络请求

package/skills/{lint-env-ensure/SKILL.md → lint/references/env-ensure.md}

@@ -1,10 +1,7 @@
----
-name: lint-env-ensure
-description: |
-  检查 lint 工具可用性，缺失时在项目内自动安装。按主语言检查对应 linter（jsts→eslint，python→ruff），
-  安装失败重试 3 次。加载配置清单供后续 skill 共享。
-  适用：lint agent 的环境检查阶段，在配置生成和规则分析前确保工具可用。
-  不适用：非 lint 场景的环境检查、系统级工具安装。
+> **原 skill**: `lint-env-ensure`（已合并入 lint）
+> **适用**: lint agent 的环境检查阶段，在配置生成和规则分析前确保工具可用。
+> **不适用**: 非 lint 场景的环境检查、系统级工具安装。
+
 ---
 
 # Lint 环境检查
@@ -25,7 +22,7 @@ description: |
 - `linter_name`：linter 名称（`eslint` 或 `ruff`）
 - `linter_version`：linter 版本号
 - `linter_installed`：是否已安装且可用（bool）
-- `config`：从 references/config.md 加载的配置对象
+- `config`：从 config.md 加载的配置对象
 
 ## 阶段一：检查工具可用性
 
@@ -58,7 +55,7 @@ description: |
 
 ## 阶段四：加载配置
 
-读取 `references/config.md`，输出配置对象供后续 skill 使用。
+读取 `config.md`，输出配置对象供后续 skill 使用。
 
 ## 决策
 
@@ -89,4 +86,4 @@ description: |
 1. 不要全局安装工具（`npm install -g`）
 2. 不要跳过安装验证步骤
 3. 不要修改项目配置文件（package.json 等）
-4. 不要使用 webfetch 下载工具，仅通过包管理器（npm/pip/uv）安装
+4. 不要使用 webfetch 下载工具，仅通过包管理器（npm/pip/uv）安装

package/skills/{lint-language-detect/SKILL.md → lint/references/language-detect.md}

@@ -1,10 +1,7 @@
----
-name: lint-language-detect
-description: |
-  探测工程主语言。优先检查 manifest 文件（package.json → jsts，pyproject.toml/setup.py → python），
-  无 manifest 时按源码文件扩展名计数，多者为主语言。JS/TS 视为一种语言。
-  适用：lint agent 的语言探测阶段，在环境检查和配置生成前确定主语言。
-  不适用：非 lint 场景的语言检测、混合语言项目（v1 按主语言处理，不支持混合）。
+> **原 skill**: `lint-language-detect`（已合并入 lint）
+> **适用**: lint agent 的语言探测阶段，在环境检查和配置生成前确定主语言。
+> **不适用**: 非 lint 场景的语言检测、混合语言项目（v1 按主语言处理，不支持混合）。
+
 ---
 
 # 主语言探测
@@ -39,7 +36,7 @@ description: |
 
 ## 阶段二：文件计数检测
 
-无 manifest 时，调用 `references/detect-language.js` 的 `detectLanguage(rootDir)` 函数扫描源码文件：
+无 manifest 时，调用 `detect-language.js` 的 `detectLanguage(rootDir)` 函数扫描源码文件：
 
 1. 递归扫描 `root_dir`（最大深度 10 层）
 2. 排除目录：`node_modules/`、`dist/`、`build/`、`.git/`、`__pycache__/`、`.venv/`、`venv/`、`.webwork/`、`reports/`、`coverage/`
@@ -76,4 +73,4 @@ description: |
 1. 不要返回多个语言（v1 只返回主语言）
 2. 不要扫描 `node_modules/` 等依赖目录
 3. 不要修改任何文件
-4. 不要执行网络请求
+4. 不要执行网络请求

package/skills/{lint-rules-analyze/SKILL.md → lint/references/rules-analyze.md}

@@ -1,10 +1,7 @@
----
-name: lint-rules-analyze
-description: |
-  执行 linter 检查并解析 JSON 输出，产出违规清单。按主语言调用对应 linter（eslint/ruff），
-  解析输出为统一的 violations 结构。二元制评分：0 违规=100，1+违规=0。
-  适用：lint agent 的规则分析阶段，用于基线检查和轮尾独立验证。
-  不适用：修复违规（使用 lint-tool-fix / lint-ai-fix）、非 lint 场景的代码分析。
+> **原 skill**: `lint-rules-analyze`（已合并入 lint）
+> **适用**: lint agent 的规则分析阶段，用于基线检查和轮尾独立验证。
+> **不适用**: 修复违规（Step 7 / references/tool-fix.md、Step 8 / references/ai-fix.md）、非 lint 场景的代码分析。
+
 ---
 
 # Lint 规则分析
@@ -126,4 +123,4 @@ Ruff 输出 JSON 数组，每元素含 `code`、`filename`、`location`：
 1. 不要修复任何违规（只检查）
 2. 不要修改源码文件
 3. 不要省略 warning 级别的违规
-4. 不要执行网络请求
+4. 不要执行网络请求

package/skills/{lint-suitability-check/SKILL.md → lint/references/suitability-check.md}

@@ -1,9 +1,7 @@
----
-name: lint-suitability-check
-description: |
-  扫描目标目录，筛选出可 lint 的源码文件列表。按主语言扩展名过滤，排除依赖/构建/缓存目录。
-  适用：lint agent 的适用性检查阶段，在环境检查前确定可检查的文件范围。
-  不适用：非 lint 场景的文件筛选、语言检测（使用 lint-language-detect）。
+> **原 skill**: `lint-suitability-check`（已合并入 lint）
+> **适用**: lint agent 的适用性检查阶段，在环境检查前确定可检查的文件范围。
+> **不适用**: 非 lint 场景的文件筛选、语言检测（Step 2 / references/language-detect.md）。
+
 ---
 
 # 可 Lint 文件筛选
@@ -81,4 +79,4 @@ description: |
 1. 不要扫描 node_modules 等排除目录
 2. 不要返回非目标语言的文件
 3. 不要修改任何文件
-4. 不要执行网络请求
+4. 不要执行网络请求

package/skills/{lint-tool-fix/SKILL.md → lint/references/tool-fix.md}

@@ -1,10 +1,7 @@
----
-name: lint-tool-fix
-description: |
-  执行 linter 的 --fix 自动修复，然后内部复跑 linter 获取剩余违规清单。
-  只处理 linter 可自动修复的规则，不可修复的规则交由 lint-ai-fix 处理。
-  适用：lint agent 的工具修复阶段，在 AI 修复前先自动修复可修复项。
-  不适用：AI 语义修复（使用 lint-ai-fix）、规则检查（使用 lint-rules-analyze）。
+> **原 skill**: `lint-tool-fix`（已合并入 lint）
+> **适用**: lint agent 的工具修复阶段，在 AI 修复前先自动修复可修复项。
+> **不适用**: AI 语义修复（Step 8 / references/ai-fix.md）、规则检查（Step 6 / references/rules-analyze.md）。
+
 ---
 
 # Lint 工具自动修复
@@ -25,7 +22,7 @@ description: |
 ## 输出
 
 - `tool_fixed_count`：自动修复的违规数
-- `remaining_violations`：修复后剩余的违规列表（结构同 lint-rules-analyze 的 violations）
+- `remaining_violations`：修复后剩余的违规列表（结构同 references/rules-analyze.md 的 violations）
 
 ## 阶段一：执行 --fix
 
@@ -40,7 +37,7 @@ description: |
 
 ## 阶段二：复跑 linter 获取剩余违规
 
-修复后重新执行 linter 检查（同 lint-rules-analyze 的命令），获取剩余违规：
+修复后重新执行 linter 检查（同 references/rules-analyze.md 的命令），获取剩余违规：
 
 | 主语言 | 命令 |
 |--------|------|
@@ -91,4 +88,4 @@ description: |
 1. 不要执行 AI 语义修复（那是 lint-ai-fix 的职责）
 2. 不要修改 linter 配置文件
 3. 不要跳过复跑 linter 步骤
-4. 不要执行网络请求
+4. 不要执行网络请求

package/skills/pytest/SKILL.md

@@ -1,9 +1,10 @@
 ---
 name: pytest
 description: |
-  自包含 Python 测试 skill：合并原 pyut（单元测试）和 pyit（集成测试）。
-  通过 test_type=unit|integration 区分：unit 全 Mock 目标覆盖率 90%，integration 最少 Mock 目标覆盖率 70%。
-  协调适用性评估→环境检查→覆盖率分析→用例创建→测试执行→用例修复的完整流程，内外两层 loop。
+  自包含 Python 测试 skill：合并原 pyut（单元测试）和 pyit（集成测试），并将所有子工作流收入 references/。
+  通过 test_type=unit|integration|sample 区分：unit 全 Mock 目标覆盖率 90%，integration 最少 Mock 目标覆盖率 70%，sample 注入 demo 样例代码。
+  unit/integration 协调适用性评估→环境检查→覆盖率分析→用例创建→测试执行→用例修复的完整流程，内外两层 loop；sample 读取 references/sample.md 注入 demo。
+  子工作流（suitability-check/env-ensure/coverage-analyze/case-create/execute/case-fix/sample）位于 references/ 下，由主流程用 read 加载并按其指令执行，不再调用独立 skill。
   调用方直接传原始任务消息，skill 自解析自包含。内部用 todowrite 管理 7 步。适用于 uv 管理的 Python 项目。
 license: MIT
 metadata:
@@ -16,9 +17,10 @@ metadata:
 
 - **MUST**：收到任务消息后，先 todowrite 落单 7 步，再逐步执行。
 - **MUST**：每步完成立即 todowrite 勾单。
-- **MUST**：test_type 只能是 unit 或 integration，其他值报错退出。
+- **MUST**：test_type 只能是 unit、integration 或 sample，其他值报错退出。
 - **禁止**：混合测试类型（unit 不混合 integration，反之亦然）。
 - **禁止**：修改 conftest.py（除非直接导致失败）。
+- **MUST**：子工作流通过 `read` 加载 `references/xxx.md` 并按其指令执行，**不再调用独立 skill**（原 pytest-* 子 skill 已合并入 references/）。
 
 ## 第一步硬指令（自检）
 
@@ -45,7 +47,9 @@ metadata:
 | 报告标题 | pytest unit 测试质量报告 | pytest integration 测试质量报告 |
 | 退出达标 | score ≥ 90 | score ≥ 70 |
 
-通用配置（两种 test_type 共享）：
+**sample 分支**：test_type=sample 时不走 7 步 loop，Step 1 解析后直接读取 `references/sample.md` 按 demo 注入流程执行（在当前工程 src/ 下创建 pytest-sample 包，写入 7 个 demo 类，含 15 个故意 bug 用于端到端验证），完成后结束。
+
+通用配置（unit/integration 共享）：
 
 - outer_max: **3**（外层 loop 最大轮次）
 - inner_max: **3**（内层 loop 最大轮次）
@@ -64,13 +68,13 @@ metadata:
 
 | 字段 | 类型 | 必填 | 说明 |
 |------|------|------|------|
-| test_type | string | 是 | `unit` 或 `integration`，其他值报错退出 |
+| test_type | string | 是 | `unit`、`integration` 或 `sample`，其他值报错退出 |
 | source | string | 是 | 源码包目录或 .py 文件路径 |
 | test_dir | string | 否 | 测试目录；未指定时按 `tests/{test_type}/{归一化路径}/` 自动推导 |
 
 **必填校验**：若无法解析出 `test_type` 或 `source`，将错误信息输出到 stderr 并结束，**禁止**继续执行。
 
-**test_type 校验**：解析后若 `test_type` 不在 `{unit, integration}` 中，输出 "test_type 只能是 unit 或 integration，得到: {value}" 并结束。
+**test_type 校验**：解析后若 `test_type` 不在 `{unit, integration, sample}` 中，输出 "test_type 只能是 unit、integration 或 sample，得到: {value}" 并结束。
 
 ## 输出
 
@@ -102,8 +106,8 @@ metadata:
 
 | 检查项 | 失败提示 |
 |--------|---------|
-| 为空 | "请提供 test_type（unit 或 integration）" |
-| 非 unit/integration | "test_type 只能是 unit 或 integration，得到: {value}" |
+| 为空 | "请提供 test_type（unit、integration 或 sample）" |
+| 非 unit/integration/sample | "test_type 只能是 unit、integration 或 sample，得到: {value}" |
 
 #### 参数 source 校验（源码路径）
 
@@ -163,11 +167,13 @@ Step 1 结束后，确定以下变量，传递给后续所有 skill：
 
 **退出条件**：参数校验失败 → 直接退出，不进入后续流程。
 
+**sample 分支**：若 `test_type == sample`，Step 1 完成后**直接读取 `references/sample.md`** 并按其指令执行 demo 注入流程（创建 src/pytest-sample/ 包 + 7 个 demo 类 + 语法验证），完成后 todowrite 勾单第 1 步并输出创建报告，**跳过 Step 2~7**，流程结束。
+
 完成后 todowrite 勾单第 1 步。
 
 ### Step 2：模块适用性评估
 
-调用 **pytest-suitability-check** 技能，传入参数：
+读取 `references/suitability-check.md` 并按其指令执行，传入参数：
 
 - target: 源码包目录路径
 - test_type: 当前 test_type
@@ -197,12 +203,12 @@ IT 仅适合有外部依赖的类（Service Class / Integration Point / External
 
 ### Step 3：环境检查
 
-调用 **pytest-env-ensure** 技能：
+读取 `references/env-ensure.md` 并按其指令执行：
 
 - 检查是否为 uv 项目
 - 检查并安装依赖（test_type=unit: pytest, pytest-cov；test_type=integration: pytest, pytest-cov, pytest-timeout）
 - test_type=integration 时：检查 pytest marker 注册（unit, integration）
-- 加载配置清单（references/config.md）
+- 加载配置清单（`references/config.md`）
 
 **分支：test_type == integration 的环境补充检查**（env-ensure 之后执行）
 
@@ -239,7 +245,7 @@ IT 仅适合有外部依赖的类（Service Class / Integration Point / External
 
 #### 覆盖率分析（非首轮或有已有测试时执行）
 
-调用 **pytest-coverage-analyze** 技能，传入参数：
+读取 `references/coverage-analyze.md` 并按其指令执行，传入参数：
 - target: 用户指定的模块路径
 - test_dir: 从 Step 1 确定的测试目录路径
 - report_dir: 从 Step 1 确定的报告输出目录
@@ -270,7 +276,7 @@ IT 仅适合有外部依赖的类（Service Class / Integration Point / External
 
 ### Step 5：用例创建
 
-调用 **pytest-case-create** 技能，传入参数：
+读取 `references/case-create.md` 并按其指令执行，传入参数：
 - uncovered_areas: 从 Step 4 获得的未覆盖区域清单（首轮为 "all"）
 - testable_classes: 从 Step 2 获得的可测试类清单
 - target: 目标模块路径
@@ -289,7 +295,7 @@ IT 仅适合有外部依赖的类（Service Class / Integration Point / External
 
 ### Step 6：测试执行
 
-调用 **pytest-execute** 技能，传入参数：
+读取 `references/execute.md` 并按其指令执行，传入参数：
 - target: 目标模块路径
 - test_dir: 从 Step 1 确定的测试目录路径
 - test_type: 当前 test_type
@@ -304,7 +310,7 @@ IT 仅适合有外部依赖的类（Service Class / Integration Point / External
 
 ### Step 7：用例修复（内层 loop）
 
-调用 **pytest-case-fix** 技能，传入参数：
+读取 `references/case-fix.md` 并按其指令执行，传入参数：
 - failed_tests: 从 Step 6 获得的失败用例清单
 - test_dir: 从 Step 1 确定的测试目录路径
 - report_dir: 从 Step 1 确定的报告输出目录
@@ -513,8 +519,30 @@ integration:
 - 按业务场景组织用例，不按函数
 - 验证端到端数据流完整性
 
+## references/ 目录结构
+
+子工作流与资源文件均位于 `references/` 下，由主流程用 `read` 加载：
+
+```
+references/
+├── suitability-check.md      # Step 2 模块适用性评估子工作流
+├── env-ensure.md             # Step 3 环境检查子工作流
+├── config.md                 # 环境检查配置清单（env-ensure.md 引用）
+├── coverage-analyze.md       # Step 4 覆盖率分析子工作流
+├── scoring-rules.md          # 评分规则（coverage-analyze.md 引用）
+├── case-create.md            # Step 5 用例创建子工作流
+├── test-standards.md         # 测试用例规范（case-create.md 引用）
+├── execute.md                # Step 6 测试执行子工作流
+├── case-fix.md               # Step 7 用例修复子工作流
+├── sample.md                 # test_type=sample 时 demo 注入子工作流
+└── src/pytest-sample/*.py    # demo 样例源码模板（sample.md 引用，7 个文件）
+```
+
+子工作流 .md 之间互不直接调用，均由主流程在对应 Step 用 `read` 加载后按其指令执行。子工作流内部对其他子工作流的引用以 `references/xxx.md` 路径或 Step 编号形式标注。
+
 ## 工具使用约束
 
 - 写文件一律用 `write` 工具；读文件用 `read` 工具。
+- 加载子工作流用 `read` 读取 `references/xxx.md`，按其指令执行（**不再通过 skill tool 调用独立子 skill**）。
 - 需要中间数据时，用 `write` 工具写入临时文件，再以 stdin 重定向传给 node。
 - 禁止使用未授权的 `cp`/`rm`/`mv` 等命令；需要复制、移动或删除临时文件时，一律用允许的 `node -e` 的 fs 模块完成。

package/skills/{pytest-case-create/SKILL.md → pytest/references/case-create.md}

@@ -1,9 +1,7 @@
----
-name: pytest-case-create
-description: |
-  按测试规范创建 pytest 测试用例。根据 test_type 切换 Mock 策略，分析源码识别未覆盖区域，按 AAA/FIRST/边界值规范创建用例。
-  适用：测试代理外层 loop 的用例创建阶段，为未覆盖代码创建测试用例。
-  不适用：修复已有失败用例（使用 pytest-case-fix）、非 pytest 框架的用例创建。
+> **原 skill**: `pytest-case-create`（已合并入 pytest）
+> **适用**: 测试代理外层 loop 的用例创建阶段，为未覆盖代码创建测试用例。
+> **不适用**: 修复已有失败用例（使用 pytest-case-fix）、非 pytest 框架的用例创建。
+
 ---
 
 # 测试用例创建
@@ -23,12 +21,12 @@ description: |
 
 | 参数 | 必填 | 类型 | 说明 |
 |------|------|------|------|
-| uncovered_areas | 是 | list/string | 未覆盖区域清单（来自 pytest-coverage-analyze，首轮为 "all"） |
-| testable_classes | 否 | list | 可测试类清单（来自 pytest-suitability-check，含文件路径+类名+分类） |
+| uncovered_areas | 是 | list/string | 未覆盖区域清单（来自 Step 4（references/coverage-analyze.md），首轮为 "all"） |
+| testable_classes | 否 | list | 可测试类清单（来自 Step 2（references/suitability-check.md），含文件路径+类名+分类） |
 | target | 是 | string | 被测模块路径 |
 | test_dir | 是 | string | 测试目录路径（由 agent Step 1 统一解析） |
 | test_type | 是 | string | 测试类型：unit 或 integration |
-| config | 是 | object | 来自 pytest-env-ensure 的配置对象 |
+| config | 是 | object | 来自 Step 3（references/env-ensure.md） 的配置对象 |
 
 ## 输出
 
@@ -65,7 +63,7 @@ description: |
 
 ## 阶段一：加载规范
 
-**操作**：读取 `references/test-standards.md`，加载：
+**操作**：读取 `test-standards.md`，加载：
 - 通用规范（AAA、FIRST、命名）
 - Python/pytest 特定规范（fixture、mock、parametrize）
 - test_type 对应的专属规范
@@ -324,4 +322,4 @@ agent 收到此标记后，应跳过 execute + fix，直接回到 coverage-analy
 5. 不要修改已存在的 conftest.py
 6. 不要导入项目特定的三方库到 conftest.py
 7. 不要跳过语法验证
-8. 不要使用 Test 前缀的类名（统一用 test_ 前缀）
+8. 不要使用 Test 前缀的类名（统一用 test_ 前缀）

package/skills/{pytest-case-fix/SKILL.md → pytest/references/case-fix.md}

@@ -1,9 +1,7 @@
----
-name: pytest-case-fix
-description: |
-  分析测试失败原因并修复。按失败类型分类处理：断言错误修复测试或源码、Mock 配置错误修正 patch、环境问题标记人工处理。
-  适用：测试代理内层 loop 的修复阶段，修复 pytest-execute 报告的失败用例。
-  不适用：创建新用例（使用 pytest-case-create）、覆盖率分析（使用 pytest-coverage-analyze）。
+> **原 skill**: `pytest-case-fix`（已合并入 pytest）
+> **适用**: 测试代理内层 loop 的修复阶段，修复 pytest-execute 报告的失败用例。
+> **不适用**: 创建新用例（使用 pytest-case-create）、覆盖率分析（使用 pytest-coverage-analyze）。
+
 ---
 
 # 用例修复
@@ -22,7 +20,7 @@ description: |
 
 | 参数 | 必填 | 类型 | 说明 |
 |------|------|------|------|
-| failed_tests | 是 | list | 失败用例清单（来自 pytest-execute） |
+| failed_tests | 是 | list | 失败用例清单（来自 Step 6（references/execute.md）） |
 | test_dir | 是 | string | 测试目录路径（由 agent Step 1 统一解析） |
 | report_dir | 是 | string | 报告输出目录（由 agent Step 1 统一解析） |
 | test_type | 是 | string | 测试类型：unit 或 integration |
@@ -236,7 +234,7 @@ uv run pytest "<对应测试文件>" -v --tb=short --timeout=60 -m {test_type}
 
 | 条件 | 动作 |
 |------|------|
-| 有修复（修复数 > 0） | 输出修复记录，回到 pytest-execute 重新执行 |
+| 有修复（修复数 > 0） | 输出修复记录，回到 Step 6（按 references/execute.md 执行） 重新执行 |
 | 无修复（全部标记人工处理） | 输出人工处理项，内层 loop 提前退出 |
 
 ## 失败处理
@@ -271,4 +269,4 @@ uv run pytest "<对应测试文件>" -v --tb=short --timeout=60 -m {test_type}
 5. 不要跳过源码修复后的快速测试
 6. 不要忽略语法验证或快速测试失败（必须回滚）
 7. 不要尝试修复导入错误（标记人工处理）
-8. 不要在未保存原始内容的情况下修改源码（无法回滚）
+8. 不要在未保存原始内容的情况下修改源码（无法回滚）

package/skills/{pytest-coverage-analyze/SKILL.md → pytest/references/coverage-analyze.md}

@@ -1,9 +1,7 @@
----
-name: pytest-coverage-analyze
-description: |
-  运行 pytest 覆盖率分析并按评分规则计算质量得分。解析 coverage.json 提取覆盖率数据，扫描测试文件检查质量维度。
-  适用：测试代理外层 loop 的分析阶段，评估当前测试覆盖范围和质量。
-  不适用：非 pytest 项目、非覆盖率相关的代码分析。
+> **原 skill**: `pytest-coverage-analyze`（已合并入 pytest）
+> **适用**: 测试代理外层 loop 的分析阶段，评估当前测试覆盖范围和质量。
+> **不适用**: 非 pytest 项目、非覆盖率相关的代码分析。
+
 ---
 
 # 覆盖率与质量分析
@@ -86,7 +84,7 @@ uv run pytest "{test_dir}" --cov="{target}" --cov-report=term --cov-report=json:
 - 函数覆盖率 = num_functions > 0 ? covered_functions / num_functions × 100% : 100%
 
 > **除零保护**：当分母为 0 时（源码无分支/无函数/无语句），该项覆盖率记为 100%（满分）。
-> 这与 `references/scoring-rules.md` 的"分母为 0 时该项给满分"规则一致。
+> 这与 `scoring-rules.md` 的"分母为 0 时该项给满分"规则一致。
 
 ---
 
@@ -125,7 +123,7 @@ uv run pytest "{test_dir}" --cov="{target}" --cov-report=term --cov-report=json:
 
 **输入**：覆盖率数据 + 质量检查结果
 
-**操作**：按 `references/scoring-rules.md` 的评分规则计算总分
+**操作**：按 `scoring-rules.md` 的评分规则计算总分
 
 **评分公式**：
 
@@ -192,7 +190,7 @@ uv run pytest "{test_dir}" --cov="{target}" --cov-report=term --cov-report=json:
 | 条件 | 动作 |
 |------|------|
 | score ≥ coverage_threshold | 输出"达标"，流程结束 |
-| score < coverage_threshold | 输出未覆盖区域，交给 pytest-case-create |
+| score < coverage_threshold | 输出未覆盖区域，交给 Step 5（按 references/case-create.md 执行） |
 | score ≤ previous_score（非首轮） | 输出"无改进"，提前退出外层 loop |
 
 ## 失败处理
@@ -223,4 +221,4 @@ uv run pytest "{test_dir}" --cov="{target}" --cov-report=term --cov-report=json:
 2. 不要修改源码或测试文件
 3. 不要跳过质量检查只看覆盖率
 4. 不要主观判断测试质量，只做可程序化检查的判断
-5. 不要忽略 coverage.json 解析错误
+5. 不要忽略 coverage.json 解析错误

package/skills/{pytest-env-ensure/SKILL.md → pytest/references/env-ensure.md}

@@ -1,9 +1,7 @@
----
-name: pytest-env-ensure
-description: |
-  检查 Python uv 项目环境并加载测试代理配置。验证 uv 项目结构、检查并安装依赖插件、读取配置清单。
-  适用：测试代理启动前的环境准备，任何需要验证 pytest 运行环境的场景。
-  不适用：非 uv 管理的 Python 项目、非测试相关的环境检查。
+> **原 skill**: `pytest-env-ensure`（已合并入 pytest）
+> **适用**: 测试代理启动前的环境准备，任何需要验证 pytest 运行环境的场景。
+> **不适用**: 非 uv 管理的 Python 项目、非测试相关的环境检查。
+
 ---
 
 # 环境检查与配置加载
@@ -50,7 +48,7 @@ description: |
 
 ## 阶段二：依赖检查与安装
 
-**输入**：读取 `references/config.md` 的 dependencies 清单
+**输入**：读取 `config.md` 的 dependencies 清单
 
 **操作**：
 
@@ -136,7 +134,7 @@ markers = [
 
 **操作**：
 
-1. 读取 `references/config.md`
+1. 读取 `config.md`
 2. 解析配置项：dependencies、env、loops、metrics（unit + integration）、naming、types
 3. 输出配置对象给调用方（agent）
 
@@ -195,4 +193,4 @@ markers = [
 2. 不要安装 install 为 null 的依赖（系统级工具）
 3. 不要忽略 required 依赖的失败
 4. 不要修改 config.md 文件内容
-5. 不要预设任何项目特定的依赖或配置
+5. 不要预设任何项目特定的依赖或配置

package/skills/{pytest-execute/SKILL.md → pytest/references/execute.md}

@@ -1,9 +1,7 @@
----
-name: pytest-execute
-description: |
-  执行 pytest 测试用例并输出测试报告。根据 test_type 选择对应测试目录，运行用例并解析结果。
-  适用：测试代理的测试执行阶段，运行已创建的用例并收集结果。
-  不适用：创建测试用例（使用 pytest-case-create）、修复失败用例（使用 pytest-case-fix）。
+> **原 skill**: `pytest-execute`（已合并入 pytest）
+> **适用**: 测试代理的测试执行阶段，运行已创建的用例并收集结果。
+> **不适用**: 创建测试用例（使用 pytest-case-create）、修复失败用例（使用 pytest-case-fix）。
+
 ---
 
 # 测试执行
@@ -32,7 +30,7 @@ description: |
 
 - 测试报告（通过数/失败数/跳过数）
 - 失败详情列表（文件路径、用例名、错误类型、错误信息、堆栈）
-- 决策结论（全部通过 → 回到 coverage-analyze；有失败 → 交给 case-fix）
+- 决策结论（全部通过 → 回到 Step 4（按 references/coverage-analyze.md 执行）；有失败 → 交给 case-fix）
 
 ---
 
@@ -126,8 +124,8 @@ tests/unit/xxx/test_MyService.py:15
 
 | 条件 | 动作 |
 |------|------|
-| 全部通过（failed=0, error=0） | 输出"全部通过"，回到 coverage-analyze |
-| 有失败（failed>0 或 error>0） | 输出失败详情，交给 pytest-case-fix |
+| 全部通过（failed=0, error=0） | 输出"全部通过"，回到 Step 4（按 references/coverage-analyze.md 执行） |
+| 有失败（failed>0 或 error>0） | 输出失败详情，交给 Step 7（按 references/case-fix.md 执行） |
 
 ## 失败处理
 
@@ -152,4 +150,4 @@ tests/unit/xxx/test_MyService.py:15
 2. 不要跳过失败的用例
 3. 不要混合 unit 和 integration 的测试
 4. 不要忽略 pytest 执行错误
-5. 不要使用 --tb=long（堆栈过长影响分析）
+5. 不要使用 --tb=long（堆栈过长影响分析）

package/skills/{pytest-sample/SKILL.md → pytest/references/sample.md}

@@ -1,11 +1,7 @@
----
-name: pytest-sample
-description: |
-  在当前工程 src/ 下创建 pytest-sample 目录，注入一批 demo 类代码。
-  覆盖纯函数、HTTP Mock、DB Mock、文件系统、时间依赖、随机值、环境变量、状态机等多种测试场景。
-  demo 代码中故意注入了 15 个 bug（分 3 个难度梯度），用于触发测试代理的 create→test→fix 循环。
-  适用：首次使用 pytest skill 前的演示验证、测试流程的端到端测试。
-  不适用：生产代码、非测试目的的代码生成。
+> **原 skill**: `pytest-sample`（已合并入 pytest，通过 test_type=sample 触发）
+> **适用**: 首次使用 pytest skill 前的演示验证、测试流程的端到端测试。
+> **不适用**: 生产代码、非测试目的的代码生成。
+
 ---
 
 # Demo 样例代码注入
@@ -15,7 +11,7 @@ description: |
 本 Skill 采用 **顺序执行** 工作流：
 
 1. **创建目录**：在 src/ 下创建 pytest-sample 包目录
-2. **写入文件**：从 references/src/pytest-sample/ 读取模板，写入到 src/pytest-sample/
+2. **写入文件**：从 src/pytest-sample/ 读取模板，写入到 src/pytest-sample/
 3. **验证**：检查所有文件语法正确
 
 ## 输入
@@ -40,7 +36,7 @@ description: |
 
 ## 阶段二：写入文件
 
-从 `references/src/pytest-sample/` 目录读取以下模板文件，写入到 `src/pytest-sample/`：
+从 `src/pytest-sample/` 目录读取以下模板文件，写入到 `src/pytest-sample/`：
 
 | 文件 | 覆盖场景 |
 |------|---------|
@@ -151,7 +147,7 @@ demo 代码中故意注入了 15 个 bug，分为 3 个难度梯度，用于尽
 ## 一定要做
 
 1. 必须在 src/pytest-sample/ 目录下创建文件
-2. 必须从 references/src/pytest-sample/ 读取模板内容写入
+2. 必须从 src/pytest-sample/ 读取模板内容写入
 3. 创建后必须验证语法正确
 4. 必须输出场景覆盖说明
 5. 必须保留 demo 中的故意 bug，不要修复
@@ -161,4 +157,4 @@ demo 代码中故意注入了 15 个 bug，分为 3 个难度梯度，用于尽
 1. 不要修改 src/ 下已有的其他文件
 2. 不要在 demo 代码中导入项目特定的三方库
 3. 不要跳过语法验证
-4. 不要修复 demo 中的故意 bug（它们是设计意图）
+4. 不要修复 demo 中的故意 bug（它们是设计意图）

package/skills/{pytest-suitability-check/SKILL.md → pytest/references/suitability-check.md}

@@ -1,10 +1,7 @@
----
-name: pytest-suitability-check
-description: |
-  分析源码包目录中的每个类，判断是否适合创建指定类型的测试（ut/it）。
-  递归扫描子目录，逐个类分类判定，返回可测试类清单。
-  适用：测试代理的适用性评估阶段，在创建用例前过滤不适合的类。
-  不适用：非 Python 项目、非测试类型判断。
+> **原 skill**: `pytest-suitability-check`（已合并入 pytest）
+> **适用**: 测试代理的适用性评估阶段，在创建用例前过滤不适合的类。
+> **不适用**: 非 Python 项目、非测试类型判断。
+
 ---
 
 # 模块适用性评估
@@ -221,4 +218,4 @@ IT 仅适合有外部依赖可集成的类。
 3. 不要按文件/模块整体判断（必须逐个类）
 4. 不要对 ut 类型做过滤
 5. 不要将空类或纯 ABC 纳入清单
-6. 不要主观臆断分类，必须基于信号规则
+6. 不要主观臆断分类，必须基于信号规则

package/skills/read-docs/references/superpowers/comparison.md

@@ -7,7 +7,7 @@
 | **编排者** | 宿主内置 agent + 技能 prompt | 自定义 `work` agent（`mode: primary`） |
 | **编排指令来源** | `using-superpowers` bootstrap + 技能 | agent 定义文件本身 |
 | **Worker** | 宿主内置 `general-purpose` | 宿主内置 `explore` / `general` |
-| **自定义 agent** | 无 | 3 个（lint/scrum/fastcode） |
+| **自定义 agent** | 无 | 2 个（scrum/fastcode）；lint 已改为纯 skill |
 | **技能系统** | 14 个技能，通过 `skill` 工具加载 | harness 自己的技能系统 |
 | **平台** | 跨平台（11+ harness） | 仅 opencode |
 

package/skills/read-docs/references/superpowers/index.md

@@ -44,7 +44,7 @@ Superpowers 是一个跨平台的 coding agent 增强插件，通过 **skills（
 |------|------------|-------------------|
 | 编排者 | 宿主内置 agent + 技能 prompt | 自定义 `work` agent（`mode: primary`） |
 | Worker | 宿主内置 `general-purpose` | 宿主内置 `explore` / `general` |
-| 自定义 agent | 无 | 3 个（lint/scrum/fastcode） |
+| 自定义 agent | 无 | 2 个（scrum/fastcode）；lint 已改为纯 skill |
 | 平台 | 跨平台（11+ harness） | 仅 opencode |
 
 ## 模块索引

package/agents/scrum.md

@@ -1,65 +0,0 @@
----
-description: |
-  将用户需求转化为敏捷用户故事，并使用Scrum理念开发并交付制品
-  适用场景：任意需求，特别适合多步骤任务场景。
-  不适用场景：无
-mode: primary
-temperature: 0.2
-permission: allow
-steps: 200
----
-
-<EXTREMELY-IMPORTANT>
-你是一个编排 agent，不是实现 agent。你的工作是规划、派发、审查、裁决——不是写代码。
-
-If you think there is even a 1% chance you should dispatch a subagent instead of
-doing something yourself, you ABSOLUTELY MUST dispatch a subagent.
-
-IF A TASK INVOLVES WRITING/EDITING CODE, READING SOURCE FILES, OR RUNNING TESTS,
-YOU DO NOT HAVE A CHOICE. YOU MUST DISPATCH A SUBAGENT.
-
-This is not negotiable. You cannot rationalize your way out of this.
-</EXTREMELY-IMPORTANT>
-
-## 角色
-你是一个敏捷团队的Scrum Master (简称 SM)，负责协调团队成员，分解需求、执行任务、交付制品。成员信息：
-- subagent ： `@general` 有读写权限
-- 数量 ： 10个，可并发执行
-
-## 术语对照表
-- Release ： 对应一次完整对话，可能包含一轮或多伦对话，可能提出一个或多个用户故事
-- Sprint ： 对应一轮对话，直接对应我们的工作流，一轮对话就是一轮完整的Scrum Sprint，需要交付制品
-- User Story ： 用户的每一轮输入对我们来说就是一个用户故事，可能是全新需求，已有功能补充，缺陷修复，这些故事可能密切相关，也可能独立存在
-- Increment ： 每一轮对话（sprint）交付的制品，可能是直接答复，可能是源代码，可能是文档
-- Backlog ： 一次完整对话中(Release)， 基于用户故事拆分的所有任务列表
-- Todos : 每一轮对话（sprint）,基于用户故事拆分的任务列表
-- Review : 每一轮对话（sprint）任务完成，最终交付制品前的审查, 用于评估制品质量，发现并修复问题
-
-## 变量
-- root_dir ： 项目根目录
-- session_id ： 会话ID，用于标识当前对话
-- doc_dir ： 文档目录，所有文档制品都存储在这个目录下，绝对路径为：<`root_dir>/.webwork/harness/scrum/<session_id>`>
-
-## Sprint 工作流
-每一轮对话都严格按照以下工作(Sprint): 
-1. 需求分析 : 产品经理 @general PM 将用户输入分解为用户故事，写入`<doc_dir>/backlog.md`中 (包含状态信息)
-2. Todos创建： SM 分析用户故事，将任务分配给团队成员(最多10个 @general subagent)，使用工具 `todowrite` 生成todos列表(如果有上一轮todos，完全覆盖)
-  - 每一项todo都确定了执行先后顺序，分配的subagent数量，是否可并发执行
-  - 无论本次用户故事是否与上一轮用户故事相关，都需要重新生成todos列表，不能直接使用上一轮todos列表
-3. 任务执行： 按照任务顺序，优先并行执行,执行后自己更新 todos列表状态
-4. 任务审查： 所有任务执行完成后， SM 审查所有任务执行结果,取人todos状态 ,如发现异常,则协调任务分配给多个 @general subagent 并发修复问题
-  - 修复后再检查，最多检查3次
-5. 总结与交付，交付制品包括：
-  - 回复总结
-  - review报告 `<doc_dir>/review.md`
-  - commit代码改动（如果有）
-  - backlog列表状态（更新）
-
-## 流程图
-每一轮对话都严格按照以下工作流进行：
-- 用户输入（用户故事）
-- SM 分析用户输入，生成todos列表
-- SM 分发todos列表给subagent执行
-- SM 监控subagent执行进度，协调任务分配
-- SM 汇总所有发现，生成审计报告
-- SM 交付制品