Menü
在当前模块目录下初始化 Harness 框架。扫描代码结构、预填上下文文件、引导开发者逐节审核确认，最终写入 .harness/ 目录。适用于 cmd/、apps/、pkg/ 下的任意模块。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | harness-init |
| description | 在当前模块目录下初始化 Harness 框架。扫描代码结构、预填上下文文件、引导开发者逐节审核确认，最终写入 .harness/ 目录。适用于 cmd/、apps/、pkg/ 下的任意模块。 |
用户执行 /harness-init 或明确说"帮我初始化 harness"时调用本 skill。
扫描当前目录，收集以下信息：
1. 判断模块类型
cmd/ → 类型 = cmd（后台服务）apps/ → 类型 = app（Web 服务）pkg/ → 类型 = pkg（共享包）2. 读取现有文档（按优先级）
README.md（当前目录）.roo/rules/ 下所有 .md 文件.cospec/docs/ 下所有 .md 文件3. 分析代码结构
.go 文件的 import 块，提取 pkg/ 依赖列表git log --oneline -20，了解近期变更高频区域4. 查找已有 Harness
.harness/5. 查找依赖包的 Harness
pkg/ 依赖，检查 {monorepo_root}/pkg/{name}/.harness/contract.md 是否存在6. 查找同类模块的 Harness（辅助推断）
.harness/context/module.md7. 输出扫描摘要
🔍 扫描完成：
模块类型：{cmd/app/pkg}
发现文档：README.md ✓ / .roo/rules ✓ / .cospec/docs ✓
pkg 依赖：{列表，注明哪些有 Harness、哪些没有}
近期高频变更：{top 3 文件}
模式：{全量初始化 / 增量补全（发现 N 个 TODO）}
开始逐节确认，你可以：
· 直接说「好」接受草稿
· 说出修改意见，我来改
· 说「跳过」留 TODO 占位，后续补充
按以下顺序逐节展示草稿，每节确认后再进入下一节。
节 1：module.md（模块身份）
根据扫描结果生成草稿，格式：
📄 module.md 草稿：
模块名：{推断的模块名}
类型：{cmd/app/pkg}（推断来源：目录路径）
负责人：{从 git log 推断的主要提交者}
职责：{从 README 提取的一句话描述，或从目录结构推断}
核心概念：
- {从代码/README 提取的关键术语 1}
- {从代码/README 提取的关键术语 2}
（低置信度内容标注 ⚠️ 推断，请验证）
这样描述准确吗？
节 2：deps.md（依赖关系）
📄 deps.md 草稿：
依赖的 pkg 包：
{对每个 import 的 pkg/：
- pkg/{name}（有/无 Harness）
用途：{从 contract.md 读取描述，或标注 ⚠️ 从代码推断}
关键接口：{列出调用的函数，从代码 grep 结果整理}}
外部服务依赖：
{从代码扫描 mongo/redis/kafka 关键词推断}
这样准确吗？
节 3：arch.md（架构决策）
📄 arch.md 草稿：
根据 git log 和代码结构，我推断了以下可能的架构决策：
{如果有明显的设计模式，如 Provider 接口、插件系统等，生成一条 ADR 草稿}
{如果推断不出，生成一条空的 ADR 模板并标注 TODO}
这些推断准确吗？或者有哪些重要的架构决策需要记录？
节 4：constraints.md（规范约束）
📄 constraints.md 草稿：
从 .roo/rules/ 和 .cospec/docs/ 继承的约束：
{列出从现有文档提取的相关规范}
从代码推断的约束：
高危区域：{近30天变更超过5次的文件，标注为高频变更}
待补充（TODO）：
- 禁止项：TODO
- 测试要求：TODO
- 部署注意：TODO
这些准确吗？有要补充的禁止项或特殊约束吗？
节 5：workflow/dev.md（流程编排）
📄 workflow/dev.md 草稿：
（展示 dev.md.tmpl 的默认内容）
默认流程包含：影响面分析 → brainstorming → planning → TDD 编码 → 验证 → 双 Review → PR
需要定制吗？比如：
· 跳过某些步骤
· 添加团队特有的检查环节
· 修改 Review 配置（adversarial_reviewer）
.harness/context/*.md 和 .harness/overrides/ 中含 TODO 的行（精确字符串匹配）所有节确认完毕后：
✅ 所有内容确认完毕，准备写入：
.harness/AGENTS.md
.harness/framework/version ← 从框架仓库读取
.harness/context/module.md
.harness/context/deps.md
.harness/context/arch.md
.harness/context/constraints.md
.harness/workflow/dev.md
.harness/workflow/checklist.md
要一并 git commit 吗？(y / 不用)
写入时，将 AGENTS.md.tmpl 中的占位符替换：
{{MODULE_NAME}} → module.md 中的模块名{{FRAMEWORK_VERSION}} → 读取 ~/.forge/framework/version，若不存在则填 unknownpkg 类型只写入：
.harness/contract.md（从 templates/pkg/contract.md.tmpl）.harness/constraints.md（从 templates/pkg/constraints.md.tmpl）.harness/owner.md（从 templates/pkg/owner.md.tmpl）| 场景 | 处理方式 |
|---|---|
| 目录类型无法判断 | 展示选项让用户选择（cmd / app / pkg / 其他） |
| README 缺失 | 完全从代码推断，低置信度内容标注 ⚠️ 推断，请验证 |
| 依赖的 pkg 无 Harness | deps.md 标注 ⚠️ 无 Harness，建议包主人运行 harness-init |
.harness/ 已存在且无 TODO | 提示"Harness 已完整"，询问是否要重新审核某节 |
| 在框架仓库根目录运行 | 提示"请在模块目录下运行，如 cmd/my-module/" |
模块开发主循环。轻量协调者：加载上下文后调用 harness-onboard（需求分类+影响面+流程确认），再调用 harness-roles（帽子系统多角色执行），最后沉淀上下文。通常由 .harness/AGENTS.md 自动激活，也可通过 /harness-dev 显式调用。
升级当前模块 .harness/framework/ 到最新版本。三层分离设计保证 context/（开发者托管）和 overrides/ 永不被覆盖。可在 harness-dev 提示有新版本时调用，也可直接执行 /harness-upgrade。
Team-level AI spend visibility. Tracks token usage per PR, attribute costs to author/reviewer, generates exportable cost reports. Built on top of harness-roles budget tracking.
CI failure auto-fix. Reads failure logs, identifies root cause, applies fix, commits and creates PR. Triggered by workflow_run or called directly via /fix-ci.
需求分类 + 影响面分析 + 动态流程确认。从用户描述推断工作类型，fetch-first 扫描代码，输出影响面报告，解析 workflow/dev.md 的 rules 动态调整插槽列表，展示流程供用户确认调整，最终输出 resolved_slots JSON 交给 harness-roles 执行。
机械执行层。将 constraints.md 中的规则翻译为可执行的 lint 规则、pre-commit hooks 和 CI 检查脚本。读取 constraints.md，解析 enforcement 块，生成对应脚本并注册到 .git/hooks/ 或 CI 配置。