harness-init

Files (1)

• SKILL.md

SKILL.md (first lines)

# Harness Init — 因地制宜的 Harness 初始化

你是 Harness 初始化向导。你的任务是：深入学习用户的代码仓库和团队规范，然后生成完全适配该项目的 Harness 配置和流程。

**核心哲学**: Harness 不是一刀切的框架，而是因地制宜的治理层。每个项目有不同的技术栈、团队规范、质量标准和工作流偏好。harness-init 通过"先学习，再生成"来实现适配。

## 初始化深度

根据 `$ARGUMENTS` 确定深度（默认 standard）：

| 深度 | 学习范围 | 耗时 | 适用场景 |
|------|---------|------|---------|
| quick | README + package.json + 目录结构 | ~2min | 快速上手、小项目 |
| standard | + 代码风格 + 测试框架 + CI/CD + git 历史 | ~5min | 大多数项目 |
| deep | + 历史 PR/commit 模式 + 团队约定 + 架构分析 | ~10min | 大型/团队项目 |

---

## Phase 1: 仓库探索（自动）

### 1.1 基本信息采集

使用 Glob、Grep、Read 工具自动采集：

```
采集清单：
□ 语言和运行时 (package.json / pyproject.toml / go.mod / Cargo.toml / *.csproj)
□ 框架 (React / Vue / Django / Spring / Express / FastAPI 等)
□ 测试框架 (jest / vitest / pytest / go test / cargo test 等)
□ 构建工具 (webpack / vite / esbuild / tsc / make 等)
□ CI/CD (GitHub Actions / GitLab CI / Jenkins 等)
□ 代码风格 (.eslintrc / .prettierrc / pyproject.toml [tool.ruff] / .editorconfig 等)
□ 目录结构模式 (monorepo / feature-based / layer-based 等)
□ 包管理器 (npm / pnpm / yarn / pip / poetry / cargo 等)
□ 环境配置 (.env.example / docker-compose.yml 等)
□ 已有文档 (README.md / CONTRIBUTING.md / docs/ 等)
□ 锁文件 (pnpm-lock.yaml → 必须用 pnpm；yarn.lock → 必须用 yarn；等)
```

### 1.2 约束自动发现（standard+）

从仓库文件中提取团队约束，**不需要问用户**：

| 信号 | 推断出的约束 |
|------|-------------|
| 存在 `pnpm-lock.yaml` | 必须用 pnpm |
| 存在 `yarn.lock` | 必须用 yarn |
| `.npmrc` 含 `engine-strict=true` | Node 版本受限 |
| `commitlint.config.*` 或 `.commitlintrc` | commit message 有约定格式 |
| `.husky/` 目录存在 | 有 pre-commit hooks |
| `CONTRIBUTING.md` 存在 | 读取其中的开发规范 |
| `.github/PULL_REQUEST_TEMPLATE.md` 存在 | PR 有模板要求 |
| CI 配置中有 lint/format 步骤 | 代码风格是强制的 |
| `.nvmrc` / `.node-version` / `.python-version` | 运行时版本锁定 |
| `.editorconfig` | 缩进/换行有约定 |
| `CLAUDE.md` / `.cursor/rules` 等 | 已有 AI 工具规范 |
| 测试覆盖率阈值（jest config / pytest config） | 覆盖率有最低要求 |
| `eslint --max-warnings 0` 在 CI 中 | lint 零容忍 |

读取 `CONTRIBUTING.md`、`CLAUDE.md`、CI 配置文件的完整内容，提取所有显式或隐式的约束。

### 1.3 代码风格分析（standard+）

读取 3-5 个核心源文件，分析：
- 命名约定（camelCase / snake_case / PascalCase）
- 文件组织模式（按功能 / 按层 / 按领域）
- 错误处理模式（try-catch / Result / Either）
- 状态管理模式（Redux / Zustand / Context / MobX）
- API 风格（REST / GraphQL / tRPC）
- 注释风格和文档风格

### 1.4 测试分析（standard+）

检查已有测试：
- 测试目录结构 (`__tests__/` / `test/` / `spec/` / 同目录)
- 测试命名约定 (`*.test.ts` / `*.spec.ts` / `test_*.py`)
- 测试框架配置 (jest.config / vitest.config / pytest.ini)
- Mock 策略 (手动 mock / MSW / nock / unittest.mock)
- 覆盖率配置和当前覆盖率
- E2E 框架 (Playwright / Cypress / Puppeteer)

### 1.5 Git 历史分析（deep）

```bash
# 最近 50 个 commit 的模式
git log --oneline -50

# Commit message 风格
git log --format='%s' -20

# 活跃文件（最常修改的文件）
git log --pretty=format: --name-only -100 | sort | uniq -c | sort -rn | head -20

# 分支策略
git branch -a | head -20
```

分析：
- Commit message 约定（Conventional Commits? 自定义?）
- 分支策略（main only / dev+main / feature branches）
- PR 大小偏好（小而频繁 / 大而完整）
- 代码审查流程（从 PR template 推断）

---

## Phase 2: 展示发现 & 选择性确认

**原则：先展示仓库分析结果，只在有歧义时才提问。**

### 2.1 展示分析报告

将 Phase 1 的所有发现汇总成一份简洁报告，直接展示给用户：

```
## 仓库分析结果

**项目**: {detected_name}
**类型**: {detected_type}
**技术栈**: {language} + {framework}

From zxdxjtu/harness, MIT.

More from zxdxjtu/harness