octopus-workflow/core/skills/_shared/review-reviewer-prompt.md

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).