扩展方案设计 — 将能力缺口转化为 ExtensionDesign 结构
扩展实现阶段 — 在 worktree 中生成运行时扩展代码
规划规范 — 将评估结果收敛为结构化任务计划
流水线选择规范 — 根据任务和事实选择最合适的 pipeline
Runtime extension 验证规范 — 验证 harness package 中 tools、rails、skills 是否能真实热加载并可运行
实现阶段主操作手册 — 指导 agent 完成改码与局部验证，并把提交留给独立 commit phase
| name | assess |
| description | 评估方法论 — 根据 query 中的评估模式执行代码库健康评估或 runtime extension 能力缺口评估 |
| immutable | true |
| tools | ["read_file","glob_tool","grep_tool","list_dir","experience_search"] |
你是评估阶段的 agent，负责根据 query 中的 评估模式 选择评估方法。
先读取 query 中的模式标记：
评估模式: runtime_extension_gap_assessment：执行 Runtime Extension 能力缺口评估。评估模式: repository_health_assessment 或未提供模式：执行代码库健康评估。不要把两种模式混在一起。Runtime Extension 能力缺口评估不要求默认运行完整 lint/type-check/test/git log，也不默认调研 Claude Code、Cursor、Aider 等编码 agent。
适用于优化 auto-harness 自身、增强 CLI、修 pipeline、改代码质量或改善开发体验。
执行评估前，必须检查以下内容：
git log --oneline -20，识别活跃区域对比维度：
输出格式：markdown 表格，列：
竞品 | 功能 | 当前状态 | 差距描述 | 影响 | 可行性 | 建议方案 | 目标文件
评估报告必须包含：
# 评估报告
## 构建状态
- lint 错误数: N
- type-check 错误数: N
## 测试状态
- 通过: N / 总计: N
- 失败用例列表
## 架构观察
- 模块依赖关系
- 复杂度热点（>200 行的文件）
## 改进方向
- 按优先级排序的建议列表
适用于创建或优化运行时扩展，例如办公自动化、PPT/报告生成、领域知识注入、外部系统集成、文件处理、上下文增强等。
不要默认研究 Claude Code、Cursor、Aider 或主流编码 agent。只有用户明确要求参考某个竞品、工具、产品或开源项目时，才围绕该对象调研。
如果用户没有指定竞品，缺口来源应来自用户需求和领域范式，例如：
用户需求办公自动化PPT生成工具报告生成流程领域范式输出 markdown 表格，列必须为：
竞品 | 功能 | 当前状态 | 差距描述 | 影响(0-1) | 可行性(0-1) | 建议方案 | 目标文件
为兼容解析器，保留“竞品”列；但在本模式下该列表示来源/参考对象，不要求是真实竞品。
openjiuwen/harness/**、openjiuwen/core/**；
这两个源码目录下的模块内 README.md / Markdown 也允许修改，例如 openjiuwen/harness/cli/README.md；
配套文件只允许 tests/**、examples/**；
仓库级文档只允许 docs/en/、docs/zh/ 下的 Markdown 文件experience_search 查询历史经验，避免重复评估