refactor: Switch review-resolve to per-specialist batched verification

Step 1 returns by_assignee instead of writing findings.json; Step 2 launches
one Sub per specialist that batch-verifies its assigned ids. review-rounds
SKILL and the sequencer program are updated to match.

Also trim redundant preambles and chat-context-dependent wording from the
review-resolve SKILL and sequencer prompts per .claude/rules/prompt.md.

Author: hanatyan128

.claude/sequencer/programs/review_rounds.py

@@ -193,10 +193,8 @@
 _TPL_REVIEW_INIT = textwrap.dedent("""\
     [Round 1/{max_rounds} Step 1: parallel-review (with initialization)]
     Skill: {skill}
-    Run parallel-review against the branch diff for {base_clause}. Following the
-    skill body, reviewers Write to individual files and an aggregator sub-agent
-    consolidates them. The orchestrator (you) does not load review-finding bodies
-    into context.
+    Run parallel-review against the branch diff for {base_clause}. The
+    orchestrator (you) does not load review-finding bodies into context.
 
     Initialization:
     - Obtain the current branch name: git branch --show-current
@@ -228,10 +226,8 @@
 _TPL_REVIEW = textwrap.dedent("""\
     [Round {round_num}/{max_rounds} Step 1: parallel-review]
     Skill: {skill}
-    Run parallel-review against the branch diff for {base_clause}. Following the
-    skill body, reviewers Write to individual files and an aggregator sub-agent
-    consolidates them. The orchestrator (you) does not load review-finding bodies
-    into context.
+    Run parallel-review against the branch diff for {base_clause}. The
+    orchestrator (you) does not load review-finding bodies into context.
 
     File-naming rules:
     - Output path: {output_base}/{branch_dir}/review-round{round_num}.md
@@ -261,11 +257,9 @@
 _TPL_RESPOND = textwrap.dedent("""\
     [Round {round_num}/{max_rounds} Step 2: review-respond]
     Skill: {skill}
-    Respond to the findings in review document {doc_path}. Following the skill
-    body, delegate parsing / triage / estimate / fix / format verification /
-    build verification / aggregation to sub-agents. The orchestrator (you) only
-    orchestrates the retry loop and does not load verdict bodies or finding
-    bodies into context.
+    Respond to the findings in review document {doc_path}. The orchestrator
+    (you) only orchestrates the retry loop and does not load verdict bodies or
+    finding bodies into context.
     {confirm_clause}
     {commit_clause}
 
@@ -303,10 +297,8 @@
 _TPL_RESOLVE = textwrap.dedent("""\
     [Round {round_num}/{max_rounds} Step 3: review-resolve]
     Skill: {skill}
-    Verify the resolution status of review document {doc_path}. Following the
-    skill body, delegate parsing / per-finding verification / aggregation to
-    sub-agents. The orchestrator (you) does not load verification bodies into
-    context.
+    Verify the resolution status of review document {doc_path}. The
+    orchestrator (you) does not load verification bodies into context.
 
     Reporting format (JSON):
     {{
@@ -318,8 +310,7 @@
     - unresolved_count: aggregator sub-agent's return value feedback_count
       (number of findings whose Verification still reads 💬 Feedback).
     - resolved_count: aggregator sub-agent's return value resolved_count.
-    - feedback_count: synonymous with unresolved_count (both included for
-      backward compatibility).
+    - feedback_count: synonymous with unresolved_count.
     - summary_line: 1-line summary for user notification.\
 """)
 
@@ -349,7 +340,7 @@
         current_meta.verification into account.
 
     Step 4.{attempt}.4 Feedback verify
-        Re-run {resolve_skill} (parsing Sub → verification Sub group → aggregator Sub).
+        Re-run {resolve_skill}.
 
     Reporting format (JSON):
     {{

.claude/skills/review-resolve/SKILL.md

@@ -34,7 +34,7 @@ Review documents are generated by parallel-review and contain metadata markers a
 ---
 ```
 
-The current state of each finding is determined from **the fields present between the markers**:
+The current state of each finding is determined from the fields present between the markers:
 
 - Markers are empty → not yet triaged.
 - `Triage: 🔧 Will Fix` only → triaged, estimate not yet completed.
@@ -62,7 +62,7 @@ For common prohibitions, see `.claude/rules/sub-agent.md`. The leader appends th
 
 ## Internal Processing (Intermediate Files)
 
-Each finding's verification verdict is written to an intermediate file, and the aggregator sub-agent consolidates them. The leader (you) does not load verification bodies into context.
+The leader (you) does not load verification bodies into context.
 
 ### Working Directory
 
@@ -75,7 +75,7 @@ The leader creates `{tmp_dir}` with `mkdir -p {tmp_dir}/verifications` at the st
 
 ### events.jsonl
 
-Final markdown reflection still uses **`{basename}.events.jsonl` in the same directory as the markdown** (e.g., `review-round1.md` → `review-round1.events.jsonl`; referred to as `{events_path}` below). The **aggregator sub-agent** generates events.jsonl in one shot from the files under `{tmp_dir}/verifications/` (Step 4). Format:
+events.jsonl is `{basename}.events.jsonl` in the same directory as the markdown (e.g., `review-round1.md` → `review-round1.events.jsonl`; referred to as `{events_path}` below). Format:
 
 ```jsonl
 {"id":"C-1","field":"verification","value":"✅ Verified — Null check fix is correct"}
@@ -88,50 +88,61 @@ Use the **Write tool** for the file. Bash cat heredoc is unusable because apostr
 
 ## Step 1 — Parse (Delegated to Parsing Sub-Agent)
 
-Launch the parsing sub-agent to extract findings. The leader (you) receives only the result file path, the count, and the dispatch `items`; do not load the review document body into context.
-Use the same prompt template as review-respond Step 1 to generate `{tmp_dir}/findings.json` (see review-respond § Step 1).
+Launch the parsing sub-agent to extract findings and assign verification specialists.
+
+Example prompt:
 
-Return value (the leader receives this JSON):
-```
-{
-  "path": "{tmp_dir}/findings.json",
-  "total": <int>,
-  "by_stage": {...},
-  "items": [{"id": "C-1", "stage": "fixed_skip"}, ...]
-}
 ```
+Read review document {document_path} and extract id / stage / verification assignee for each finding (no file output).
 
-Each element of `items` (only `id` and `stage`) is used as the dispatch list for launching verification sub-agents in the next step.
+Extraction targets: Critical / Major / Minor (skip Info).
 
-## Step 2 — Verify Each Finding (Delegated in Parallel to Verification Sub-Agents)
+stage classification (based on the latest values in current_meta):
+- markers empty → pending_triage
+- triage: 🔧 Will Fix, no estimate → pending_estimate
+- estimate: ▶️ Maintain or 🚧 Alternative, no status → pending_fix
+- verification last value is 💬 Feedback → feedback
+- triage: 🚫 Won't Fix → wontfix_skip
+- estimate: 🔻 Downgrade → downgrade_skip
+- status: 🟢 Fixed, no verification or last value is ✅ Verified → fixed_skip
 
-Loop over the `items` array received in Step 1 and launch a verification sub-agent in parallel for each `id` via the Agent tool. Findings have no inter-dependencies, so parallel launch is allowed. Each sub-agent looks up its id in `{tmp_dir}/findings.json` to obtain the trailing metadata, and Writes the result to `{tmp_dir}/verifications/{id}.json`.
+Verification assignee determination:
+- If the Triage line includes "(assignee: {specialist})", use that specialist.
+- If no assignee is present, pick one specialist from the finding's Reviewers, preferring required reviewers (cpp-sensei / qt-sensei / obs-sensei / network-sensei). If none of the required reviewers are listed, use the first Reviewer.
 
-Launch procedure:
+Return value: {total, by_stage: {<stage>: <int>}, by_assignee: [{assignee, ids: [id, ...]}]}
+```
 
-1. Launch a verification sub-agent in parallel for each element of `items` via the Agent tool. Example prompt:
+## Step 2 — Verify Each Finding (Delegated in Parallel per Specialist)
+
+Loop over Step 1's `by_assignee` and launch a verification sub-agent in parallel for each `{assignee, ids}` via `Agent(subagent_type=assignee, prompt=...)` (the agent definition's persona and specialty perspective load automatically). Each specialist processes all assigned ids in a single launch, writing one `{tmp_dir}/verifications/{id}.json` per id.
+
+Example prompt (do not include persona):
 
 ```
-Verify the resolution of finding {finding-id} (verification and JSON Write only).
+Verify the assigned findings {ids} in a single batch.
 
-Input: the item with id == "{finding-id}" in {tmp_dir}/findings.json (read trailing field from current_meta).
-Output: {tmp_dir}/verifications/{finding-id}.json
+Input: review document {document_path} (Read to obtain severity / location / description / trailing metadata for each id).
 
-Decision: based on the trailing field (final value of triage / estimate / status / verification), apply the rules in this SKILL § "Step 2 § Verification Logic" to determine Resolved / Feedback / Unresolved.
+For each id:
+1. Based on the trailing field (final value of triage / estimate / status / verification), apply the rules in this SKILL § "Step 2 § Verification Logic" to determine Resolved / Feedback / Unresolved.
+2. Write to {tmp_dir}/verifications/{id}.json.
 
-{tmp_dir}/verifications/{finding-id}.json: {id, outcome (Resolved | Feedback | Unresolved), reason (1–3 sentences), memo_value, feedback_detail}
+{tmp_dir}/verifications/{id}.json: {id, severity, trailing_field, outcome (Resolved | Feedback | Unresolved), reason (1–3 sentences), memo_value, feedback_detail}
+
+trailing_field: the literal last metadata line inside the markers (e.g., "Status: 🟢 Fixed" / "Triage: 🚫 Won't Fix" / "(empty)")
 
 memo_value:
 - Resolved: "✅ Verified — {verification result}"
 - Feedback: "💬 Feedback — {what is missing and what is needed for full resolution}"
 - Unresolved: ""
 
-feedback_detail (include only when outcome == Feedback): {current_state, issue, suggestion}
+feedback_detail (include only when outcome == Feedback): {description, current_state, issue, suggestion}
 
-Return value: {path, outcome}
+Return value: [{id, outcome}, ...]
 ```
 
-2. Receive the return values (`{path, outcome}` only) from all verification agents. **Do not load verification bodies into context.**
+**Do not load verification bodies into context** (return values are `[{id, outcome}, ...]` only).
 
 ### Verification Logic
 
@@ -175,7 +186,7 @@ Apply in each of `Status: 🟢 Fixed` / `Triage: 🚫 Won't Fix` / `Estimate: 
 
 ## Step 3 — Verification Report and Reflection (Delegated to Aggregator Sub-Agent)
 
-The aggregator sub-agent consolidates the verification results under `{tmp_dir}/verifications/` and performs verification-report generation, events.jsonl write, and `render-review.py` execution in one shot. The leader (you) does not load verification bodies into context.
+The leader (you) does not load verification bodies into context.
 
 Launch procedure:
 
@@ -185,8 +196,7 @@ Launch procedure:
 You are responsible for review-verification aggregation. Generate the verification report and events.jsonl from the intermediate files, and reflect them into the markdown.
 
 Input:
-- {tmp_dir}/verifications/ — verification result for each finding
-- {tmp_dir}/findings.json — severity / trailing field reference
+- {tmp_dir}/verifications/ — verification result for each finding (includes severity / trailing_field / feedback_detail)
 - Target markdown: {document_path}
 
 Output:
@@ -196,15 +206,15 @@ Output:
 
 What to do:
 
-1. Read {tmp_dir}/verifications/*.json, cross-reference with findings.json, and Write the verification report to {tmp_dir}/resolve-summary.md. Format:
+1. Read {tmp_dir}/verifications/*.json and Write the verification report to {tmp_dir}/resolve-summary.md. Format:
    - Heading: "# Review Verification Report"
    - Meta info: "Review document: {document_path}", "Verification date: YYYY-MM-DD" (bold)
    - Under "## Verification Results", three tables:
      - "### Resolved": # / Severity / Trailing field / Verdict (outcome == Resolved)
      - "### Feedback Required": # / Severity / Trailing field / Issue (outcome == Feedback)
      - "### Unresolved": # / Severity / Trailing field / Note (outcome == Unresolved)
    - "## Summary": findings verified / Resolved / Feedback required / Unresolved as a bullet list
-   - "## Feedback Details": for each outcome == Feedback finding, write "### {finding-id} — Feedback", "Original finding", "Trailing field", "Actual state (feedback_detail.current_state)", "Issue (feedback_detail.issue)", "Suggestion (feedback_detail.suggestion)"; separate entries with ---
+   - "## Feedback Details": for each outcome == Feedback finding, write "### {finding-id} — Feedback", "Original finding (feedback_detail.description)", "Trailing field", "Actual state (feedback_detail.current_state)", "Issue (feedback_detail.issue)", "Suggestion (feedback_detail.suggestion)"; separate entries with ---
 
 2. Write verification events to {events_path} as JSONL (one event per line). Format: {"id":"...","field":"verification","value":"<memo_value>"}. Do not write events for outcome == Unresolved.
 
@@ -214,14 +224,11 @@ What to do:
 Return value: {events_path, summary_path, summary_line (<=200 chars; e.g., "3 resolved, 1 feedback (M-1), 2 unresolved"), resolved_count, feedback_count, unresolved_count}
 ```
 
-2. The leader holds the return value (`{events_path, summary_path, summary_line, resolved_count, feedback_count, unresolved_count}`) in context.
-
-3. The leader removes `{tmp_dir}` in one shot:
+2. The leader removes `{tmp_dir}` in one shot:
    ```bash
    .claude/scripts/rm-tmp.sh {tmp_dir}
    ```
 
 ## Step 4 — Completion Report
 
-The leader prints the `summary_line` received from the aggregator sub-agent to the console.
-If a detailed report is needed, Read `summary_path` (`resolve-summary.md` while `{tmp_dir}` still exists). Usually the `summary_line` alone is sufficient.
+The leader prints the `summary_line` received from the aggregator sub-agent to the console. If a detailed report is needed, Read `summary_path` (`resolve-summary.md` while `{tmp_dir}` still exists).

.claude/skills/review-rounds/SKILL.md

@@ -40,14 +40,15 @@ Write the review document in the user's chat language.
 - **Most work, including aggregation and consolidation, is delegated to sub-agents** (one level of nesting is allowed):
   - Individual reviewers (Step 2.1) — launch cpp-sensei / qt-sensei / obs-sensei / network-sensei, etc. in parallel for individual reviews. Each reviewer Writes findings to a file; the return value is only the path and counts.
   - Aggregator sub-agent (Step 2.1) — Read the individual reviewer output files and consolidate them into the review document (parallel-review § Step 3).
-  - Parsing sub-agent (Steps 2.2 / 2.3 / 2.4) — Read the review document and Write `findings.json`. Subsequent sub-agents take this JSON as input (review-respond § Step 1 / review-resolve § Step 1).
+  - Parsing sub-agent (review-respond, Steps 2.2 / 2.4) — Read the review document and Write `findings.json`. Subsequent sub-agents take this JSON as input (review-respond § Step 1).
+  - Parsing sub-agent (review-resolve, Steps 2.3 / 2.4) — Read the review document and return verification assignments (by_assignee) (review-resolve § Step 1; no file output).
   - Triage sub-agent (Steps 2.2 / 2.4) — render verdicts in a separate context to avoid bias (review-respond § Step 2).
   - Individual estimates (Steps 2.2 / 2.4) — delegate each Will Fix in parallel to its assigned specialist sub-agent (read-only).
   - Estimate aggregator sub-agent (Steps 2.2 / 2.4) — generate a summary of individual estimate results (review-respond § Step 3).
   - Individual fixes (Steps 2.2 / 2.4) — delegate each finding to the appropriate specialist sub-agent.
   - Format & build verification sub-agent (Steps 2.2 / 2.4) — run clang-format / cmake-format + build once; on failure, analyze code and determine the responsible specialist (no fix; recommendation only).
   - Build-fix specialist sub-agent (Steps 2.2 / 2.4) — fix build errors as the specialist determined by the format & build verification sub-agent. The leader re-launches the format & build verification sub-agent afterwards (review-respond § Step 5).
-  - Verification sub-agent (Steps 2.3 / 2.4) — verify each finding in parallel (review-resolve § Step 2; read-only).
+  - Verification sub-agent (Steps 2.3 / 2.4) — launched in parallel per specialist; each batch-verifies its assigned findings (review-resolve § Step 2; read-only).
   - Aggregator sub-agent (Steps 2.2 / 2.3 / 2.4) — generate events.jsonl from intermediate files and run render-review.py (review-respond § Step 6 / review-resolve § Step 3).
   - Final-report aggregator sub-agent (Step 3) — generate the final report from all rounds' review documents.
 - **The orchestrator (you) directly handles only the following**:
@@ -75,8 +76,8 @@ Round 1 starts
   │     [format & build verification Sub] ⇄ [build-fix specialist Sub] loop (max 5, leader-controlled)
   │     [aggregator Sub] triage.json + estimates/*.json + statuses/*.json → events.jsonl → render-review.py
   ├─ 2.3 review-resolve
-  │     [parsing Sub] Reads round1.md → emits findings.json
-  │     [verification Sub group] verifies each finding in parallel → emits verifications/{id}.json
+  │     [parsing Sub] Reads round1.md → returns by_assignee (no file output)
+  │     [verification Sub group] launched per specialist; each batch-verifies its assigned findings → emits verifications/{id}.json
   │     [aggregator Sub] verifications/*.json → events.jsonl → render-review.py
   ├─ 2.4 Feedback re-fix loop (up to 3 iterations)
   │     [parsing Sub] → [triage Sub] → [estimate Sub group] → [fix Sub group]