harness-accept

harness-accept

A skill that presents the acceptance decision (ship / wait / reject) for completed implementation tasks as a single HTML page for non-engineer requesters and producers. Use at the requester's cognitive load peak (3), the acceptance decision stage.

Phase 65.1.x (harness-plan-brief) as a paired structure, and retrieves the acceptance_criteria approved in the Plan Brief on the read side for evaluation.

Quick Reference

「Create an Acceptance Demo" → this skill
「Want to make an acceptance decision" → this skill
「ship/wait/reject determination" → this skill

Responsibility boundaries

Scope	This skill's responsibility
Search	Current project only (`project: <current>`, `strict_project: true` must be specified)
cross-project	do not (from Phase 65.3 onward, `--cross-project-group <name>` flag opt-in release)
Plan Brief integration	`user_request_hash` as the join key `personal-preference.v1` (Phase 65.1.4) を read
Write	not done (memory write after Acceptance approval is the responsibility of `accept-record-decision.sh` )
recommendation calculation	0.8 / 0.5 threshold determination by the ratio of verified / all criteria. The logic is calculated immediately before `scripts/render-html.sh` .

Input

Argument [task-description] pass the user's request to (use the same wording as at Plan Brief time). If there is no argument, receive it interactively.

Output

Output	path	Format
Acceptance Demo HTML	`.claude/state/views/accept-<timestamp>.html`	HTML that can be opened standalone (no server, no JS framework)
Acceptance context JSON	`.claude/state/views/accept-<timestamp>.context.json`	`acceptance-context.v1` schema

Schema: `acceptance-context.v1`

{
  "schema": "acceptance-context.v1",
  "user_request": "string",
  "user_request_hash": "sha256 hex (Plan Brief 側の personal-preference.v1 と join)",
  "demo_artifacts": [
    { "kind": "video|screenshot|text", "path": "string" }
  ],
  "verified_criteria": [
    { "name": "string", "passed": true, "evidence": "string" }
  ],
  "tdd_verified": "yes|no|not-required|skip:<reason>",
  "unverified_caveats": ["string"],
  "past_issue_patterns": [
    { "pattern_id": "P5", "title": "string", "verified_in_current_task": true }
  ],
  "recommendation": "ship|wait|reject",
  "recommendation_evidence": ["string"],
  "project": "string",
  "generated_at": "ISO8601"
}

For the complete schema, refer to schemas/acceptance-context.v1.schema.json .

Recommendation calculation logic

verified_count    = count of verified_criteria where passed=true
total_criteria    = count of verified_criteria
ratio             = verified_count / total_criteria  (total=0 のときは 0)

  ratio >= 0.8 → "ship"
  ratio >= 0.5 → "wait"
  ratio <  0.5 → "reject"
  total = 0    → "reject" (criteria 0 件は判定不能、安全側 reject)

Leave the evaluation basis as literal numeric values in recommendation_evidence . Example: "verified 4 件 / 全 5 件 (80%) → ship 閾値以上"

Execution Flow

When the skill starts, Claude operates according to the following procedure.

Step 1: Resolve project name and user_request_hash

PROJECT_NAME="$(basename "$(git rev-parse --show-toplevel)")"
USER_REQUEST_HASH="$(printf '%s' "$USER_REQUEST" | sha256sum | awk '{print $1}')"

PROJECT_NAME If is empty (outside git), use current as the default.

Step 2: harness-mem を project-only search with and retrieve the Plan Brief side record (default)

If the argument is --cross-project-group <name> flag がnotcase (default behavior):

mcp__harness__harness_mem_search Call with the following parameters:

project: <PROJECT_NAME>
strict_project: true
tags: ["personal-preference", "plan-brief-approval"]
limit: 10

Important: project The parameter isRequired。strict_project: true specify and cross-project searchmust never be performed。

Filter the retrieved records by data.user_request_hash == <USER_REQUEST_HASH> and select the single newest one. This holds the approved content at Plan Brief time (chosen_option / acceptance_criteria, etc.).

Step 2 (alt): cross-project search (Phase 65.3.5 opt-in)

Only if the argument is --cross-project-group <name> flag がthere is, retrieve similar plan-brief-approval / acceptance-decision history from other projects in the cross-cutting group (D43 Option α):

MEMBERS_JSON="$(bash scripts/load-cross-project-groups.sh --group "<name>" 2>/dev/null)" || {
  echo "ERROR: cross-project group not found: <name>" >&2
  exit 1
}

MEMBERS_JSON が [] In the case of , fall back to the default single project search.

MEMBERS_JSON If is non-empty, issue one MCP search per member project:

for each project in MEMBERS_JSON:
  mcp__harness__harness_mem_search(
    project: <member>,
    strict_project: true,
    tags: ["personal-preference", "plan-brief-approval"],
    limit: 10
  )

Merge the results on the client side and filter bydata.user_request_hash == <USER_REQUEST_HASH> . Hash matches are basically from the same user request, so duplication across multiple projects is rare, but dedupe by id just in case.

If cross-project-derived records are adopted, there is a possibility that chosen_option / acceptance_criteria from past other cases may be mixed in, so when outputting HTML, always use the --with-redaction flag to do:

bash scripts/render-html.sh --template accept ... --with-redaction

For details, see .claude/rules/cross-repo-handoff.md "Phase 65.3 Implementation Decisions (D43)".

Step 3: Retrieve past problem patterns (Phase 65.2.2 delegation)

bash scripts/accept-past-issues.sh --project "$PROJECT_NAME" --task "$USER_REQUEST" > "$PAST_ISSUES_JSON"

This script semantically searches patterns.md (P1-P33) and past acceptance-context.v1 records, and returns up to 3 past-issue.v1 . Each with verified_in_current_task: bool attached.

Step 4: Assemble verified_criteria

For each acceptance_criteria item at Plan Brief time, evaluate the current task state. The user (or Claude) presents "verified evidence" and fills in theevidence string.

evidence If it is an empty string, a warning is displayed on the HTML (DoD c).

For tasks that require TDD, always include one line of TDD verified: yes|no in the Acceptance Demo. If TDD is not required or is skipped, display TDD verified: not-required or TDD verified: skip:<reason> . yes what can be done to .claude/state/tdd-red-log/<task-id>.jsonl Only when the Red evidence of , or literal failing test output can be confirmed.

Step 5: Compute recommendation

Follow the "Recommendation computation logic" above to decide ship / wait / reject.

Step 6: Generate HTML

scripts/render-html.sh (Phase 65.1.1) を templates/html/accept.html.template Call with:

bash scripts/render-html.sh \
  --template accept \
  --data "$CONTEXT_JSON" \
  --out "$HTML_OUT"

Step 7: Auto-open in browser

scripts/plan-brief-open.sh (introduced in Phase 65.1.2, the generic OS dispatcher) is reused:

bash scripts/plan-brief-open.sh "$HTML_OUT"

Note: Although the script name contains "plan-brief", it is actually an OS-specific browser open dispatcher and kind-neutral. Because it was introduced earlier in Phase 65.1.2, it has a historical name. It is also reused for other purposes such as Layer 3 (final scan immediately before HTML). BROWSER=true If the env for is set (CI environment), open only outputs the path with skip is done printf .

Step 8: Wait for user decision

Confirm whether to "adopt or override the ship / wait / reject recommendation". The memory write after the decision is the responsibility of a separate skill (accept-record-decision.sh, Phase 65.2.3).

Behavior on failure

Failure	Behavior
`mcp__harness__harness_mem_search` Unreachable	Display a warning, and continue with`verified_criteria` as an empty array (recommendation = reject)
Plan Brief side record not found	Emit a warning, and continue with`verified_criteria` as an empty array
`git rev-parse --show-toplevel` Failure	`PROJECT_NAME=current` Continue with
`accept-past-issues.sh` Failure	`past_issue_patterns: []` Continue with (best-effort)
`render-html.sh` Failure	Output error to stderr and exit 1

harness-plan-brief (Phase 65.1.2) — the planning-stage paired-structure skill. This skill handles the personal-preference.v1 を user_request_hash join and read with
scripts/accept-past-issues.sh at Plan Brief time (Phase 65.2.2) — past problem pattern retrieval (read side)
scripts/accept-record-decision.sh (Phase 65.2.3) — approval memory write (acceptance-decision.v1)
scripts/render-html.sh (Phase 65.1.1) — HTML template engine
scripts/plan-brief-open.sh (Phase 65.1.2) — generic OS browser dispatcher
harness-progress skill (Phase 65.4.1) — progress management skill (the middle of the 3 surfaces)

About this skill

Quick Reference

Responsibility boundaries

Input

Output

Schema: `acceptance-context.v1`

Recommendation calculation logic

Execution Flow

Step 1: Resolve project name and user_request_hash

Step 2: harness-mem を project-only search with and retrieve the Plan Brief side record (default)

Step 2 (alt): cross-project search (Phase 65.3.5 opt-in)

Step 3: Retrieve past problem patterns (Phase 65.2.2 delegation)

Step 4: Assemble verified_criteria

Step 5: Compute recommendation

Step 6: Generate HTML

Step 7: Auto-open in browser

Step 8: Wait for user decision

Behavior on failure

Related

harness-accept

About this skill

Quick Reference

Responsibility boundaries

Input

Output

Schema: acceptance-context.v1

Recommendation calculation logic

Execution Flow

Step 1: Resolve project name and user_request_hash

Step 2: harness-mem を project-only search with and retrieve the Plan Brief side record (default)

Step 2 (alt): cross-project search (Phase 65.3.5 opt-in)

Step 3: Retrieve past problem patterns (Phase 65.2.2 delegation)

Step 4: Assemble verified_criteria

Step 5: Compute recommendation

Step 6: Generate HTML

Step 7: Auto-open in browser

Step 8: Wait for user decision

Behavior on failure

Related

Schema: `acceptance-context.v1`