harness-work

Harness Work

Harness integrated execution skill. Integrates the following legacy skills:

work — Implementation of Plans.md tasks (automatic scope determination)
impl — Feature implementation (task-based)
breezing — Team full auto execution
parallel-workflows — Parallel workflow optimization
ci — Recovery on CI failure

Quick Reference

User input	Mode	Action
`/harness-work`	auto	Automatically determined by task count (see below)
`/harness-work all`	auto	Execute all incomplete tasks in auto mode
`/harness-work 3`	solo	Immediately execute only task 3
`/harness-work --parallel 5`	parallel	Parallel execution with 5 workers (forced)
`/harness-work --codex`	codex	Delegate to Codex CLI (only when explicitly specified)
Cursor host (adapter candidate)	cursor	Task/subagent routing via `.cursor/AGENTS.md`; not auto-selected
`/harness-work --breezing`	breezing	Force team execution
`/harness-work 3 --plan roadmap`	solo	named Plans の `roadmap` Execute task 3 from

Execution Mode Auto Selection (automatic determination when no flag is present)

When there is no explicit mode flag (--parallel, --breezing, --codex), automatically select the optimal mode according to the number of target tasks:

Target task count	Auto-selected mode	Reason
1 item	Solo	Minimal overhead. Direct implementation is fastest
2–3 items	Parallel（Task tool）	Threshold at which the benefits of Worker separation begin to appear
4 items or more	Breezing	The three-way separation of Lead coordination + Worker parallelism + independent Reviewer is effective

Rules

Explicit flags always override auto modedo (--parallel N / --breezing / --codex is forced regardless of task count)
--codex is triggered only when explicitly specified. Since some environments do not have Codex CLI installed, it is not auto-selected
--codex can be combined with other modes: --codex --breezing → Codex + Breezing

Execution Backend Selection (implementation backend selection)

Backend (which runtimeWhether to implement) is orthogonal to the execution mode (topology: solo / parallel / breezing).

backend	Implementer	Delegation command
`claude`(default)	Task subagent（`agents/worker.md`）	Agent tool で worker を spawn
`codex`	Codex CLI	`bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write "<prompt>"`
`cursor`	cursor-agent（model `composer-2.5-fast`）	`bash "${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh" task --write --workspace <worktree> "<prompt>"`

For governance details of Codex invocation (prohibited items, verdict mapping, etc.), refer to references/codex-cli-only.md .

Resolve only once with the resolver at the start of run.HARNESS_IMPL_BACKEND Do not read env directly to determine backend:

bash "${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh"

precedence (highest first): explicit flag (--backend / --cursor / --codex) > env > project file > user file > default claude. Project settings override user scope.

Backend default (`claude` is the intended default; warnings only on invalid-value fallback)

The default backend is claude(Native subagent). The resolver's unset fallback is also claude , and when it is successfully resolved to claude , no warning isissued(2026-07-24 operator ruling. The format is identical to the Narration Rules "Backend default and per-run flat judgment" in breezing , cross-ref: skills/breezing/SKILL.md）。

⚠️ A warning is issued only when the resolver performs an invalid-value fallback Only when a stderr warning is emitted. One line immediately after the banner, not repeated within the same run
The Lead may choose the backend flat per-run according to the work content and volume. When choosing, use an explicit override to the resolver (--backend <v> / --codex / --cursor)
composer / コンポーザー / composer 2.5 Natural language expressions such as --cursor are treated as the same intent as --backend cursor and passed to the resolver as an explicit override (natural language backend trigger)

The backend is role-scoped: Following the resolved backend applies only to the implementation (worker) role. Reviewer / Advisor are always fixed to brain (--host claude) (do not route the primary reviewer to cursor/codex). The only exception is fresh-context advisory pre-review : a cursor review tier that does not share conversation state with the session that generated the diff is permitted to produce advisory findings, and the primary verdict (APPROVE | REQUEST_CHANGES) is produced only by brain.

bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host cursor --role worker --field model
bash "${HARNESS_PLUGIN_ROOT}/scripts/model-routing.sh" --host claude --role reviewer --field model

backend が codex / cursor , the Lead does not spawn a Worker agent and calls the companion directly (topology without Worker intermediation). The self_review gate is skipped, and the Lead's diff review becomes the only quality gate. Before delegation, output the cursor backend banner, and before cherry-pick pass the two-stage contract grep gate (test-support-claim-wording.sh / check-consistency.sh / validate-plugin.sh). For details of the Mode 1 Producer → Sub-Lead → Composer hierarchy and the review→iterate loop, see references/backend-selection.md .

Options

Option	Description	Default
`all`	Targets all incomplete tasks	-
`N` or `N-M`	Task number/range specification	-
`--parallel N`	Number of parallel workers (upper limit is the CC-side concurrency cap, default 20. See below for details)	auto
`--sequential`	Force serial execution	-
`--codex`	Delegate implementation to Codex CLI (only when explicit, not auto-selected)	false
`--backend <claude\|codex\|cursor>`	Explicit backend selection (applies only to the worker role, highest precedence)	claude
`--cursor`	cursor backend（`--codex` , only when explicit. Not auto-selected because there are environments without cursor-agent installed)	false
`--plan NAME`	`plans/manifest.json` 's named plan	active/default
`--no-commit`	Suppress automatic commit	false
`--resume <id\|latest>`	Resume previous session. After a long idle period, `/recap` is recommended in combination	-
`--breezing`	Lead/Worker/Reviewer team execution	false
`--no-tdd`	Skip TDD phase	false
`--tdd-bypass`	Bypass mandatory TDD only in emergencies.`HARNESS_TDD_BYPASS_REASON` or keep an explicit reason in the audit	false
`--no-simplify`	Skip Auto-Refinement	false
`--auto-mode`	Explicitly request Harness-side Auto Mode rollout. Separate from `--enable-auto-mode` , which became unnecessary in CC 2.1.111	false

Progressive Disclosure

First, check only the entry points, automatic selection, and stop conditions in this main text. Read the details only when needed.

Details	Reference
Complete version of the 1–17 steps for Solo / Breezing, complete version of Phases A/B/C	`references/execution-modes.md`
Backend role-scoped constraints, non-claude topology, Mode 1 hierarchy, review→iterate	`references/backend-selection.md`
Codex review, Reviewer fallback, verdict mapping, fix loop	`references/review-loop.md`
Sprint Contract field list, PR Closeout	`references/sprint-contract.md`
Details of effort tier multi-factor scoring	`references/effort-routing.md`
Generation of Solo / Breezing completion reports	`references/completion-report.md`
Command for re-ticketing on test/CI failure	`references/failure-reticketing.md`
Criteria for specification source-of-truth checks	`docs/plans/spec-ssot.md`

Important stop conditions

Plans.md If the old format cannot read DoD / Depends / Status, stop.
If the spec affects implementation decisions but the project spec SSOT cannot be found, first create/update the authoritative spec, then implement.
If the sprint-contract is required but not ready, do not proceed to implementation.
Do not consider the work complete while critical / major review findings remain.
Do not resolve this by weakening tests, skipping them, or loosening expected values to match the implementation.
helper script は host project の scripts/ instead of ${HARNESS_PLUGIN_ROOT}/scripts/ .
When there are multiple Plans.md files, do not switch plans within a single run. If necessary, --plan NAME explicitly and start a new run.

Token Optimization (v2.1.69+): For lightweight tasks that do not involve git operations, enable includeGitInstructions: false in plugin settings to reduce prompt tokens.

Prompt Cache (CC 2.1.108+): For longer implementations or work that heavily uses --resume , prefer ENABLE_PROMPT_CACHING_1H=1 .

Scope dialog (when there are no arguments)

/harness-work
どこまでやりますか?
1) 次のタスク: Plans.md の次の未完了タスク → Solo で実行
2) 全部（推奨）: 残りのタスクをすべて完了 → タスク数で自動モード選択
3) 番号指定: タスク番号を入力（例: 3, 5-7）→ 件数で自動モード選択

If there are arguments, execute immediately (skip the dialogue):

/harness-work all → all tasks, automatic mode selection
/harness-work 3-6 → 4 items, so Breezing is auto-selected

Effort level control (Opus 4.8 / v2.1.111+)

effort is the official knob for choosing the model's reasoning intensity.low(○)/medium(◐)/high(●)/xhigh in 4 stages, and you can reset to the default with /effort auto . Determine the tier from the complexity score (the sum of file count, target directories, keywords, failure history, and explicit specification), and do not use the approach of injecting a free-text marker (the old ultrathink) into the spawn prompt.

Score	code-risk (including core/guardrails/security/architecture/migration)	effort tier
0-2	Any	`medium`(leave as the Worker frontmatter default)
≥ 3	None	`high`
≥ 3	Yes	`xhigh`

Apply the same logic in breezing mode as well (harness-work manages it in a unified way). For the scoring breakdown and details of the levers, see references/effort-routing.md .

Execution mode details

Harness helper script root

Helper scripts bundled with Harness must always be called from the plugin bundle root, not from the target project's scripts/ .

HARNESS_PLUGIN_ROOT="${HARNESS_PLUGIN_ROOT:-${CLAUDE_PLUGIN_ROOT:-}}"
if [ -z "$HARNESS_PLUGIN_ROOT" ] && [ -n "${CLAUDE_SKILL_DIR:-}" ]; then
  probe="$(cd "${CLAUDE_SKILL_DIR}" && pwd)"
  while [ "$probe" != "/" ] && [ ! -d "$probe/scripts" ]; do
    probe="$(cd "$probe/.." && pwd)"
  done
  [ -d "$probe/scripts" ] && HARNESS_PLUGIN_ROOT="$probe"
fi

The subsequent node "${HARNESS_PLUGIN_ROOT}/scripts/..." / bash "${HARNESS_PLUGIN_ROOT}/scripts/..." assume this resolved root.

Backend-resolved executor path (Solo / Parallel / Breezing)

Solo / Parallel / Breezing choose the implementation executor from the same resolver result. harness-work 3 --cursor or resolver output of cursor (including defaults via project / user files) must not fall through to local Read/Write/Edit/Bash even for a single task.

resolver_backend_arg = ""
if explicit_backend_value in ["claude", "codex", "cursor"]:
    resolver_backend_arg = "--backend {explicit_backend_value}"
backend = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/resolve-impl-backend.sh\" {resolver_backend_arg}")
if explicit_flag == "--cursor":
    backend = "cursor"
if explicit_flag == "--codex":
    backend = "codex"

if topology in ["solo", "parallel"] and backend in ["cursor", "codex"]:
    BASE_REF = git("rev-parse", "HEAD")
    WT_ID = "{task.number}-$(date +%Y%m%d-%H%M%S)-$$"
    worktree_path = ".claude/worktrees/{backend}-{WT_ID}"
    worktree_branch = "{backend}-work/{WT_ID}"
    bash("mkdir -p .claude/worktrees && git worktree add -b {worktree_branch} {worktree_path} {BASE_REF}")
    companion_prompt = "{task prompt}\n\nAfter making changes, create exactly one git commit in this worktree before returning."
    if backend == "cursor":
        companion_output = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh\" task --write --workspace {worktree_path} \"{companion_prompt}\"")
    else:
        companion_state_file = "{worktree_path}/.claude/state/codex-primary-environment.json"
        companion_output = bash("CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE={companion_state_file} bash \"${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh\" task --write -C {worktree_path} \"{companion_prompt}\"")
    latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
    if backend == "cursor" and git("-C", worktree_path, "status", "--porcelain") != "":
        git("-C", worktree_path, "add", "-A")
        git("-C", worktree_path, "-c", "user.name=cursor-composer", "-c", "user.email=cursor-composer@local", "commit", "--no-verify", "-m", "cursor: delegated change")
        latest_commit = git("-C", worktree_path, "rev-parse", "HEAD")
    if latest_commit == BASE_REF:
        raise EscalationError("{backend} companion produced no commit")
    worker_result = {type: "companion-result.v1", baseCommit: BASE_REF, commit: latest_commit, worktreePath: worktree_path, branch: worktree_branch, files_changed: git("-C", worktree_path, "diff", "--name-only", "{BASE_REF}..HEAD"), summary: companion_output}
    enter_non_claude_companion_review_loop(worker_result)
else:
    run_native_solo_or_parallel()

def enter_non_claude_companion_review_loop(worker_result):
    # companion-result.v1 has no worker_id and no worker_result.self_review.
    # Do not use the Worker-only SendMessage/self_review loop for cursor/codex.
    latest_commit = worker_result.commit
    diff_text = git("-C", worker_result.worktreePath, "diff", "{worker_result.baseCommit}..HEAD")
    verdict = codex_exec_review(diff_text) or reviewer_agent_review(diff_text)
    review_count = 0
    MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3
    while verdict == "REQUEST_CHANGES" and review_count < MAX_REVIEWS:
        previous_commit = latest_commit
        if backend == "cursor":
            companion_output = bash("bash \"${HARNESS_PLUGIN_ROOT}/scripts/cursor-companion.sh\" task --write --workspace {worker_result.worktreePath} \"Review findings:\n{issues}\n\nFix the findings and commit the result.\"")
        else:
            companion_state_file = "{worker_result.worktreePath}/.claude/state/codex-primary-environment.json"
            companion_output = bash("CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE={companion_state_file} bash \"${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh\" task --write -C {worker_result.worktreePath} \"Review findings:\n{issues}\n\nFix the findings and commit the result.\"")
        latest_commit = git("-C", worker_result.worktreePath, "rev-parse", "HEAD")
        if backend == "cursor" and git("-C", worker_result.worktreePath, "status", "--porcelain") != "":
            git("-C", worker_result.worktreePath, "add", "-A")
            git("-C", worker_result.worktreePath, "-c", "user.name=cursor-composer", "-c", "user.email=cursor-composer@local", "commit", "--no-verify", "-m", "cursor: review fix")
            latest_commit = git("-C", worker_result.worktreePath, "rev-parse", "HEAD")
        if latest_commit == previous_commit:
            raise EscalationError("{backend} companion retry produced no new commit")
        worker_result.commit = latest_commit
        worker_result.summary = companion_output
        diff_text = git("-C", worker_result.worktreePath, "diff", "{worker_result.baseCommit}..HEAD")
        verdict = codex_exec_review(diff_text) or reviewer_agent_review(diff_text)
        review_count++
    if verdict == "APPROVE":
        git cherry-pick --no-commit {worker_result.baseCommit}..{worker_result.commit}

Parallel applies this resolver path per task. backend=cursor / codex , do not use native Worker spawn; create an isolated companion worktree for each task and normalize it to companion-result.v1 before entering the range review / cherry-pick loop dedicated to non-Claude companions.

Solo mode (auto-selected when there is 1 item)

From reading Plans.md to cc:完了 [hash] , the complete 1–17 step version is see references/execution-modes.md#solo-detailed-steps . Key points: Authoritative spec preflight to check for the presence of the spec SSOT, spec_path is passed to the Worker/Reviewer. Apply plan-time pre-verification and reduce to zero AskUserQuestion caused by declared items during work. Proceed in the order of TDD Red → sprint-contract → implementation → review loop → commit → cc:完了 .

Parallel mode (auto-selected when there are 2–3 items / `--parallel N` to force)

[P] Execute tasks marked with in parallel using N workers. --parallel N If explicitly specified with , use this mode regardless of the number of tasks.

N is the desired value, and the actual concurrency is determined by CC(133.9, primary source confirmed). CC limits concurrently running subagents to a default of 20 (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, 2.1.217), and anything beyond that simply enters the queue rather than causing an error. Nested spawns default to a depth of 3 (CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH, relaxed from 1 → 3 in 2.1.219), so Lead (0) → Worker (1) → advisor called by Worker (2) fits. Hierarchies exceeding this are silently rejected unless raised via env. The Harness side does not explicitly set either env and follows CC defaults. If writes to the same file conflict, separate them with git worktree. Each task's implementation executor follows the Backend-resolved executor path. --parallel N --cursor、--backend cursor, or if the resolver output is cursor , then even in Parallel, use a per-task Cursor companion worktree instead of native Worker spawn.

Codex mode (`--codex` only when explicitly specified)

Delegate tasks to Codex CLI via the official plugin codex-plugin-cc companion.

# タスク委託（書き込み可能・worktree 分離）
BASE_REF="$(git rev-parse HEAD)"
WT_ID="codex-$(date +%Y%m%d-%H%M%S)-$$"
WORKTREE_PATH=".claude/worktrees/${WT_ID}"
git worktree add -b "codex-work/${WT_ID}" "$WORKTREE_PATH" "$BASE_REF"
CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE="$WORKTREE_PATH/.claude/state/codex-primary-environment.json" \
  bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write -C "$WORKTREE_PATH" \
  "タスク内容。完了前にこの worktree で exactly one git commit を作成してください。"

# stdin 経由（大きなプロンプト向け）
CODEX_PROMPT=$(mktemp /tmp/codex-prompt-XXXXXX.md)
# タスク内容を書き出し
cat "$CODEX_PROMPT" | CODEX_MODEL_TIER=worker HARNESS_CODEX_PRIMARY_ENV_STATE_FILE="$WORKTREE_PATH/.claude/state/codex-primary-environment.json" \
  bash "${HARNESS_PLUGIN_ROOT}/scripts/codex-companion.sh" task --write -C "$WORKTREE_PATH"
rm -f "$CODEX_PROMPT"

# Lead review 後に承認されたら range を取り込む
git -C "$WORKTREE_PATH" diff "$BASE_REF..HEAD"
WORKTREE_HEAD="$(git -C "$WORKTREE_PATH" rev-parse HEAD)"
git cherry-pick --no-commit "$BASE_REF..$WORKTREE_HEAD"

The companion communicates with Codex via the App Server Protocol and provides job management, thread resume, and structured output. Verify the results, and if they do not meet quality standards, fix them yourself.

Cursor mode (adapter candidate, not auto-selected)

In Cursor host, .cursor/AGENTS.md と .cursor-plugin/plugin.json が bootstrap route。Cursor は candidate remains as is — supported claims are prohibited.

Solo / Parallel: Task tool or .cursor/agents/worker.md subagent
Breezing: Worker parallelism is limited to non-overlapping file groups; Reviewer / cherry-pick / Advisor remain serial as in core
Multitask / background agents: smoke target only. Do not claim Claude Agent Teams parity

bash scripts/model-routing.sh --host cursor --role worker --format json
bash tests/test-cursor-adapter-candidate.sh

Explicit Task/subagent model takes precedence over the routed default.

Breezing mode (auto-selected when there are 4 or more items / `--breezing` to force)

Run as a team with separation of roles: Lead / Worker / Advisor / Reviewer. In Codex, assume spawn_agent, wait, send_input, resume_agent, close_agent -based native subagent orchestration. In Cursor, map to Task/subagent/background agents, but leave the serial responsibilities of review/cherry-pick on the core side (adapter smoke target).

Permission policy: the current shipped default is bypassPermissions。--auto-mode is an opt-in rollout flag for compatible parent sessions. permissions.defaultMode や agent frontmatter の permissionMode Do not write an undocumented autoMode value in .

Lead (this agent)
├── Worker (task-worker agent) — 実装担当
├── Advisor (claude-code-harness:advisor) — 方針助言
└── Reviewer (code-reviewer agent) — レビュー担当

Phase A (preparation: reading Plans.md, dependency resolution, applying plan-preapproval, effort scoring, generating sprint-contract) → Phase B (each task: Worker spawn → Advisor when needed → self_review gate → review loop → cherry-pick to trunk on APPROVE) → Phase C (integration: commit log aggregation, rich completion report, final Plans.md check), a 3-stage structure. The full-version pseudocode (including the sequential steps B-1 through B-7) is references/execution-modes.md#breezing-phase-detail see.

Active task scope

Before the preapproval preflight of each task, the target worktree's .claude/state/active-task.json へ {"phase":"<phase>","task":"<task>"} is written atomically. The Go guardrail reads this file as the source of truth for the current scope. At task end, delete it on any path: success, failure, or stop. The environment variable HARNESS_ACTIVE_PHASE / HARNESS_ACTIVE_TASK is limited to fallback on hosts where the state file does not exist.

In Parallel / Breezing, write to the worktree of each task. Do not share the same worktree's active-task.json across multiple tasks.

Work Mode Lifecycle (`bin/harness work-mode`)

Skipping the confirmation for R04 (writing outside the project root) / R05 (dangerous rm) depends on ctx.WorkMode , but both paths that set this were in a state where they did not take effect: HARNESS_WORK_MODE / ULTRAWORK_MODE env has no means of being set from a skill / hook, and state.SetWorkState（SQLite work_states line) also had no callers at all. bin/harness work-mode <on|off|status> becomes the only entry point that writes this SQLite path.

Lead は At run start(before Phase A starts; in solo execution, before the first implementation action), bin/harness work-mode on is executed.--codex In run, bin/harness work-mode on --codex(R07 = Lead's direct Write/Edit prohibition is simultaneously in effect)
Lead は At run end, on all paths — success, failure, or interruption — execute bin/harness work-mode off . active-task.json — "clean up at exit on any path"
It is per run (once across Phases A–C), and is not a per-task write likeactive-task.json . Do not individually turn it on/off in child worktrees
The resolution order for the session ID is the --session-id flag → HARNESS_SESSION_ID env (the real session_id that the SessionStart hook exports via CLAUDE_ENV_FILE) → .claude/state/last-session-id.json(within 2 hours of freshness). The old .claude/state/session.json internal ID does not match the ID the guardrail receives, so it isnot accepted. If it cannot be resolved, work-mode exits non-zero and outputs the reason to stderr (it does not silently succeed)

Advisor Protocol (common to all modes)

The Advisor is neither an "implementer" nor a "reviewer." It steps in only when you are unsure, as an adviser for the executor to decide the next step.

The Worker does not add generic subagents, and returns advisor-request.v1 only when necessary
The Lead calls the advisor only once
Advisor は PLAN / CORRECTION / STOP returns one of
Lead uses that advice (advisor-response.v1) is returned to the same Worker to continue
The Reviewer looks only at the final artifact. Do not output APPROVE / REQUEST_CHANGES in the advisor's response

In solo execution, the parent session itself also serves as Lead (implements on its own, consults the advisor on its own, and finally routes to an independent review). The consultation conditions and budget are the same as breezing, and the maximum number of consultations per task is 3.STOP stops on the spot and is escalated to user judgment. The review artifact gate is not skipped.

Sprint Contract と PR Closeout

sprint-contract is a contract file that makes "what will make this task pass" machine-readable (default: .claude/state/contracts/<task-id>.sprint-contract.json、generate-sprint-contract.js generated). runtime_validation 's LSP/AST workflow policy:

If you grep the same symbol twice in the same session, switch to harness_ast_search.
For a bugfix where homologous implementations appear across multiple modules, run harness_ast_search to find all implementations before editing.
Only when changed files include .ts or .tsx, the DoD requires zero new harness_lsp_diagnostics errors; if the harness MCP is not connected or the changed file types are not eligible, treat diagnostics as not-configured and non-blocking.

spec_path / lane / stage / research_evidence / tdd_red_log / review_artifact / pr_closeout 's field specification and the PR title/body assembly after review APPROVE (harness-pr-closeout.sh, default dry-run) details are see references/sprint-contract.md .

Handling CI failures

If CI fails:

Check the logs and identify the error
Apply a fix
If it fails 3 times for the same cause, stop the auto-fix loop
Escalate with the failure logs, attempted fixes, and remaining issues summarized

Automatic re-ticketing of failed tasks

If tests/CI fail after task completion, a draft fix task is automatically generated and, after approval, reflected in Plans.md. For details on trigger conditions, generation format, and approval command (approve fix <task_id> / reject fix <task_id>), see references/failure-reticketing.md .

Review loop

A quality verification stage that runs automatically after implementation is complete.Common to all modes(Solo / Parallel / Breezing) and is applied uniformly. For the full version of the priority order (Codex exec → internal Reviewer agent fallback), the APPROVE / REQUEST_CHANGES criteria (only critical/major affect the verdict), the verdict mapping, and the fix loop (MAX_REVIEWS = read_contract(contract_path, ".review.max_iterations") or 3), see references/review-loop.md .

Completion Report Output Contract

Before rendering a Solo, forced single-task Parallel, or Breezing completion report:

Resolve the active locale with the shared get_harness_locale function from ${HARNESS_PLUGIN_ROOT}/scripts/config-utils.sh. Pass an explicit session or user language as its optional argument; otherwise keep the resolver priority of project i18n.language, CLAUDE_CODE_HARNESS_LANG, then default en.
Unset, invalid, and resolved en render the English template.
Only resolved ja renders the Japanese template.
Japanese input alone does not select the Japanese template.
Read references/completion-report.md and render exactly one template for the selected mode and locale.
Keep machine-readable status and review values in English, and never mix English and Japanese labels in one report.

Progress visualization (for non-engineers)

During task execution, harness-progress compiles the progress counts and drift alerts into a single HTML page. Because it is automatically regenerated by a PostToolUse hook, the requester can view the latest progress board without learning how to invoke it (posttool-progress-regen.sh is regenerated at most once per minute).

Related skills

harness-plan — Plan the tasks to execute
harness-sync — Synchronize implementation and Plans.md
harness-review — Review the implementation
harness-release — version bump/release
harness-progress — Progress board HTML (for non-engineers, automatically regenerated during execution)