dsh-aris-panel 0.1.0

package/skills/skills-codex-gemini-review/auto-paper-improvement-loop/SKILL.md

@@ -0,0 +1,331 @@
+---
+name: "auto-paper-improvement-loop"
+description: "Autonomously improve a generated paper via Gemini review through gemini-review MCP → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper."
+---
+
+> Override for Codex users who want **Gemini**, not a second Codex agent, to act as the reviewer. Install this package **after** `skills/skills-codex/*`.
+
+# Auto Paper Improvement Loop: Review → Fix → Recompile
+
+> **Gemini overlay assurance:** `review_independence: cross-family` and `acceptance_status: accepted`.
+
+Autonomously improve the paper at: **$ARGUMENTS**
+
+## Context
+
+This skill is designed to run **after** Workflow 3 (`/paper-plan` → `/paper-figure` → `/paper-write` → `/paper-compile`). It takes a compiled paper and iteratively improves it through external LLM review.
+
+Unlike `/auto-review-loop` (which iterates on **research** — running experiments, collecting data, rewriting narrative), this skill iterates on **paper writing quality** — fixing theoretical inconsistencies, softening overclaims, adding missing content, and improving presentation.
+
+## Constants
+
+- **MAX_ROUNDS = 2** — Two rounds of review→fix→recompile. Empirically, Round 1 catches structural issues (4→6/10), Round 2 catches remaining presentation issues (6→7/10). Diminishing returns beyond 2 rounds for writing-only improvements.
+- **REVIEWER_MODEL = `gemini-review`** — Gemini reviewer invoked through the local `gemini-review` MCP bridge. Set `GEMINI_REVIEW_MODEL` if you need a specific Gemini model override.
+- **REVIEW_LOG = `PAPER_IMPROVEMENT_LOG.md`** — Cumulative log of all rounds, stored in paper directory.
+- **HUMAN_CHECKPOINT = false** — When `true`, pause after each round's review and present score + weaknesses to the user. The user can approve fixes, provide custom modification instructions, skip specific fixes, or stop early. When `false` (default), runs fully autonomously.
+
+> 💡 Override: `/auto-paper-improvement-loop "paper/" — human checkpoint: true`
+
+## Inputs
+
+1. **Compiled paper** — `paper/main.pdf` + LaTeX source files
+2. **All section `.tex` files** — concatenated for review prompt
+
+## State Persistence (Compact Recovery)
+
+If the context window fills up mid-loop, Codex auto-compacts. To recover, this skill writes `PAPER_IMPROVEMENT_STATE.json` after each round:
+
+```json
+{
+  "current_round": 1,
+  "thread_id": "019ce736-...",
+  "last_score": 6,
+  "status": "in_progress",
+  "timestamp": "2026-03-13T21:00:00"
+}
+```
+
+**On startup**: if `PAPER_IMPROVEMENT_STATE.json` exists with `"status": "in_progress"` AND `timestamp` is within 24 hours, read it + `PAPER_IMPROVEMENT_LOG.md` to recover context, then resume from the next round. Otherwise (file absent, `"status": "completed"`, or older than 24 hours), start fresh.
+
+**After each round**: overwrite the state file. **On completion**: set `"status": "completed"`.
+
+## Workflow
+
+### Step 0: Preserve Original
+
+```bash
+cp paper/main.pdf paper/main_round0_original.pdf
+```
+
+### Step 1: Collect Paper Text
+
+Concatenate all section files into a single text block for the review prompt:
+
+```bash
+# Collect all sections in order
+for f in paper/sections/*.tex; do
+    echo "% === $(basename $f) ==="
+    cat "$f"
+done > /tmp/paper_full_text.txt
+```
+
+### Step 2: Round 1 Review
+
+Send the full paper text to Gemini review:
+
+```
+mcp__gemini-review__review_start:
+  prompt: |
+    You are reviewing a [VENUE] paper. Please provide a detailed, structured review.
+
+    ## Full Paper Text:
+    [paste concatenated sections]
+
+    ## Review Instructions
+    Please act as a senior ML reviewer ([VENUE] level). Provide:
+    1. **Overall Score** (1-10, where 6 = weak accept, 7 = accept)
+    2. **Summary** (2-3 sentences)
+    3. **Strengths** (bullet list, ranked)
+    4. **Weaknesses** (bullet list, ranked: CRITICAL > MAJOR > MINOR)
+    5. **For each CRITICAL/MAJOR weakness**: A specific, actionable fix
+    6. **Missing References** (if any)
+    7. **Verdict**: Ready for submission? Yes / Almost / No
+
+    Focus on: theoretical rigor, claims vs evidence alignment, writing clarity,
+    self-containedness, notation consistency.
+```
+
+After this start call, immediately save the returned `jobId` and poll `mcp__gemini-review__review_status` with a bounded `waitSeconds` until `done=true`. Treat the completed status payload's `response` as the reviewer output, and save the completed `threadId` for any follow-up round.
+
+Save the returned `jobId`, poll `mcp__gemini-review__review_status` until `done=true`, then save the completed `threadId` for Round 2.
+
+### Step 2b: Human Checkpoint (if enabled)
+
+**Skip if `HUMAN_CHECKPOINT = false`.**
+
+Present the review results and wait for user input:
+
+```
+📋 Round 1 review complete.
+
+Score: X/10 — [verdict]
+Key weaknesses (by severity):
+1. [CRITICAL] ...
+2. [MAJOR] ...
+3. [MINOR] ...
+
+Reply "go" to implement all fixes, give custom instructions, "skip 2" to skip specific fixes, or "stop" to end.
+```
+
+Parse user response same as `/auto-review-loop`: approve / custom instructions / skip / stop.
+
+### Step 3: Implement Round 1 Fixes
+
+Parse the review and implement fixes by severity:
+
+**Priority order:**
+1. CRITICAL fixes (assumption mismatches, internal contradictions)
+2. MAJOR fixes (overclaims, missing content, notation issues)
+3. MINOR fixes (if time permits)
+
+**Common fix patterns:**
+
+| Issue | Fix Pattern |
+|-------|-------------|
+| Assumption-model mismatch | Rewrite assumption to match the model, add formal proposition bridging the gap |
+| Overclaims | Soften language: "validate" → "demonstrate practical relevance", "comparable" → "qualitatively competitive" |
+| Missing metrics | Add quantitative table with honest parameter counts and caveats |
+| Theorem not self-contained | Add "Interpretation" paragraph listing all dependencies |
+| Notation confusion | Rename conflicting symbols globally, add Notation paragraph |
+| Missing references | Add to `references.bib`, cite in appropriate locations |
+| Theory-practice gap | Explicitly frame theory as idealized; add synthetic validation subsection |
+
+### Step 4: Recompile Round 1
+
+```bash
+cd paper && latexmk -C && latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex
+cp main.pdf main_round1.pdf
+```
+
+Verify: 0 undefined references, 0 undefined citations.
+
+### Step 5: Round 2 Review
+
+Use `mcp__gemini-review__review_reply_start` with the saved completed `threadId`:
+
+```
+mcp__gemini-review__review_reply_start:
+  threadId: [saved from Round 1]
+  prompt: |
+    [Round 2 update]
+
+    Since your last review, we have implemented:
+    1. [Fix 1]: [description]
+    2. [Fix 2]: [description]
+    ...
+
+    Please re-score and re-assess. Same format:
+    Score, Summary, Strengths, Weaknesses, Actionable fixes, Verdict.
+```
+
+After this start call, immediately save the returned `jobId` and poll `mcp__gemini-review__review_status` with a bounded `waitSeconds` until `done=true`. Treat the completed status payload's `response` as the reviewer output, and save the completed `threadId` for any follow-up round.
+
+### Step 5b: Human Checkpoint (if enabled)
+
+**Skip if `HUMAN_CHECKPOINT = false`.** Same as Step 2b — present Round 2 review, wait for user input.
+
+### Step 6: Implement Round 2 Fixes
+
+Same process as Step 3. Typical Round 2 fixes:
+- Add controlled synthetic experiments validating theory
+- Further soften any remaining overclaims
+- Formalize informal arguments (e.g., truncation → formal proposition)
+- Strengthen limitations section
+
+### Step 7: Recompile Round 2
+
+```bash
+cd paper && latexmk -C && latexmk -pdf -interaction=nonstopmode -halt-on-error main.tex
+cp main.pdf main_round2.pdf
+```
+
+### Step 8: Format Check
+
+After the final recompilation, run a format compliance check:
+
+```bash
+# 1. Page count vs venue limit
+PAGES=$(pdfinfo paper/main.pdf | grep Pages | awk '{print $2}')
+echo "Pages: $PAGES (limit: 9 main body for ICLR/NeurIPS)"
+
+# 2. Overfull hbox warnings (content exceeding margins)
+OVERFULL=$(grep -c "Overfull" paper/main.log 2>/dev/null || echo 0)
+echo "Overfull hbox warnings: $OVERFULL"
+grep "Overfull" paper/main.log 2>/dev/null | head -10
+
+# 3. Underfull hbox warnings (loose spacing)
+UNDERFULL=$(grep -c "Underfull" paper/main.log 2>/dev/null || echo 0)
+echo "Underfull hbox warnings: $UNDERFULL"
+
+# 4. Bad boxes summary
+grep -c "badness" paper/main.log 2>/dev/null || echo "0 badness warnings"
+```
+
+**Auto-fix patterns:**
+
+| Issue | Fix |
+|-------|-----|
+| Overfull hbox in equation | Wrap in `\resizebox` or split with `\split`/`aligned` |
+| Overfull hbox in table | Reduce font (`\small`/`\footnotesize`) or use `\resizebox{\linewidth}{!}{...}` |
+| Overfull hbox in text | Rephrase sentence or add `\allowbreak` / `\-` hints |
+| Over page limit | Move content to appendix, compress tables, reduce figure sizes |
+| Underfull hbox (loose) | Rephrase for better line filling or add `\looseness=-1` |
+
+If any overfull hbox > 10pt is found, fix it and recompile before documenting.
+
+### Step 9: Document Results
+
+Create `PAPER_IMPROVEMENT_LOG.md` in the paper directory:
+
+```markdown
+# Paper Improvement Log
+
+## Score Progression
+
+| Round | Score | Verdict | Key Changes |
+|-------|-------|---------|-------------|
+| Round 0 (original) | X/10 | No/Almost/Yes | Baseline |
+| Round 1 | Y/10 | No/Almost/Yes | [summary of fixes] |
+| Round 2 | Z/10 | No/Almost/Yes | [summary of fixes] |
+
+## Round 1 Review & Fixes
+
+<details>
+<summary>Gemini Review (Round 1)</summary>
+
+[Full raw review text, verbatim]
+
+</details>
+
+### Fixes Implemented
+1. [Fix description]
+2. [Fix description]
+...
+
+## Round 2 Review & Fixes
+
+<details>
+<summary>Gemini Review (Round 2)</summary>
+
+[Full raw review text, verbatim]
+
+</details>
+
+### Fixes Implemented
+1. [Fix description]
+2. [Fix description]
+...
+
+## PDFs
+- `main_round0_original.pdf` — Original generated paper
+- `main_round1.pdf` — After Round 1 fixes
+- `main_round2.pdf` — Final version after Round 2 fixes
+```
+
+### Step 9: Summary
+
+Report to user:
+- Score progression table
+- Number of CRITICAL/MAJOR/MINOR issues fixed per round
+- Final page count
+- Remaining issues (if any)
+
+### Feishu Notification (if configured)
+
+After each round's review AND at final completion, check `~/.codex/feishu.json`:
+- **After each round**: Send `review_scored` — "Round N: X/10 — [key changes]"
+- **After final round**: Send `pipeline_done` — score progression table + final page count
+- If config absent or mode `"off"`: skip entirely (no-op)
+
+## Output
+
+```
+paper/
+├── main_round0_original.pdf    # Original
+├── main_round1.pdf             # After Round 1
+├── main_round2.pdf             # After Round 2 (final)
+├── main.pdf                    # = main_round2.pdf
+└── PAPER_IMPROVEMENT_LOG.md    # Full review log with scores
+```
+
+## Output Protocols
+
+> Follow these shared protocols for all output files:
+> - **[Output Versioning Protocol](../../shared-references/output-versioning.md)** — write timestamped file first, then copy to fixed name
+> - **[Output Manifest Protocol](../../shared-references/output-manifest.md)** — log every output to MANIFEST.md
+> - **[Output Language Protocol](../../shared-references/output-language.md)** — respect the project's language setting
+
+## Key Rules
+
+- **Large file handling**: If the Write tool fails due to file size, immediately retry using Bash (`cat << 'EOF' > file`) to write in chunks. Do NOT ask the user for permission — just do it silently.
+
+- **Preserve all PDF versions** — user needs to compare progression
+- **Save FULL raw review text** — do not summarize or truncate Gemini reviewer responses
+- **Use `mcp__gemini-review__review_reply_start` plus `mcp__gemini-review__review_status`** for Round 2 to maintain conversation context
+- **Always recompile after fixes** — verify 0 errors before proceeding
+- **Do not fabricate experimental results** — synthetic validation must describe methodology, not invent numbers
+- **Respect the paper's claims** — soften overclaims rather than adding unsupported new claims
+- **Global consistency** — when renaming notation or softening claims, check ALL files (abstract, intro, method, experiments, theory sections, conclusion, tables, figure captions)
+
+## Typical Score Progression
+
+Based on end-to-end testing on a real theory-paper run:
+
+| Round | Score | Key Improvements |
+|-------|-------|-----------------|
+| Round 0 | 4/10 (content) | Baseline: assumption-model mismatch, overclaims, notation issues |
+| Round 1 | 6/10 (content) | Fixed assumptions, softened claims, added interpretation, renamed notation |
+| Round 2 | 7/10 (content) | Added synthetic validation, formal truncation proposition, stronger limitations |
+| Round 3 | 5→8.5/10 (format) | Removed hero fig, appendix, compressed conclusion, fixed overfull hbox |
+
+**+4.5 points across 3 rounds** (2 content + 1 format) is typical for a well-structured but rough first draft. Final state at submission: clean overfull-hbox count and venue-format-compliant length.

package/skills/skills-codex-gemini-review/auto-review-loop/SKILL.md

@@ -0,0 +1,304 @@
+---
+name: "auto-review-loop"
+description: "Autonomous multi-round research review loop. Repeatedly reviews using Gemini via gemini-review MCP, implements fixes, and re-reviews until positive assessment or max rounds reached. Use when user says \"auto review loop\", \"review until it passes\", or wants autonomous iterative improvement."
+---
+
+> Override for Codex users who want **Gemini**, not a second Codex agent, to act as the reviewer. Install this package **after** `skills/skills-codex/*`.
+
+# Auto Review Loop: Autonomous Research Improvement
+
+> **Gemini overlay assurance:** `review_independence: cross-family` and `acceptance_status: accepted`.
+
+Autonomously iterate: review → implement fixes → re-review, until the external reviewer gives a positive assessment or MAX_ROUNDS is reached.
+
+## Context: $ARGUMENTS
+
+## Constants
+
+- MAX_ROUNDS = 4
+- POSITIVE_THRESHOLD: score >= 6/10 AND verdict ∈ {"ready", "almost"} — both must hold, matching the operative STOP CONDITION below. Verdict vocabulary is {"ready", "almost", "not ready"}. (Earlier wording used "or" + a stale verdict set; the AND form is authoritative.)
+- REVIEW_DOC: `review-stage/AUTO_REVIEW.md` (cumulative log) *(fall back to `./AUTO_REVIEW.md` for legacy projects)*
+- **OUTPUT_DIR = `review-stage/`** — Directory for review output files.
+- **REVIEWER_MODEL = `gemini-review`** — Gemini reviewer invoked through the local `gemini-review` MCP bridge. Set `GEMINI_REVIEW_MODEL` if you need a specific Gemini model override.
+- **HUMAN_CHECKPOINT = false** — When `true`, pause after each round's review (Phase B) and present the score + weaknesses to the user. Wait for user input before proceeding to Phase C. The user can: approve the suggested fixes, provide custom modification instructions, skip specific fixes, or stop the loop early. When `false` (default), the loop runs fully autonomously.
+
+> 💡 Override: `/auto-review-loop "topic" — human checkpoint: true`
+
+## State Persistence (Compact Recovery)
+
+Long-running loops may hit the context window limit, triggering automatic compaction. To survive this, persist state to `review-stage/REVIEW_STATE.json` after each round:
+
+```json
+{
+  "round": 2,
+  "thread_id": "019cd392-...",
+  "status": "in_progress",
+  "last_score": 5.0,
+  "last_verdict": "not ready",
+  "pending_experiments": ["screen_name_1"],
+  "timestamp": "2026-03-13T21:00:00"
+}
+```
+
+**Write this file at the end of every Phase E** (after documenting the round). Overwrite each time — only the latest state matters.
+
+**On completion** (positive assessment or max rounds), set `"status": "completed"` so future invocations don't accidentally resume a finished loop.
+
+## Workflow
+
+### Initialization
+
+1. **Check for `review-stage/REVIEW_STATE.json`** *(fall back to `./REVIEW_STATE.json` if not found — legacy path)*:
+   - If neither path exists: **fresh start** (normal case, identical to behavior before this feature existed)
+   - If it exists AND `status` is `"completed"`: **fresh start** (previous loop finished normally)
+   - If it exists AND `status` is `"in_progress"` AND `timestamp` is older than 24 hours: **fresh start** (stale state from a killed/abandoned run — delete the file and start over)
+   - If it exists AND `status` is `"in_progress"` AND `timestamp` is within 24 hours: **resume**
+     - Read the state file to recover `round`, `thread_id`, `last_score`, `pending_experiments`
+     - Read `review-stage/AUTO_REVIEW.md` to restore full context of prior rounds *(fall back to `./AUTO_REVIEW.md`)*
+     - If `pending_experiments` is non-empty, check if they have completed (e.g., check screen sessions)
+     - Resume from the next round (round = saved round + 1)
+     - Log: "Recovered from context compaction. Resuming at Round N."
+2. Read project narrative documents, memory files, and any prior review documents
+3. Read recent experiment results (check output directories, logs)
+4. Identify current weaknesses and open TODOs from prior reviews
+5. Initialize round counter = 1 (unless recovered from state file)
+6. Create/update `review-stage/AUTO_REVIEW.md` with header and timestamp
+
+### Loop (repeat up to MAX_ROUNDS)
+
+#### Phase A: Review
+
+Send comprehensive context to the external reviewer:
+
+```
+mcp__gemini-review__review_start:
+  prompt: |
+    [Round N/MAX_ROUNDS of autonomous review loop]
+
+    [Full research context: claims, methods, results, known weaknesses]
+    [Changes since last round, if any]
+
+    Please act as a senior ML reviewer (NeurIPS/ICML level).
+
+    1. Score this work 1-10 for a top venue
+    2. List remaining critical weaknesses (ranked by severity)
+    3. For each weakness, specify the MINIMUM fix (experiment, analysis, or reframing)
+    4. State clearly: is this READY for submission? Yes/No/Almost
+
+    Be brutally honest. If the work is ready, say so clearly.
+
+    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
+    Report anything that is actually wrong here — including a rare-looking case, if
+    this repo actually produces it. Then keep the fix in scope:
+    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
+       welcome; over-defense is not. Assume a cooperating operator on their own
+       machine — a malicious local user is NOT in the threat model.
+    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
+       Reporting a real defect in hashing code that already exists is fine.
+    3. NO speculative machinery: do not add feature flags, migration frameworks,
+       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
+       a current repo defect they fix or an explicit existing invariant they must
+       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
+       not evidence. Point to the failing path/artifact or invariant, and check the
+       proposal's factual premises, such as whether a named package version exists.
+    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
+       millisecond races are out of scope unless you can show the case arises here.
+    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
+       judgement. A clear sentence a human reads beats a scored table nobody
+       maintains.
+    Exception: code that runs remote commands, starts a network service, or installs
+    an MCP server runs on the user's machine with their credentials — trust-boundary
+    findings there are in scope and the default is strict.
+    Say plainly when something is correct. Do not manufacture findings.
+```
+
+After this start call, immediately save the returned `jobId` and poll `mcp__gemini-review__review_status` with a bounded `waitSeconds` until `done=true`. Treat the completed status payload's `response` as the reviewer output, and save the completed `threadId` for any follow-up round.
+
+If this is round 2+, use `mcp__gemini-review__review_reply_start` with the saved completed `threadId`, then poll `mcp__gemini-review__review_status` with the returned `jobId` until `done=true` to maintain continuity.
+
+#### Phase B: Parse Assessment
+
+**CRITICAL: Save the FULL raw response** from the external reviewer verbatim (store in a variable for Phase E). Do NOT discard or summarize — the raw text is the primary record.
+
+Then extract structured fields:
+- **Score** (numeric 1-10)
+- **Verdict** ("ready" / "almost" / "not ready")
+- **Action items** (ranked list of fixes)
+
+**STOP CONDITION**: If score >= 6 AND verdict ∈ {"ready", "almost"} (exact match — "not ready" does NOT qualify) → stop loop, document final state.
+
+#### Human Checkpoint (if enabled)
+
+**Skip this step entirely if `HUMAN_CHECKPOINT = false`.**
+
+When `HUMAN_CHECKPOINT = true`, present the review results and wait for user input:
+
+```
+📋 Round N/MAX_ROUNDS review complete.
+
+Score: X/10 — [verdict]
+Top weaknesses:
+1. [weakness 1]
+2. [weakness 2]
+3. [weakness 3]
+
+Suggested fixes:
+1. [fix 1]
+2. [fix 2]
+3. [fix 3]
+
+Options:
+- Reply "go" or "continue" → implement all suggested fixes
+- Reply with custom instructions → implement your modifications instead
+- Reply "skip 2" → skip fix #2, implement the rest
+- Reply "stop" → end the loop, document current state
+```
+
+Wait for the user's response. Parse their input:
+- **Approval** ("go", "continue", "ok", "proceed"): proceed to Phase C with all suggested fixes
+- **Custom instructions** (any other text): treat as additional/replacement guidance for Phase C. Merge with reviewer suggestions where appropriate
+- **Skip specific fixes** ("skip 1,3"): remove those fixes from the action list
+- **Stop** ("stop", "enough", "done"): terminate the loop, jump to Termination
+
+#### Feishu Notification (if configured)
+
+After parsing the score, check if `~/.codex/feishu.json` exists and mode is not `"off"`:
+- Send a `review_scored` notification: "Round N: X/10 — [verdict]" with top 3 weaknesses
+- If **interactive** mode and verdict is "almost": send as checkpoint, wait for user reply on whether to continue or stop
+- If config absent or mode off: skip entirely (no-op)
+
+#### Phase C: Implement Fixes (if not stopping)
+
+For each action item (highest priority first):
+
+1. **Code changes**: Write/modify experiment scripts, model code, analysis scripts
+2. **Run experiments**: Deploy to GPU server via SSH + screen/tmux
+3. **Analysis**: Run evaluation, collect results, update figures/tables
+4. **Documentation**: Update project notes and review document
+
+Prioritization rules:
+- Skip fixes requiring excessive compute (flag for manual follow-up)
+- Skip fixes requiring external data/models not available
+- Prefer reframing/analysis over new experiments when both address the concern
+- Always implement metric additions (cheap, high impact)
+
+#### Phase D: Wait for Results
+
+If experiments were launched:
+- Monitor remote sessions for completion
+- Collect results from output files and logs
+
+#### Phase E: Document Round
+
+Append to `review-stage/AUTO_REVIEW.md`:
+
+```markdown
+## Round N (timestamp)
+
+### Assessment (Summary)
+- Score: X/10
+- Verdict: [ready/almost/not ready]
+- Key criticisms: [bullet list]
+
+### Reviewer Raw Response
+
+<details>
+<summary>Click to expand full reviewer response</summary>
+
+[Paste the COMPLETE raw response from the external reviewer here — verbatim, unedited.
+This is the authoritative record. Do NOT truncate or paraphrase.]
+
+</details>
+
+### Actions Taken
+- [what was implemented/changed]
+
+### Results
+- [experiment outcomes, if any]
+
+### Status
+- [continuing to round N+1 / stopping]
+```
+
+**Write `review-stage/REVIEW_STATE.json`** with current round, agent id, score, verdict, and any pending experiments.
+
+Increment round counter → back to Phase A.
+
+### Termination
+
+When loop ends (positive assessment or max rounds):
+
+1. Update `review-stage/REVIEW_STATE.json` with `"status": "completed"`
+2. Write final summary to `review-stage/AUTO_REVIEW.md`
+3. Update project notes with conclusions
+4. If stopped at max rounds without positive assessment:
+   - List remaining blockers
+   - Estimate effort needed for each
+   - Suggest whether to continue manually or pivot
+5. **Feishu notification** (if configured): Send `pipeline_done` with final score progression table
+
+## Output Protocols
+
+> Follow these shared protocols for all output files:
+> - **[Output Versioning Protocol](../../shared-references/output-versioning.md)** — write timestamped file first, then copy to fixed name
+> - **[Output Manifest Protocol](../../shared-references/output-manifest.md)** — log every output to MANIFEST.md
+> - **[Output Language Protocol](../../shared-references/output-language.md)** — respect the project's language setting
+
+## Key Rules
+
+- **Large file handling**: If the Write tool fails due to file size, immediately retry using Bash (`cat << 'EOF' > file`) to write in chunks. Do NOT ask the user for permission — just do it silently.
+
+- Always ask the Gemini reviewer for strict, high-rigor feedback.
+- Save the completed `threadId` from the first `mcp__gemini-review__review_status` result, then use `mcp__gemini-review__review_reply_start` plus `mcp__gemini-review__review_status` for subsequent rounds
+- Be honest — include negative results and failed experiments
+- Do NOT hide weaknesses to game a positive score
+- Implement fixes BEFORE re-reviewing (don't just promise to fix)
+- If an experiment takes > 30 minutes, launch it and continue with other fixes while waiting
+- Document EVERYTHING — the review log should be self-contained
+- Update project notes after each round, not just at the end
+
+## Prompt Template for Round 2+
+
+```
+mcp__gemini-review__review_reply_start:
+  threadId: [saved from round 1]
+  prompt: |
+    [Round N update]
+
+    Since your last review, we have:
+    1. [Action 1]: [result]
+    2. [Action 2]: [result]
+    3. [Action 3]: [result]
+
+    Updated results table:
+    [paste metrics]
+
+    Please re-score and re-assess. Are the remaining concerns addressed?
+    Same format: Score, Verdict, Remaining Weaknesses, Minimum Fixes.
+
+    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
+    Report anything that is actually wrong here — including a rare-looking case, if
+    this repo actually produces it. Then keep the fix in scope:
+    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
+       welcome; over-defense is not. Assume a cooperating operator on their own
+       machine — a malicious local user is NOT in the threat model.
+    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
+       Reporting a real defect in hashing code that already exists is fine.
+    3. NO speculative machinery: do not add feature flags, migration frameworks,
+       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
+       a current repo defect they fix or an explicit existing invariant they must
+       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
+       not evidence. Point to the failing path/artifact or invariant, and check the
+       proposal's factual premises, such as whether a named package version exists.
+    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
+       millisecond races are out of scope unless you can show the case arises here.
+    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
+       judgement. A clear sentence a human reads beats a scored table nobody
+       maintains.
+    Exception: code that runs remote commands, starts a network service, or installs
+    an MCP server runs on the user's machine with their credentials — trust-boundary
+    findings there are in scope and the default is strict.
+    Say plainly when something is correct. Do not manufacture findings.
+```
+
+After this start call, immediately save the returned `jobId` and poll `mcp__gemini-review__review_status` with a bounded `waitSeconds` until `done=true`. Treat the completed status payload's `response` as the reviewer output, and save the completed `threadId` for any follow-up round.