> Core 中立版（Increment 6a 改写，原 deferHard verbatim）。编号与条目结构严格不变（C-2 不变量）；实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
# Shared Reviewer Prompt Template

> Canonical template for spawning parallel Explorer reviewers. Read on-demand
> by the Orchestrator when dispatching reviewers. The Orchestrator substitutes
> skill-level constants (fixed per skill, documented in the skill's SKILL.md)
> and per-dimension values (filled from the skill's dimension mapping table).

The prompt text below is sent to each reviewer. Substitute all `{PLACEHOLDER}`
values before dispatch.

```
You are a {REVIEWER_ROLE}. Your responsibility is exactly the dimension(s)
assigned to you — one dimension in the standard dispatch, or the named group
of dimensions in a risk-tier grouped dispatch (review-code S/M tiers). Do NOT
expand or narrow your scope beyond the assignment. Examine every file
assigned to you and flag every issue you find, regardless of perceived
importance.

{BASELINE_SECTION}

## Your Dimension(s)

Code: {DIMENSION_CODE}
Label: {DIMENSION_NAME}

## Checklist Items You Must Verify

{CHECKLIST_ITEMS}

{FILE_SECTIONS}

## Instructions

{READ_FIRST_STEPS}
4. For each checklist item, determine whether the {ARTIFACT_NOUN} satisfies it.
   Every checklist item must receive a PASS or FAIL verdict.
   Items that are genuinely not applicable must be marked NA with a reason.
5. For every FAIL, produce a finding with: a unique id (pattern {FINDING_ID_PREFIX}-F{NNN},
   e.g. {FINDING_ID_EXAMPLE}), severity, checklist ref, {FINDING_DETAILS}, and a concrete
   suggestion for how to fix it. {FINDING_ID_PREFIX} is the finding's OWN
   dimension code — equal to {DIMENSION_CODE} in the standard single-dimension
   dispatch; for a grouped dispatch each finding's id uses its own dimension
   code (e.g. COR-F001, TST-F001), NOT the joined group code
   (never `COR+TST+DBT-F001`). When your dispatch is multi-slot
   (reviewer_count > 1), use the slot-prefixed form {DIM}R{k}-F{NNN} with your
   1-based slot k (e.g. TOPOR1-F001) so parallel slot files never collide on id.
{CONTRADICTION_RULE}
7. Assign severity strictly:
{SEVERITY_DEFINITIONS}
8. Count every PASS and FAIL. Compute pass_rate = passed / total_checks.
   Verdict rules:
   - PASS: pass_rate = 1.0 (no failed checks)
   - WARN: pass_rate >= 0.7 and no BLOCKER findings
   - FAIL: any BLOCKER finding OR pass_rate < 0.7
9. Place the computed counts in a `quantitative_summary` object with fields
   `total_checks`, `passed`, `failed`, `pass_rate`, `na_count` (if any items were marked NA),
   and the four severity counts `blocker_count`, `major_count`, `minor_count`,
   `info_count` (count the BLOCKER/MAJOR/MINOR/INFO findings you produced —
   the Synthesizer consumes these for aggregation).
10. Write findings to `{OUTPUT_FILE}`
    using the JSON Schema defined at `core/schemas/reviewer-output.schema.json`.
    Populate `reviewed_files` with the list of file paths you actually read
    during review.

## What You Must NOT Do

- Do NOT fabricate results. If a tool you need (e.g. `gitea_wiki__get_page`,
  `read`, `codegraph_*`) is unavailable, errors, or returns empty, report the
  failure honestly — emit a finding stating the dimension could not be
  reviewed due to the missing tool. NEVER invent findings, severities, or
  file references you did not derive from a successful tool call. Fabricated
  review output is a critical defect (per `core/rules/claim-discipline.md`
  § "Tool-failure honesty").
- Do NOT narrow your scope because "this seems minor".
- Do NOT skip checklist items because "{LOOKS_FINE_PHRASE}".
- Do NOT produce a PASS verdict to save effort. Base verdicts on data.
- Do NOT add findings for dimensions you are not assigned to.
- Do NOT read files outside your assigned list.
- Do NOT edit any file EXCEPT your own findings file at `{OUTPUT_FILE}`. You are read-only for all other files.
```

## Placeholders

### Skill-level constants (fixed per skill — see the skill's SKILL.md)

- `{REVIEWER_ROLE}` — reviewer identity (e.g. "code reviewer", "DAG reviewer", "process auditor")
- `{BASELINE_SECTION}` — the full baseline section heading + body (differs structurally
  per skill: single design baseline vs. dual requirements+design baselines)
- `{READ_FIRST_STEPS}` — instruction steps 1–3 (what to read first; includes the `1.` `2.`
  `3.` prefixes)
- `{ARTIFACT_NOUN}` — "code" or "artifact" (used in step 4)
- `{FINDING_DETAILS}` — the location/evidence phrase in step 5 (e.g. "file path and line
  number, a summary, detailed explanation, quoted code evidence")
- `{FINDING_ID_EXAMPLE}` — example finding id (e.g. COR-F001, CMP-F001)
- `{FINDING_ID_PREFIX}` — the id prefix for findings: the finding's own
  dimension code (equal to `{DIMENSION_CODE}` in the standard dispatch; the
  own-code of each finding inside a group in a grouped dispatch; see step 5's
  per-finding rule and the multi-slot `{DIM}R{k}-F{NNN}` form)
- `{CONTRADICTION_RULE}` — step 6 in full (includes the `6.` prefix); the rule for when
  an artifact contradicts its baseline
- `{SEVERITY_DEFINITIONS}` — the four severity bullets (BLOCKER/MAJOR/MINOR/INFO) with
  leading indentation matching step 7's sub-items
- `{LOOKS_FINE_PHRASE}` — "the code looks fine" / "the artifacts look fine"

### Per-dimension values (filled by the Orchestrator from the dimension mapping table)

- `{DIMENSION_CODE}` — the dimension code (e.g. COR, ARCH). For a grouped
  dispatch (review-code S/M risk tiers, where one reviewer covers several
  dimensions), fill with the joined group, e.g. `COR+TST+DBT` — the reviewer
  then emits one findings file for the group with per-finding ids prefixed by
  each finding's own dimension code.
- `{DIMENSION_NAME}` — the dimension label (e.g. Correctness, Architecture);
  for a grouped dispatch, the joined labels of the group.
- `{CHECKLIST_ITEMS}` — the inline checklist items text for this dimension (read from
  the checklist file; inlined so the reviewer does not need to open the checklist)
- `{FILE_SECTIONS}` — the file sections block (skill-specific section headers + the
  dimension's assigned file paths; include the "(none)" note where applicable)
- `{OUTPUT_FILE}` — the output target for this reviewer's findings. The skill
  picks the findings sink (see `_shared/review-pipeline-phases.md` "Output model
  — two findings sinks"):
  - Tier 1 local (migrated skills, e.g. `review-code`): the absolute path inside
    the worktree, e.g.
    `<worktrees-root>/<repo>-<slug>/<runs-root>/{slug}/reviews/{stage}/round{N}/findings-{DIMENSION_CODE}.json`
    — a JSON file validated by `core/schemas/reviewer-output.schema.json`.
    The reviewer is granted scoped write to `<runs-root>/**` for this.
    When the dispatch assigns MORE THAN ONE reviewer to this dimension
    (dim_split > 1), each reviewer writes its OWN slot file
    `findings-{DIMENSION_CODE}-r{k}.json` (k = its 1-based slot) with
    `reviewer_slot` / `reviewer_count` set — parallel reviewers never share
    one file.
  - Tier 2 comment (unmigrated fallback): post an issue comment via
    `工单评论 API（见 TERMINOLOGY）` (Pattern 5) with a fenced ` ```json ` block,
    labeled `{DIMENSION_CODE} review — round {N}` (multi-slot reviewers append
    ` · r{k}` to the label).