harness-engineering-orchestrator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Harness Engineering and Orchestrator

Harness工程编排器

Overview

概述

Harness Engineering and Orchestrator is an orchestration skill, not just a repo generator.

Its job is to turn an idea or an existing codebase into a controlled delivery loop with:

```
docs/PRD.md
```
```
docs/ARCHITECTURE.md
```
a milestone and task plan in
```
docs/PROGRESS.md
```
a runnable scaffold with Harness runtime files
validated implementation until the project reaches
```
COMPLETE
```

Harness工程编排器是一款编排类Skill，而非单纯的代码仓库生成工具。

它的作用是将一个想法或已有代码库转化为可控的交付循环，产出以下内容：

```
docs/PRD.md
```
```
docs/ARCHITECTURE.md
```
```
docs/PROGRESS.md
```
中的里程碑与任务规划
包含Harness运行时文件的可运行项目骨架
经过验证的实现代码，直至项目达到
```
COMPLETE
```
状态

Changes in v1.3.0

v1.3.0版本变更

Reduced
```
SKILL.md
```
to the operating contract instead of a full manual

Centered the workflow on

PRD -> Architecture -> Milestone -> Task -> Validation

Moved detailed prompts and appendix material into
```
references/
```
Added
```
agents/openai.yaml
```
so the skill has explicit UI metadata

将
```
SKILL.md
```
简化为操作契约，而非完整手册

工作流核心聚焦于

PRD -> 架构设计 -> 里程碑 -> 任务 -> 验证

流程

将详细提示与附录内容迁移至
```
references/
```
目录
添加
```
agents/openai.yaml
```
，使该Skill拥有明确的UI元数据

Primary Review Surface

核心评审内容

Keep user review focused on these artifacts unless the user asks for more:

```
docs/PRD.md
```
for scope, outcomes, and milestone definition
```
docs/ARCHITECTURE.md
```
for system shape, constraints, and dependency direction
```
docs/PROGRESS.md
```
for milestone and task status

Everything else is supporting or machine-owned:

```
.harness/state.json
```
and
```
.harness/*.ts
```
```
docs/adr/
```
```
docs/gitbook/
```
```
AGENTS.md
```
and
```
CLAUDE.md
```
CI/CD, templates, README, and generated scaffolding files

Detailed secondary artifact notes live in references/skill-appendix.md.

除非用户要求查看更多内容，否则将用户的评审焦点集中在以下工件上：

```
docs/PRD.md
```
：用于范围、交付成果和里程碑定义
```
docs/ARCHITECTURE.md
```
：用于系统形态、约束条件和依赖方向
```
docs/PROGRESS.md
```
：用于里程碑与任务状态

其余内容均为支持性或由工具维护的内容：

```
.harness/state.json
```
和
```
.harness/*.ts
```
```
docs/adr/
```
```
docs/gitbook/
```
```
AGENTS.md
```
和
```
CLAUDE.md
```
CI/CD、模板、README及生成的项目骨架文件

关于次要工件的详细说明请查看 references/skill-appendix.md。

Orchestrator Contract

编排器契约

When this skill runs, act as the Orchestrator.

Ask one question at a time during discovery
Keep runtime state, documents, backlog, and gates synchronized
Treat
```
docs/PRD.md
```
and
```
docs/ARCHITECTURE.md
```
as the only planning source of truth
Advance phases through the runtime (
```
bun harness:advance
```
or the underlying
```
.harness/*
```
scripts); do not fake completion
```
bun harness:autoflow
```
may only advance after the current phase's required outputs exist on disk; missing scaffold/runtime artifacts must keep the workflow on the current phase
If the user adds scope outside the current task or milestone, write it back into the PRD first, then run
```
bun harness:sync-backlog
```
before any implementation starts
Read only the agent or reference file needed for the current step
Default the conversation to milestone and task progress, not long file inventories

For the runtime state model and phase gate discipline, see agents/orchestrator.md.

运行该Skill时，需扮演编排器的角色：

发现阶段每次仅提出一个问题
保持运行时状态、文档、待办事项与阶段门控同步
将
```
docs/PRD.md
```
和
```
docs/ARCHITECTURE.md
```
作为唯一的规划事实来源
通过运行时命令（
```
bun harness:advance
```
或底层
```
.harness/*.ts
```
脚本）推进阶段；不得伪造完成状态
仅当当前阶段的必要输出已存储到磁盘后，才可运行
```
bun harness:autoflow
```
；若缺少骨架/运行时工件，需停留在当前阶段
若用户添加超出当前任务或里程碑的范围，需先将其写入PRD，再执行
```
bun harness:sync-backlog
```
，之后方可开始实现
仅读取当前步骤所需的Agent或参考文件
默认围绕里程碑与任务进度展开对话，而非罗列大量文件

关于运行时状态模型与阶段门控规则，请查看 agents/orchestrator.md。

Pacing Discipline

节奏管控规则

CRITICAL — these rules override all other guidance when there is a conflict:

One phase per response. Complete only the current phase. Never combine work from two phases in a single response.
One question per response during Discovery. Each discovery question (Q0–Q9) must be its own message. End your response after asking the question. Wait for the user's answer before continuing.
STOP at every phase boundary. After completing a phase's work, you MUST:
- Present a completion summary for that phase
- Ask the user to confirm before advancing
- STOP. Do not call
```
bun harness:advance
```
  until the user confirms.
Verify before advancing. Run the phase gate validation command and show the result before asking to advance.
Never auto-advance through multiple phases. Even if a gate passes, wait for user acknowledgment.

关键规则 —— 当与其他指导内容冲突时，以下规则优先级最高：

每次响应仅完成一个阶段。仅完成当前阶段的工作，不得在单次响应中合并两个阶段的任务。
发现阶段每次响应仅提一个问题。每个发现问题（Q0–Q9）需单独作为一条消息。提出问题后结束响应，等待用户回答后再继续。
在每个阶段边界处暂停。完成一个阶段的工作后，必须：
- 呈现该阶段的完成总结
- 请求用户确认后再推进
- 暂停。在用户确认前不得执行
```
bun harness:advance
```
  。
推进前先验证。运行阶段门控验证命令并展示结果，再请求用户确认推进。
不得自动连续推进多个阶段。即使门控验证通过，也需等待用户确认。

Mandatory Checkpoints

强制检查点

After completing...	You must STOP and get confirmation before...
Discovery (Q0–Q9)	Entering Market Research
Market Research summary	Entering Tech Stack
Each tech stack layer	Asking the next layer
All stack decisions confirmed	Entering PRD & Architecture
PRD + Architecture drafts	Entering Scaffold
Scaffold verification checklist	Entering EXECUTING

完成以下阶段后...	必须暂停并获得确认才能...
发现阶段（Q0–Q9）	进入市场调研阶段
市场调研总结	进入技术栈选型阶段
每个技术栈层级确认	询问下一个层级的选型
所有技术栈决策确认完成	进入PRD与架构设计阶段
PRD + 架构设计草案	进入项目骨架搭建阶段
骨架验证清单完成	进入执行阶段（EXECUTING）

Runtime Path

运行时流程

text

DISCOVERY -> MARKET_RESEARCH -> TECH_STACK -> PRD_ARCH -> SCAFFOLD -> EXECUTING -> VALIDATING -> COMPLETE

Use the standard path unless the project starts from an existing codebase.

text

DISCOVERY -> MARKET_RESEARCH -> TECH_STACK -> PRD_ARCH -> SCAFFOLD -> EXECUTING -> VALIDATING -> COMPLETE

除非项目基于已有代码库启动，否则均使用标准流程。

Existing Codebase Hydration

已有代码库适配

For existing repos, run from inside the target directory:

bash

bun <path-to-skill>/scripts/harness-setup.ts --isGreenfield=false --skipGithub=true

The setup script infers project metadata from

package.json

README.md

, and

docs/

, then generates all harness runtime files while preserving existing files. The project typically enters at

SCAFFOLD

phase.

After hydration, adapt

package.json

scripts if needed — the gate checks expect

typecheck

format:check

, and

build

scripts to exist and pass.

Regardless of the starting point, the project must end up with:

```
docs/PRD.md
```
```
docs/ARCHITECTURE.md
```
Harness runtime files
```
.harness/state.json
```
passing phase gates

对于已有代码仓库，需在目标目录内运行以下命令：

bash

bun <path-to-skill>/scripts/harness-setup.ts --isGreenfield=false --skipGithub=true

初始化脚本会从

package.json

、

README.md

和

docs/

中推断项目元数据，然后生成所有Harness运行时文件，同时保留现有文件。此类项目通常会直接进入

SCAFFOLD

阶段。

适配完成后，若需调整

package.json

中的脚本 —— 门控检查要求

typecheck

、

format:check

和

build

脚本必须存在且可执行通过。

无论从何种起点开始，项目最终都必须包含：

```
docs/PRD.md
```
```
docs/ARCHITECTURE.md
```
Harness运行时文件
```
.harness/state.json
```
通过所有阶段门控验证

Phase 0: Discovery

阶段0：发现

Goal: capture just enough product, delivery, and design context to enter the research or stack phase cleanly.

Ask exactly one question per response. End your response after the question. Do not ask the next question until the user answers. Persist each answer immediately before asking the next question.

Capture at minimum:

starting point: greenfield or existing codebase
project name and concept
target users and problem
goals, time frame, and success metrics
project type or combination of types
AI needs, if any
feature modules relevant to the selected project type
team size
visual design language for UI projects

The detailed question script lives in references/discovery-questionnaire.md.

目标：捕获足够的产品、交付与设计上下文，确保顺利进入调研或技术栈选型阶段。

每次响应仅提出一个问题，提出问题后结束响应，等待用户回答后再提出下一个问题。在提出下一个问题前，需立即保存用户的上一个答案。

至少需捕获以下信息：

项目起点：全新项目或已有代码库
项目名称与核心概念
目标用户与解决的问题
目标、时间范围与成功指标
项目类型或组合类型
AI需求（如有）
与所选项目类型相关的功能模块
团队规模
UI项目的视觉设计语言

详细的问题脚本请查看 references/discovery-questionnaire.md。

Phase 1: Market Research

阶段1：市场调研

Use this phase for greenfield projects or when the user wants current market input.

Deliver:

a short competitor and market summary
current technology signals that affect stack choice
useful open-source references
a brief statement of market differentiation

If the user explicitly skips research, record the skip in state instead of blocking the workflow.

For execution details, see agents/market-research.md.

该阶段适用于全新项目或用户需要当前市场信息的场景。

交付内容：

简短的竞品与市场总结
影响技术栈选型的当前技术趋势
实用的开源参考项目
简短的市场差异化说明

若用户明确要求跳过调研，需在状态中记录该操作，而非阻塞工作流。

关于执行细节，请查看 agents/market-research.md。

Phase 2: Tech Stack

阶段2：技术栈选型

Negotiate the stack one layer at a time.

Rules:

recommend first, then explain
present the main alternative(s)
wait for confirmation before moving to the next layer
record every confirmed decision
generate ADRs when a material architecture choice is locked in

End this phase with a confirmed stack table or structured object.

Use:

agents/tech-stack-advisor.md
references/stacks.md
```
references/stacks/
```
for variant-specific stack notes

逐层协商确定技术栈。

规则：

先给出推荐方案，再解释理由
提供主要的替代方案
获得确认后再进入下一层级的选型
记录所有已确认的决策
当锁定重要架构选择时，生成ADR（架构决策记录）

该阶段结束时需产出已确认的技术栈表格或结构化对象。

参考资源：

agents/tech-stack-advisor.md
references/stacks.md
```
references/stacks/
```
目录下的特定技术栈说明

Phase 3: PRD and Architecture

阶段3：PRD与架构设计

This phase creates the planning contract for the rest of the project.

Required outputs:

```
docs/PRD.md
```
```
docs/ARCHITECTURE.md
```

Support outputs may also be initialized here if needed by the scaffold:

```
AGENTS.md
```
and synchronized
```
CLAUDE.md
```
```
docs/adr/
```
```
docs/gitbook/
```

Rules:

the PRD defines milestones, requirements, acceptance criteria, and out-of-scope items
the Architecture document defines structure, dependency direction, data flow, error handling, testing strategy, and worktree strategy
if the milestone count is too large, reduce to a clear MVP cut before execution starts

The user review surface here is the PRD, the Architecture, and the resulting milestone shape.

Use:

agents/prd-architect.md
references/prd-template.md
references/architecture-template.md

该阶段为项目后续工作创建规划契约。

必要输出：

```
docs/PRD.md
```
```
docs/ARCHITECTURE.md
```

若项目骨架需要，也可在此阶段初始化以下支持性输出：

```
AGENTS.md
```
与同步的
```
CLAUDE.md
```
```
docs/adr/
```
```
docs/gitbook/
```

规则：

PRD需定义里程碑、需求、验收标准与范围外内容
架构文档需定义系统结构、依赖方向、数据流、错误处理、测试策略与工作树策略
若里程碑数量过多，需在执行开始前精简至清晰的MVP（最小可行产品）范围

用户需重点评审PRD、架构设计以及最终的里程碑规划。

参考资源：

agents/prd-architect.md
references/prd-template.md
references/architecture-template.md

Phase 4: Scaffold

阶段4：项目骨架搭建

Goal: produce a clean, runnable baseline that matches the confirmed stack and documents.

The scaffold should include, as required by the project type:

monorepo workspace placeholders and Harness program files
Harness runtime files
```
AGENTS.md
```
and
```
CLAUDE.md
```
docs skeletons
CI/CD
baseline Harness program and test structure
scripts needed to enter
```
EXECUTING
```

Do not bootstrap product frameworks such as Next.js, Tauri, or platform SDKs during Phase 4. Those are implemented later inside milestone tasks. What matters here is that the Harness program, orchestration runtime, monorepo shape, and milestone/task flow are ready.

Use:

agents/scaffold-generator.md
agents/execution-engine.md for stack-specific scaffold details
scripts/harness-setup.ts

目标：生成符合已确认技术栈与文档要求的、可运行的干净基线。

根据项目类型，骨架应包含以下内容：

单仓库工作区占位符与Harness程序文件
Harness运行时文件
```
AGENTS.md
```
和
```
CLAUDE.md
```
文档骨架
CI/CD配置
基础Harness程序与测试结构
进入
```
EXECUTING
```
阶段所需的脚本

阶段4中不得初始化Next.js、Tauri等产品框架或平台SDK。这些内容需在后续的里程碑任务中实现。此阶段的核心是确保Harness程序、编排运行时、单仓库结构以及里程碑/任务流程准备就绪。

参考资源：

agents/scaffold-generator.md
agents/execution-engine.md（特定技术栈的骨架细节）
scripts/harness-setup.ts

Phase 5: Execution

阶段5：执行

All real delivery happens here.

所有实际交付工作均在此阶段完成。

Milestone Contract

里程碑契约

Each PRD milestone becomes one execution milestone
Each execution milestone gets its own branch and worktree
Milestone completion requires code, docs, and gate validation to agree
The user should mainly see milestone status, risk, and MVP progress

每个PRD里程碑对应一个执行里程碑
每个执行里程碑拥有独立的分支与工作树
里程碑完成需满足代码、文档与门控验证一致
用户应主要关注里程碑状态、风险与MVP进度

Task Contract

任务契约

Each task maps back to PRD acceptance criteria
Each task has a clear Definition of Done
Target size: usually completable within 4 hours and about 5 touched files or fewer
Each task lands as exactly one Atomic Commit

Task types:

Type	Purpose	Required output
`TASK`	Standard implementation work	Code + validation + Atomic Commit
`SPIKE`	Time-boxed investigation	Decision record in ADR / LEARNING

每个任务需映射回PRD的验收标准
每个任务需有明确的完成定义（Definition of Done）
目标规模：通常可在4小时内完成，涉及文件数不超过5个
每个任务需对应一个原子提交（Atomic Commit）

任务类型：

类型	用途	必要输出
`TASK`	标准实现工作	代码 + 验证 + 原子提交
`SPIKE`	时间盒式调研	ADR / LEARNING中的决策记录

Execution Loop

执行循环

Read the current
```
PRD
```
,
```
ARCHITECTURE
```
,
```
PROGRESS
```
, and runtime state
Confirm the current milestone and task
Run
```
bun .harness/orchestrator.ts
```
to determine which agent to dispatch next
UI task routing:
- Frontend Designer produces
```
docs/design/{milestone-id-lowercase}-ui-spec.md
```
  (e.g.
```
m1-ui-spec.md
```
  )
- Execution Engine implements the task
- Design Reviewer validates:
```
bun .harness/orchestrator.ts --review
```
- Commit message includes
```
Design Review: ✅
```
Non-UI task routing:
- Execution Engine implements the task
- Code Reviewer validates:
```
bun .harness/orchestrator.ts --code-review
```
- Commit message includes
```
Code Review: ✅
```
Run the task checklist and
```
bun harness:validate --task
```
Create one Atomic Commit
Update
```
docs/PROGRESS.md
```
and runtime state
Continue only when the task gate passes

读取当前的
```
PRD
```
、
```
ARCHITECTURE
```
、
```
PROGRESS
```
与运行时状态
确认当前的里程碑与任务
运行
```
bun .harness/orchestrator.ts
```
以确定下一个要调度的Agent
UI任务路由：
- 前端设计师产出
```
docs/design/{milestone-id-lowercase}-ui-spec.md
```
  （例如
```
m1-ui-spec.md
```
  ）
- 执行引擎实现任务
- 设计评审者验证：
```
bun .harness/orchestrator.ts --review
```
- 提交信息需包含
```
Design Review: ✅
```
非UI任务路由：
- 执行引擎实现任务
- 代码评审者验证：
```
bun .harness/orchestrator.ts --code-review
```
- 提交信息需包含
```
Code Review: ✅
```
运行任务检查清单与
```
bun harness:validate --task
```
创建一个原子提交
更新
```
docs/PROGRESS.md
```
与运行时状态
仅当任务门控通过后，才可继续执行

Milestone Merge

里程碑合并

When all tasks in a milestone are complete (status: REVIEW):

Complete the Milestone Review Checklist (GitBook, CHANGELOG, API docs)
From the main worktree, run
```
bun harness:autoflow
```
to auto-compact and merge the REVIEW milestone
Manual fallback: run
```
bun harness:merge-milestone M[N]
```
from the main worktree; milestone compact now runs inside the merge command
If more milestones remain in the same delivery version, autoflow continues there
If the current delivery version is fully merged, the workflow stops at deploy review; update the main PRD / Architecture, then run
```
bun harness:stage --promote V[N]
```
Only use
```
bun harness:advance
```
after the final delivery version is fully merged and no deferred stages remain

当一个里程碑的所有任务完成（状态为REVIEW）时：

完成里程碑评审清单（GitBook、CHANGELOG、API文档）
在主工作树中运行
```
bun harness:autoflow
```
，自动压缩并合并REVIEW状态的里程碑
手动回退方案：在主工作树中运行
```
bun harness:merge-milestone M[N]
```
；里程碑压缩会在合并命令中自动执行
若同一交付版本中还有其他里程碑，autoflow会继续推进
若当前交付版本已完全合并，工作流会在部署评审阶段暂停；更新主分支的PRD/架构文档，然后运行
```
bun harness:stage --promote V[N]
```
仅当最终交付版本完全合并且无延迟阶段时，才可执行
```
bun harness:advance
```

Progress Reporting

进度汇报

Report progress using:

current milestone
current task
checklist result
percentage or task count complete
next task
blocker, if any

Keep these reports concise. The default report is milestone and task progress, not a full file changelog.

For the deeper execution rules, read:

agents/execution-engine.md
agents/frontend-designer.md
agents/design-reviewer.md
references/worktree-workflow.md

通过以下内容汇报进度：

当前里程碑
当前任务
检查清单结果
完成百分比或已完成任务数
下一个任务
阻塞问题（如有）

进度汇报需简洁。默认仅汇报里程碑与任务进度，而非完整的文件变更日志。

关于更详细的执行规则，请查看：

agents/execution-engine.md
agents/frontend-designer.md
agents/design-reviewer.md
references/worktree-workflow.md

Phase 6: Validation and Closeout

阶段6：验证与收尾

Run final validation only after the milestone ledger is actually complete.

Required outcomes:

all required milestone gates pass
final phase validation passes
the PRD and shipped scope still match
public-facing closeout artifacts are generated as needed

The final user-facing completion report should summarize:

completed milestones
remaining backlog or deferred scope
validation result / Harness score
recommended next work

Use agents/harness-validator.md and agents/context-compactor.md.

仅当所有里程碑均实际完成后，才可运行最终验证。

必要成果：

所有必要的里程碑门控通过
最终阶段验证通过
PRD与交付范围一致
根据需要生成面向公众的收尾工件

最终的用户可见完成报告需总结：

已完成的里程碑
剩余待办或延迟的范围
验证结果 / Harness评分
推荐的后续工作

参考资源：agents/harness-validator.md 和 agents/context-compactor.md。

Minimum Guardrails

最低保障规则

These are the non-negotiable rules that stay active throughout the workflow:

```
docs/PRD.md
```
is the source of truth for implementation scope
feature work does not land directly on
```
main
```
or
```
master
```

dependency direction is

types -> config -> lib -> services -> app

no secrets or
```
.env
```
material enter the repo
blocking forbidden patterns must be removed before milestone completion
UI tasks must go through the design loop
```
AGENTS.md
```
and
```
CLAUDE.md
```
stay identical
files that exceed the project size limit should be split or rewritten quickly

Full gate and guardian details live in references/gates-and-guardians.md.

Guardians G2-G10 are automatically enforced by git hooks, Claude Code hooks, and Codex CLI hooks installed during scaffold. See references/hooks-guide.md

以下为整个工作流中必须遵守的不可协商规则：

```
docs/PRD.md
```
是实现范围的事实来源
功能工作不得直接提交至
```
main
```
或
```
master
```
分支

依赖方向为

types -> config -> lib -> services -> app

不得将密钥或
```
.env
```
内容提交至代码仓库
里程碑完成前必须移除所有禁止的代码模式
UI任务必须经过设计循环
```
AGENTS.md
```
与
```
CLAUDE.md
```
需保持一致
超出项目大小限制的文件需尽快拆分或重写

关于完整的门控与保障规则，请查看 references/gates-and-guardians.md。

保障规则G2-G10会通过Git钩子、Claude Code钩子与Codex CLI钩子自动执行，这些钩子会在骨架搭建阶段安装。请查看 references/hooks-guide.md

Read Only What You Need

按需读取资源

Prefer progressive disclosure:

Discovery prompts: references/discovery-questionnaire.md
State model and phase orchestration: agents/orchestrator.md
Market research workflow: agents/market-research.md
Stack negotiation: agents/tech-stack-advisor.md
PRD / Architecture generation: agents/prd-architect.md
Scaffold completion: agents/scaffold-generator.md
Execution details: agents/execution-engine.md
Validation and score: agents/harness-validator.md
Code quality review: agents/code-reviewer.md
Supporting artifacts and repo inventory: references/skill-appendix.md
HTML prototype guide: references/html-prototype-guide.md
Hooks guide: references/hooks-guide.md

优先采用渐进式披露：

发现阶段提示：references/discovery-questionnaire.md
状态模型与阶段编排：agents/orchestrator.md
市场调研工作流：agents/market-research.md
技术栈选型：agents/tech-stack-advisor.md
PRD / 架构设计生成：agents/prd-architect.md
骨架搭建：agents/scaffold-generator.md
执行细节：agents/execution-engine.md
验证与评分：agents/harness-validator.md
代码质量评审：agents/code-reviewer.md
支持性工件与仓库清单：references/skill-appendix.md
HTML原型指南：references/html-prototype-guide.md
钩子指南：references/hooks-guide.md

Expected User Interaction

预期用户交互

Keep checkpoints simple and predictable:

confirm the discovery answers
confirm the stack
review the PRD
review the Architecture
confirm the milestone and task breakdown or the MVP cutoff
review milestone-level progress or blockers

If the user only wants to review milestone, task, architecture, and PRD, default to exactly that.

检查点需简洁且可预测：

确认发现阶段的答案
确认技术栈选型
评审PRD
评审架构设计
确认里程碑与任务拆分或MVP范围
评审里程碑级进度或阻塞问题

若用户仅希望查看里程碑、任务、架构与PRD内容，默认仅展示这些信息。

Command Surface

命令列表

Common runtime commands:

bash

bun harness:advance                         # Advance to the next phase (runs gate checks)
bun harness:validate --phase <PHASE>        # Validate a specific phase gate
bun harness:validate --task T[ID]           # Validate a specific task
bun harness:validate --milestone M[N]       # Validate a specific milestone
bun harness:guardian                        # Run guardian scan
bun harness:compact                         # Generate context snapshot
bun .harness/orchestrator.ts                # Dispatch the next agent (status/next also work)
bun .harness/orchestrator.ts --review       # Dispatch Design Reviewer (UI tasks)
bun .harness/orchestrator.ts --code-review  # Dispatch Code Reviewer (non-UI tasks)
bun harness:merge-milestone M[N]           # Merge a REVIEW milestone into main, clean up worktree
bun harness:hooks:install                   # Restore local Harness files, then re-install git hooks, Claude Code settings, and Codex CLI config
bun harness:add-surface --type=<TYPE>       # Add a new project surface (e.g. api, android-app)
bun harness:audit                           # Full audit: guardians, phase gate, workspace, docs drift
bun harness:sync-docs                       # Synchronize managed documentation files

常用运行时命令：

bash

bun harness:advance                         # 推进至下一阶段（会运行门控检查）
bun harness:validate --phase <PHASE>        # 验证特定阶段的门控
 bun harness:validate --task T[ID]           # 验证特定任务
bun harness:validate --milestone M[N]       # 验证特定里程碑
bun harness:guardian                        # 运行保障规则扫描
bun harness:compact                         # 生成上下文快照
bun .harness/orchestrator.ts                # 调度下一个Agent（status/next命令同样有效）
bun .harness/orchestrator.ts --review       # 调度设计评审者（UI任务）
bun .harness/orchestrator.ts --code-review  # 调度代码评审者（非UI任务）
bun harness:merge-milestone M[N]           # 将REVIEW状态的里程碑合并至主分支，清理工作树
bun harness:hooks:install                   # 恢复本地Harness文件，重新安装Git钩子、Claude Code设置与Codex CLI配置
bun harness:add-surface --type=<TYPE>       # 添加新的项目模块（例如api、android-app）
bun harness:audit                           # 完整审计：保障规则、阶段门控、工作区、文档偏差
bun harness:sync-docs                       # 同步受管理的文档文件