@research-copilot/plugin 1.1.17 → 1.1.19

package/dist/skills/experiment-audit/SKILL.md

@@ -0,0 +1,262 @@
+---
+name: experiment-audit
+description: "Audit experiment integrity before claiming results. Uses cross-model review (GPT-5.5) to check for fake ground truth, score normalization fraud, phantom results, and insufficient scope. Use when user says \"审计实验\", \"check experiment integrity\", \"audit results\", \"实验诚实度\", or after experiments complete before writing claims."
+argument-hint: [experiment-dir-or-results-path]
+allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob
+---
+
+# Experiment Audit: Cross-Model Integrity Verification
+
+Audit experiment integrity for: **$ARGUMENTS**
+
+## Why This Exists
+
+LLM agents can produce fraudulent experimental results through:
+1. **Fake ground truth** — creating synthetic "reference" from model outputs, then reporting high agreement as performance
+2. **Score normalization** — dividing metrics by the model's own max to get 0.99+
+3. **Phantom results** — claiming numbers from files that don't exist or functions never called
+4. **Insufficient scope** — reporting 2-scene pilots as "comprehensive evaluation"
+
+These are NOT intentional deception — they are failure modes of optimizing agents that lack integrity constraints. This skill adds that constraint.
+
+## Core Principle
+
+**The executor (Claude) collects file paths. The reviewer (GPT-5.5) reads code and judges integrity. The executor does NOT participate in integrity judgment.**
+
+This follows `shared-references/reviewer-independence.md` and `shared-references/experiment-integrity.md`.
+
+## Constants
+
+- **REVIEWER_BACKEND = `codex`** — Default: Codex reviewer agent (`spawn_agent`, xhigh). Override with `— reviewer: oracle-pro` for GPT-5.5 Pro via Oracle MCP. See `shared-references/reviewer-routing.md`.
+
+## Workflow
+
+### Step 1: Collect Artifacts (Executor — Claude)
+
+Locate and list these files WITHOUT reading or summarizing their content:
+
+```
+Scan project directory for:
+1. Evaluation scripts:    *eval*.py, *metric*.py, *test*.py, *benchmark*.py
+2. Result files:          *.json, *.csv in results/, outputs/, logs/
+3. Ground truth paths:    look in eval scripts for data loading (dataset paths, GT references)
+4. Experiment tracker:    EXPERIMENT_TRACKER.md, EXPERIMENT_LOG.md
+5. Paper claims:          NARRATIVE_REPORT.md, paper/sections/*.tex, PAPER_PLAN.md
+6. Config files:          *.yaml, *.toml, *.json configs with metric definitions
+```
+
+**DO NOT summarize, interpret, or explain any file content.** Only collect paths.
+
+### Step 2: Send to Reviewer (GPT-5.5 via Codex MCP)
+
+Pass ONLY file paths and the audit checklist to the reviewer. The reviewer reads everything directly.
+
+```text
+spawn_agent:
+  model: gpt-5.5
+  reasoning_effort: xhigh
+  message: |
+    You are an experiment integrity auditor. Read ALL files listed below
+    and check for the following fraud patterns.
+
+    Files to read:
+    - Evaluation scripts: [list paths]
+    - Result files: [list paths]
+    - Experiment tracker: [list paths]
+    - Paper claims: [list paths]
+    - Config files: [list paths]
+
+    ## Audit Checklist
+
+    ### A. Ground Truth Provenance
+    For each evaluation script:
+    1. Where does "ground truth" / "reference" / "target" come from?
+    2. Is it loaded from the DATASET, or generated/derived from MODEL OUTPUTS?
+    3. If derived: is it explicitly labeled as proxy evaluation?
+    4. Are official eval scripts used when available for this benchmark?
+    FAIL if: GT is derived from model outputs without explicit proxy labeling.
+
+    ### B. Score Normalization
+    For each metric computation:
+    1. Is any metric divided by max/min/mean of the model's OWN output?
+    2. Are raw scores reported alongside any normalized scores?
+    3. Are any scores suspiciously close to 1.0 or 100%?
+    FAIL if: Normalization denominator comes from prediction statistics.
+
+    ### C. Result File Existence
+    For each claim in the paper/narrative:
+    1. Does the referenced result file actually exist?
+    2. Does the claimed metric key exist in that file?
+    3. Does the claimed NUMBER match what's in the file?
+    4. Is the experiment tracker status DONE (not TODO/IN_PROGRESS)?
+    FAIL if: Claimed results reference nonexistent files or mismatched numbers.
+
+    ### D. Dead Code Detection
+    For each metric function defined in eval scripts:
+    1. Is it actually CALLED in any evaluation pipeline?
+    2. Does its output appear in any result file?
+    WARN if: Metric functions exist but are never called.
+
+    ### E. Scope Assessment
+    1. How many scenes/datasets/configurations were actually tested?
+    2. How many seeds/runs per configuration?
+    3. Does the paper use words like "comprehensive", "extensive", "robust"?
+    4. Is the actual scope sufficient for those claims?
+    WARN if: Scope language exceeds actual evidence.
+
+    ### F. Evaluation Type Classification
+    Classify each evaluation as:
+    - real_gt: uses dataset-provided ground truth
+    - synthetic_proxy: uses model-generated reference
+    - self_supervised_proxy: no GT by design
+    - simulation_only: simulated environment
+    - human_eval: human judges
+
+    ## Output Format
+
+    For each check (A-F), report:
+    - Status: PASS | WARN | FAIL
+    - Evidence: exact file:line references
+    - Details: what specifically was found
+
+    Overall verdict: PASS | WARN | FAIL
+    
+    Be thorough. Read every eval script line by line.
+```
+
+### Step 3: Parse and Write Report (Executor — Claude)
+
+Parse the reviewer's response and write `EXPERIMENT_AUDIT.md`:
+
+```markdown
+# Experiment Audit Report
+
+**Date**: [today]
+**Auditor**: GPT-5.5 xhigh (cross-model, read-only)
+**Project**: [project name]
+
+## Overall Verdict: [PASS | WARN | FAIL]
+
+## Integrity Status: [pass | warn | fail]
+
+## Checks
+
+### A. Ground Truth Provenance: [PASS|WARN|FAIL]
+[details + file:line evidence]
+
+### B. Score Normalization: [PASS|WARN|FAIL]
+[details]
+
+### C. Result File Existence: [PASS|WARN|FAIL]
+[details]
+
+### D. Dead Code Detection: [PASS|WARN|FAIL]
+[details]
+
+### E. Scope Assessment: [PASS|WARN|FAIL]
+[details]
+
+### F. Evaluation Type: [real_gt | synthetic_proxy | ...]
+[classification + evidence]
+
+## Action Items
+- [specific fixes if WARN or FAIL]
+
+## Claim Impact
+- Claim 1: [supported | needs qualifier | unsupported]
+- Claim 2: ...
+```
+
+Also write `EXPERIMENT_AUDIT.json` for machine consumption:
+
+```json
+{
+  "date": "2026-04-10",
+  "auditor": "gpt-5.5-xhigh",
+  "overall_verdict": "warn",
+  "integrity_status": "warn",
+  "checks": {
+    "gt_provenance": {"status": "pass", "details": "..."},
+    "score_normalization": {"status": "warn", "details": "..."},
+    "result_existence": {"status": "pass", "details": "..."},
+    "dead_code": {"status": "pass", "details": "..."},
+    "scope": {"status": "warn", "details": "..."},
+    "eval_type": "real_gt"
+  },
+  "claims": [
+    {"id": "C1", "impact": "supported"},
+    {"id": "C2", "impact": "needs_qualifier"}
+  ]
+}
+```
+
+### Step 4: Print Summary
+
+```
+🔬 Experiment Audit Complete
+
+  GT Provenance:      ✅ PASS — real dataset GT used
+  Score Normalization: ⚠️ WARN — boundary metric uses self-reference
+  Result Existence:    ✅ PASS — all files exist, numbers match
+  Dead Code:           ✅ PASS — all metric functions called
+  Scope:               ⚠️ WARN — 2 scenes, paper says "comprehensive"
+
+  Overall: ⚠️ WARN
+  
+  See EXPERIMENT_AUDIT.md for details.
+```
+
+## Integration with Other Skills
+
+### Automatic in /research-pipeline (advisory, never blocks)
+
+When integrated into the pipeline, this skill runs automatically after `/experiment-bridge` and before `/auto-review-loop`:
+
+```
+/experiment-bridge → results ready
+    ↓
+/experiment-audit (automatic, advisory)
+    ├── PASS  → continue normally
+    ├── WARN  → print ⚠️ warning, continue, tag claims as [INTEGRITY: WARN]
+    └── FAIL  → print 🔴 alert, continue, tag claims as [INTEGRITY CONCERN]
+    ↓
+/auto-review-loop → proceeds with integrity tags visible to reviewer
+```
+
+**Never blocks the pipeline.** Even on FAIL, the pipeline continues — but claims carry visible integrity tags.
+
+### Read by /result-to-claim (if exists)
+
+```
+if EXPERIMENT_AUDIT.json exists:
+    read integrity_status
+    attach to verdict: {claim_supported: "yes", integrity_status: "warn"}
+    if integrity_status == "fail":
+        downgrade verdict display: "yes [INTEGRITY CONCERN]"
+else:
+    verdict as normal, integrity_status = "unavailable"
+    mark as "provisional — no integrity audit"
+```
+
+### Read by /paper-write (if exists)
+
+```
+if EXPERIMENT_AUDIT.json exists AND integrity_status == "fail":
+    add footnote to affected claims: "Note: integrity audit flagged concerns with this evaluation"
+```
+
+## Key Rules
+
+- **Reviewer independence**: executor collects paths, reviewer judges. Period.
+- **Never block**: warn loudly, never halt the pipeline.
+- **File-as-switch**: no EXPERIMENT_AUDIT.md = skill was never run = zero impact on existing behavior.
+- **Cross-model**: the reviewer MUST be a different model family from the executor.
+- **Honest about limits**: the audit catches common patterns, not all possible fraud. It is a safety net, not a guarantee.
+
+## Acknowledgements
+
+Motivated by community-reported integrity issues (#57, #131) where executor agents created fake ground truth and self-normalized scores.
+
+## Review Tracing
+
+After each reviewer agent call, save the trace following `shared-references/review-tracing.md` (Policy C — forensic; never silently skip). Use `save_trace.sh` (resolved per the chain in `shared-references/integration-contract.md` §2) or write files directly to `.aris/traces/<skill>/<date>_run<NN>/`. Respect the `--- trace:` parameter (default: `full`).

package/dist/skills/experiment-bridge/SKILL.md

@@ -0,0 +1,316 @@
+---
+name: experiment-bridge
+description: "Workflow 1.5: Bridge between idea discovery and auto review. Reads EXPERIMENT_PLAN.md, implements experiment code, deploys to GPU, collects initial results. Use when user says \"实现实验\", \"implement experiments\", \"bridge\", \"从计划到跑实验\", \"deploy the plan\", or has an experiment plan ready to execute."
+---
+
+# Workflow 1.5: Experiment Bridge
+
+Implement and deploy experiments from plan: **$ARGUMENTS**
+
+## Overview
+
+This skill bridges Workflow 1 (idea discovery + method refinement) and Workflow 2 (auto review loop). It takes the experiment plan and turns it into running experiments with initial results.
+
+```
+Workflow 1 output:                    This skill:                        Workflow 2 input:
+refine-logs/EXPERIMENT_PLAN.md   →   implement → deploy → collect   →   initial results ready
+refine-logs/EXPERIMENT_TRACKER.md     code        /run-experiment        for /auto-review-loop
+refine-logs/FINAL_PROPOSAL.md
+```
+
+## Constants
+
+- **AUTO_DEPLOY = true** — Automatically deploy experiments after implementation. Set `false` to review code before deploying.
+- **CODE_REVIEW = true** — Secondary Codex reviewer with xhigh reasoning reviews experiment code before deployment. Catches logic bugs before wasting GPU hours. Set `false` to skip.
+- **SANITY_FIRST = true** — Run the sanity-stage experiment first (smallest, fastest) before launching the rest. Catches setup bugs early.
+- **MAX_PARALLEL_RUNS = 4** — Maximum number of experiments to deploy in parallel (limited by available GPUs).
+- **BASE_REPO = false** — GitHub repo URL to use as a base codebase. When set, clone it first and implement experiments on top of it.
+- **COMPACT = false** — When `true`, prefer `idea-stage/IDEA_CANDIDATES.md` over the full `idea-stage/IDEA_REPORT.md`, and append completed runs to `EXPERIMENT_LOG.md`.
+- **BACKENDS = local | ssh | vast | modal** — Preserve the Claude mainline backend lifecycle. Vast.ai and Modal routes are first-class when configured; do not silently fall back to local execution if the user requested either backend.
+- **RESCUE_ON_FAILURE = true** — If sanity or deployment fails, run a Codex-native rescue / second opinion review before abandoning the experiment plan.
+
+> Override: `/experiment-bridge "EXPERIMENT_PLAN.md" — compact: true, base repo: https://github.com/org/project`
+
+## Inputs
+
+This skill expects one or more of:
+
+1. **`refine-logs/EXPERIMENT_PLAN.md`** (best) — claim-driven experiment roadmap from `/experiment-plan`
+2. **`refine-logs/EXPERIMENT_TRACKER.md`** — run-by-run execution table
+3. **`refine-logs/FINAL_PROPOSAL.md`** — method description for implementation context
+4. **`idea-stage/IDEA_CANDIDATES.md`** — compact idea summary (preferred when `COMPACT = true`) *(fall back to `./IDEA_CANDIDATES.md` if not found)*
+5. **`idea-stage/IDEA_REPORT.md`** — fallback if refine-logs don't exist *(fall back to `./IDEA_REPORT.md` if not found)*
+
+If none exist, ask the user what experiments to implement.
+
+## Workflow
+
+### Phase 1: Parse the Experiment Plan
+
+Read `EXPERIMENT_PLAN.md` and extract:
+
+1. **Run order and milestones** — which experiments run first (sanity → baseline → main → ablation → polish)
+2. **For each experiment block:**
+   - Dataset / split / task
+   - Compared systems and variants
+   - Metrics to compute
+   - Setup details (backbone, hyperparameters, seeds)
+   - Success criterion
+   - Priority (MUST-RUN vs NICE-TO-HAVE)
+3. **Compute budget** — total estimated GPU-hours
+4. **Method details** from `FINAL_PROPOSAL.md` — what exactly to implement
+
+Present a brief summary:
+
+```
+📋 Experiment plan loaded:
+- Milestones: [N] (sanity → baseline → main → ablation)
+- Must-run experiments: [N]
+- Nice-to-have: [N]
+- Estimated GPU-hours: [X]
+
+Proceeding to implementation.
+```
+
+### Phase 2: Implement Experiment Code
+
+**If `BASE_REPO` is set** — clone the repo first:
+
+```bash
+git clone <BASE_REPO> base_repo/
+```
+
+For each milestone (in order), write the experiment scripts:
+
+1. **Check existing code** — scan the project (or cloned `base_repo/`) for existing experiment scripts, model code, and data loaders. Reuse as much as possible.
+
+2. **Implement missing pieces:**
+   - Training scripts with proper argparse (all hyperparameters configurable)
+   - Evaluation scripts computing the specified metrics
+   - Data loading / preprocessing if needed
+   - Baseline implementations if not already present
+   - Fixed random seeds for reproducibility
+   - Results saved to JSON/CSV for later analysis
+   - Proper logging (wandb if configured in AGENTS.md)
+
+3. **Follow the plan's run order** — implement sanity-stage experiments first, then baselines, then main method, then ablations.
+
+4. **Self-review before deploying:**
+   - Are all hyperparameters from EXPERIMENT_PLAN.md reflected in argparse?
+   - Is the random seed fixed and controllable?
+   - Are results saved in a parseable format (JSON/CSV)?
+   - Does the code match FINAL_PROPOSAL.md's method description?
+   - **CRITICAL**: does evaluation compare predictions against dataset ground truth, never another model's output?
+
+### Phase 2.5: Cross-Model Code Review (when CODE_REVIEW = true)
+
+Skip this step if `CODE_REVIEW` is `false`.
+
+Before deploying, send the experiment code to a secondary Codex reviewer with xhigh reasoning:
+
+```text
+spawn_agent:
+  reasoning_effort: xhigh
+  message: |
+    Review the following experiment implementation for correctness.
+
+    ## Experiment Plan
+    [paste key sections from EXPERIMENT_PLAN.md]
+
+    ## Method Description
+    [paste from FINAL_PROPOSAL.md]
+
+    ## Implementation
+    [paste the experiment scripts or exact file paths plus relevant snippets]
+
+    Check for:
+    1. Does the code correctly implement the method described in the proposal?
+    2. Are all hyperparameters from the plan reflected in the code?
+    3. Are there logic bugs: wrong loss, wrong data split, missing eval, leakage, metric mismatch?
+    4. Is the evaluation metric computed against ground truth, not another model's output?
+    5. Are seeds, result paths, logging, and failure handling sufficient for reproducible experiments?
+
+    Output:
+    - BLOCKING issues that must be fixed before deployment
+    - NON-BLOCKING issues that can wait
+    - Suggested patches or checks
+```
+
+If BLOCKING issues are found, fix them and re-run this review once before Phase 3. Save the reviewer response and any fixes in `refine-logs/EXPERIMENT_CODE_REVIEW.md`. If reviewer delegation is unavailable, run the same checklist locally and mark the review `[local-only]`.
+
+### Phase 3: Sanity Check (if SANITY_FIRST = true)
+
+Before deploying the full experiment suite, run the sanity-stage experiment:
+
+```
+/run-experiment [sanity experiment command]
+```
+
+Wait for completion. Verify:
+- Training loop runs without errors
+- Metrics are computed and saved correctly
+- GPU memory usage is within bounds
+- Output format matches expectations
+
+If sanity fails → fix the code, re-run. Do not proceed to full deployment with broken code.
+
+If the same sanity failure repeats, trigger a second opinion: summarize the plan, code diff, command, logs, backend, and failure, then ask a fresh Codex reviewer agent for a rescue diagnosis. Apply only concrete fixes grounded in the logs.
+
+### Phase 4: Deploy Full Experiments
+
+Deploy experiments following the plan's milestone order. Route by job count and dependencies:
+
+```
+/run-experiment [experiment commands]
+```
+
+For large batches (≥10 jobs), multi-seed sweeps, or teacher→student phase dependencies, use the queue scheduler:
+
+```
+/experiment-queue [grid spec or manifest]
+```
+
+Auto-routing rule: if any milestone in `EXPERIMENT_PLAN.md` declares ≥10 jobs or declares phase dependencies, route that milestone to `/experiment-queue`; otherwise use `/run-experiment`. `/experiment-queue` adds OOM-aware retry with backoff, stale-screen cleanup, wave-transition race prevention, phase dependency enforcement, and crash-safe state persistence in `queue_state.json`.
+
+For each milestone:
+1. Deploy experiments in parallel (up to MAX_PARALLEL_RUNS for `/run-experiment`, or `max_parallel` from the queue manifest for `/experiment-queue`)
+2. Use `/monitor-experiment` to track progress; if `/experiment-queue` is active, monitor `queue_state.json`
+3. Collect results as experiments complete
+
+Backend lifecycle rules:
+- **Vast.ai**: record instance id, SSH endpoint, mounted data/checkpoints, estimated hourly cost, and cleanup policy. If `auto_destroy` is configured, write the exact cleanup command before launch.
+- **Modal**: verify app/function, image/dependencies, secrets, volumes, and output persistence before launch.
+- **Local/SSH**: verify GPU availability, environment activation, log path, and result path before launching.
+- If a backend is unreachable or misconfigured, stop with a configuration issue instead of silently switching backend.
+
+**🚦 Checkpoint (if AUTO_DEPLOY = false):**
+
+```
+🔧 Code implementation complete. Ready to deploy:
+
+Milestone 0 (sanity): [status — passed/pending]
+Milestone 1 (baseline): [N experiments, ~X GPU-hours]
+Milestone 2 (main method): [N experiments, ~X GPU-hours]
+Milestone 3 (ablations): [N experiments, ~X GPU-hours]
+
+Total estimated: ~X GPU-hours on [N] GPUs
+
+Deploy now? Or review the code first?
+```
+
+### Phase 5: Collect Initial Results
+
+As experiments complete:
+
+1. **Parse output files** (JSON/CSV/logs) for key metrics
+2. **Training quality check** — if W&B data is available, invoke `/training-check` to detect NaN, loss divergence, plateaus, or overfitting. If W&B is not configured, skip silently.
+3. **Update `refine-logs/EXPERIMENT_TRACKER.md`** — fill in Status and Notes columns
+4. **Check success criteria** from EXPERIMENT_PLAN.md — did each experiment meet its bar?
+5. **Write initial results summary:**
+
+```markdown
+# Initial Experiment Results
+
+**Date**: [today]
+**Plan**: refine-logs/EXPERIMENT_PLAN.md
+
+## Results by Milestone
+
+### M0: Sanity — PASSED
+- [result]
+
+### M1: Baselines
+| Run | System | Key Metric | Status |
+|-----|--------|-----------|--------|
+| R001 | baseline_1 | X.XX | DONE |
+
+### M2: Main Method
+| Run | System | Key Metric | Status |
+|-----|--------|-----------|--------|
+| R003 | our_method | X.XX | DONE |
+
+### M3: Ablations
+...
+
+## Summary
+- [X/Y] must-run experiments completed
+- Main result: [positive/negative/inconclusive]
+- Ready for /auto-review-loop: [YES/NO]
+
+## Next Step
+→ /auto-review-loop "[topic]"
+```
+
+### Phase 5.5: Write Compact Log (when COMPACT = true)
+
+**Skip entirely if `COMPACT` is `false`.**
+
+Append each completed experiment to `EXPERIMENT_LOG.md`:
+
+```markdown
+## [Run ID] — [timestamp]
+- **System**: [method name]
+- **Config**: [key hyperparameters]
+- **Result**: [primary metric = X.XX]
+- **Verdict**: [positive / negative / inconclusive]
+- **Reproduce**: `python train.py --config configs/run_id.yaml --seed 42`
+```
+
+### Phase 5.6: Auto Ablation Planning
+
+After main experiments (M2) complete with positive results, invoke `/ablation-planner` to design ablation studies:
+
+- Read the main results and method description
+- Generate a claim-driven ablation plan: which components to remove, what to compare, and expected outcomes
+- Append ablation blocks to `refine-logs/EXPERIMENT_PLAN.md` and `refine-logs/EXPERIMENT_TRACKER.md`
+- If main results are negative or inconclusive, skip ablation planning and note that in the summary
+
+If `/ablation-planner` is unavailable, skip silently.
+
+### Phase 6: Handoff
+
+Present final status:
+
+```
+🔬 Experiment bridge complete:
+- Implemented: [N] experiment scripts
+- Deployed: [N] experiments on [M] GPUs
+- Completed: [X/Y] must-run, [A/B] nice-to-have
+- Main result: [one sentence]
+
+Results: refine-logs/EXPERIMENT_RESULTS.md
+Tracker: refine-logs/EXPERIMENT_TRACKER.md
+
+Ready for Workflow 2:
+→ /auto-review-loop "[topic]"
+```
+
+## 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.
+- **CRITICAL — Evaluation must use dataset ground truth.** Always compare model predictions against the dataset's actual labels/targets, never another model's output. If the task has official eval scripts, prefer them.
+- **Follow the plan.** Do not invent experiments not in EXPERIMENT_PLAN.md. If you think something is missing, note it but don't add it.
+- **Sanity first.** Never deploy a full suite without verifying the sanity stage passes.
+- **Reuse existing code.** Scan the project before writing new scripts. Extend, don't duplicate.
+- **Save everything as JSON/CSV.** The auto-review-loop needs parseable results, not just terminal output.
+- **Update the tracker.** `EXPERIMENT_TRACKER.md` should reflect real status after each run completes.
+- **Don't wait forever.** If an experiment exceeds 2x its estimated time, flag it and move on to the next milestone.
+- **Budget awareness.** Track GPU-hours against the plan's budget. Warn if approaching the limit.
+
+## Composing with Other Skills
+
+```
+/idea-discovery "direction"          ← Workflow 1: find + refine + plan
+/experiment-bridge                   ← you are here (Workflow 1.5: implement + deploy)
+/auto-review-loop "topic"            ← Workflow 2: review + iterate
+/paper-writing "NARRATIVE_REPORT.md" ← Workflow 3: write the paper
+
+Or use /research-pipeline for the full end-to-end flow (includes this bridge).
+```