research-refine

name	research-refine
description	Turn a vague research direction into a problem-anchored, elegant, frontier-aware, implementation-oriented method plan via iterative GPT-5.4 review. Use when the user says "refine my approach", "decompose this problem", "refine research plan", or wants a concrete research method that stays simple, focused, and top-venue ready instead of a vague or overbuilt idea.
argument-hint	["topic-or-scope"]
allowed-tools	Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch, Agent

Research Refine: Problem-Anchored, Elegant, Frontier-Aware Plan Refinement

Refine and concretize: $ARGUMENTS

Overview

Use this skill when the research problem is already visible but the technical route is still fuzzy. The goal is not to produce a bloated proposal or a benchmark shopping list. The goal is to turn a vague direction into a problem -> focused method -> minimal validation document that is concrete enough to implement, elegant enough to feel paper-worthy, and current enough to resonate in the foundation-model era.

Four principles dominate this skill:

1. Do not lose the original problem. Freeze an immutable Problem Anchor and reuse it in every round.
2. The smallest adequate mechanism wins. Prefer the minimal intervention that directly fixes the bottleneck.
3. One paper, one dominant contribution. Prefer one sharp thesis plus at most one supporting contribution.
4. Modern leverage is a prior, not a decoration. When LLM / VLM / Diffusion / RL / distillation / inference-time scaling naturally fit the bottleneck, use them concretely. Do not bolt them on as buzzwords.

User input (PROBLEM + vague APPROACH)
  -> Phase 0 (Claude): Freeze Problem Anchor
  -> Phase 1 (Claude): Scan grounding papers -> identify technical gap -> choose the sharpest route -> write focused proposal
  -> Phase 2 (Codex/GPT-5.4): Review for fidelity, specificity, contribution quality, and frontier leverage
  -> Phase 3 (Claude): Anchor check + simplicity check -> revise method -> rewrite full proposal
  -> Phase 4 (Codex, same thread): Re-evaluate revised proposal
  -> Repeat Phase 3-4 until OVERALL SCORE >= 9 or MAX_ROUNDS reached
  -> Phase 5: Save full history to output/refine-logs/
  -> Optional handoff: /experiment-plan for a detailed execution-ready experiment roadmap

Constants

• REVIEWER_MODEL = gpt-5.4 — Reviewer model used via Codex MCP.
• MAX_ROUNDS = 5 — Maximum review-revise rounds.
• SCORE_THRESHOLD = 9 — Minimum overall score to stop.
• OUTPUT_DIR = output/refine-logs/ — Directory for round files and final report.
• MAX_LOCAL_PAPERS = 15 — Maximum local papers/notes to scan for grounding.
• MAX_CORE_EXPERIMENTS = 3 — Default cap for core validation blocks inside this skill.
• MAX_PRIMARY_CLAIMS = 2 — Soft cap for paper-level claims. Prefer one dominant claim plus one supporting claim.
• MAX_NEW_TRAINABLE_COMPONENTS = 2 — Soft cap for genuinely new trainable pieces. Exceed only if the paper breaks otherwise.

Override via argument if needed, e.g. /refine-research "problem | approach" -- max rounds: 3, threshold: 9.

State Persistence (Checkpoint Recovery)

Long-running refinement sessions may fail mid-way (e.g., API timeout, context compaction, or session interruption). To avoid losing completed work, persist state to output/refine-logs/REFINE_STATE.json after each phase boundary:

{
  "phase": "review",
  "round": 1,
  "threadId": "019cd392-...",
  "last_score": 6.5,
  "last_verdict": "REVISE",
  "status": "in_progress",
  "timestamp": "2026-03-22T20:00:00"
}

Field definitions:

Field	Values	Meaning
phase	"anchor" / "proposal" / "review" / "refine" / "done"	Last completed phase
round	0–MAX_ROUNDS	Current round number
threadId	string or null	Reviewer thread ID for codex-reply continuity
last_score	number or null	Most recent overall score from reviewer
last_verdict	string or null	Most recent verdict (READY / REVISE / RETHINK)
status	"in_progress" / "completed"	Loop status
timestamp	ISO 8601	When state was last written

Write rules:

• Write after each phase completes (not before). Overwrite each time — only the latest state matters.
• On completion (Phase 5 finished), set "status": "completed".

Output Structure

output/refine-logs/
├── refine_state.json
├── round-0-initial-proposal.md
├── round-1-review.md
├── round-1-refinement.md
├── round-2-review.md
├── round-2-refinement.md
├── ...
├── final_proposal.md
├── refine_report.md
└── score-history.md

Every round-N-refinement.md must contain a full anchored proposal, not just incremental fixes.

Workflow

Initialization (Checkpoint Recovery)

Before starting any phase, check whether a previous run left a checkpoint:

1. Check for output/refine-logs/REFINE_STATE.json:

   • If it does not exist → fresh start (proceed to Phase 0 normally)
   • If it exists AND status is "completed" → fresh start (delete state file, previous run finished)
   • 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)
   • If it exists AND status is "in_progress" AND timestamp is within 24 hours → resume

2. On resume, read the state file and recover context:

   • Read all existing output/refine-logs/round-*.md files to restore prior work
   • Read output/refine-logs/SCORE_HISTORY.md if it exists
   • Recover threadId for reviewer thread continuity
   • Log to the user: "Checkpoint found. Resuming after phase: {phase}, round: {round}."
   • Jump to the next phase based on the saved phase value:

   Saved phase	What was completed	Resume from
   "anchor"	Phase 0 done	Phase 1 (read anchor from round-0 context)
   "proposal"	Phase 1 done	Phase 2 (read round-0-initial-proposal.md)
   "review"	Phase 2 or 4 done	Phase 3 (read latest round-N-review.md)
   "refine"	Phase 3 done	Phase 4 (read latest round-N-refinement.md)

3. On fresh start, ensure output/refine-logs/ directory exists and proceed to Phase 0.

Phase 0: Freeze the Problem Anchor

Step 0.1: Source the Input

Before extracting the anchor, decide what material is available:

• Read output/IDEA_REPORT.md (produced by generate-idea) if it exists.
• Read output/LIT_REVIEW_REPORT.md (produced by lit-review) if it exists.
• If both exist: use them as the primary source for problem framing, technical gap, and grounding literature. $ARGUMENTS is treated as an optional filter / pointer to which candidate idea to refine (if IDEA_REPORT.md contains multiple). Steps 1.1 and 1.2 are skipped — the gap and grounding material are already captured.
• If only one exists: read it and still skip the step it covers (IDEA_REPORT → covers Step 1.2; LIT_REVIEW_REPORT → covers Step 1.1). Perform the other step.
• If neither exists: focus on $ARGUMENTS as the sole input and run Phase 1 in full.

Record which source was used at the top of ROUND_0_INITIAL_PROPOSAL.md.

Step 0.2: Extract the Anchor

Before proposing anything, extract the user's immutable bottom-line problem. This anchor must be copied verbatim into every proposal and every refinement round.

Write:

• Bottom-line problem: What technical problem must be solved?
• Must-solve bottleneck: What specific weakness in current methods is unacceptable?
• Non-goals: What is explicitly not the goal of this project?
• Constraints: Compute, data, time, tooling, venue, deployment limits.
• Success condition: What evidence would make the user say "yes, this method addresses the actual problem"?

If later reviewer feedback would change the problem being solved, mark that as drift and push back or adapt carefully.

Checkpoint: Write output/refine-logs/REFINE_STATE.json with {"phase": "anchor", "round": 0, "threadId": null, "last_score": null, "last_verdict": null, "status": "in_progress", "timestamp": "<now>"}.

Phase 1: Build the Initial Proposal

Step 1.1: Scan Grounding Material

Skip this step if output/LIT_REVIEW_REPORT.md was read in Step 0.1 — its Synthesis section already provides grounding. Pull any additional details only if the review report is silent on a specific mechanism.

Check papers/ first. Read only the relevant parts needed to answer:

• What mechanism do current methods use?
• Where exactly do they fail for this problem?
• What training objectives, representations, or interfaces are reusable?
• What details distinguish a real method from a renamed high-level idea?

If local material is insufficient, search recent top-venue/arXiv work online. Focus on method sections, training setup, and failure modes, not just abstracts.

Step 1.2: Identify the Technical Gap

Skip this step if output/IDEA_REPORT.md was read in Step 0.1 — the selected idea already names the technical gap, bottleneck, and core claim. Lift them directly into the proposal (Method Thesis, Contribution Focus, Core Mechanism) and proceed to Step 1.3.

Do not stop at generic research questions. Make the gap operational:

1. Current pipeline failure point: where does the baseline break?
2. Why naive fixes are insufficient: larger context, more data, prompting, memory bank, or stacking more modules.
3. Smallest adequate intervention: what is the least additional mechanism that could plausibly fix the bottleneck?
4. Frontier-native alternative: is there a more current route using foundation-model-era primitives that better matches the bottleneck?
5. Core technical claim: what exact mechanism claim could survive top-venue scrutiny?
6. Required evidence: what minimum proof is needed to defend that claim?

Step 1.3: Choose the Sharpest Route

Before locking the method, compare two candidate routes if both are plausible:

• Route A: Elegant minimal route — the smallest mechanism that directly targets the bottleneck.
• Route B: Frontier-native route — a more modern route that uses Deep learning / LLM / VLM / Diffusion / RL / distillation / inference-time scaling only if it gives a cleaner or stronger story.

Then decide:

• Which route is more likely to become a strong paper under the stated constraints?
• Which route has the cleaner novelty story relative to the closest work?
• Which route avoids contribution sprawl?

If both routes are weak, rethink the framing instead of combining them into a larger system by default.

Step 1.4: Concretize the Method First

The proposal must answer "how would we actually build this?" Prefer method detail over broad experimentation and prefer reuse over invention.

Cover:

1. One-sentence method thesis: the single strongest mechanism claim.
2. Contribution focus: one dominant contribution and at most one supporting contribution.
3. Complexity budget: what is frozen or reused, what is new, and what tempting additions are intentionally excluded.
4. System graph: modules, data flow, inputs, outputs.
5. Representation design: what latent, embedding, plan token, reward signal, memory state, or alignment space is used?
6. Training recipe: data source, supervision, pseudo-labeling, negatives, curriculum, losses, weighting, stagewise vs joint training.
7. Inference path: how the trained components are used at test time and what signals flow where.
8. Why the mechanism stays small: why a larger stack is unnecessary.
9. Exact role of any frontier primitive: if you use an LLM / VLM / Diffusion / RL component, specify whether it acts as planner, teacher, critic, reward model, generator prior, search controller, or distillation source.
10. Failure handling: what could go wrong and what fallback or diagnostic exists?
11. Novelty and elegance argument: why this is more than naming a module and why the paper still looks focused.

If the method is still only described as "add a module" or "use a planner," it is not concrete enough.

Step 1.5: Design Minimal Claim-Driven Validation

Experiments exist to validate the method, not to dominate the document.

For each core claim, define the smallest strong experiment that can validate it. Every claim must be specified concretely enough that /experiment-design can turn it into a run plan without re-deriving scope.

Required fields per claim:

• Claim statement — the exact mechanism-level assertion
• Anti-claim to rule out — the alternative explanation a skeptical reviewer would reach for (e.g. "gain only comes from more parameters," "works only because of data leakage," "modern primitive is decorative")
• Dataset / split / task — named benchmark(s), splits, and the task formulation
• Baseline family — the single strongest comparison, plus the one ablation that isolates the contribution (avoid padded baseline lists)
• Decisive metric — the one metric that decides the claim; secondary metrics are optional
• Success criterion — the directional + magnitude outcome that would make the claim believable (e.g. "≥ 2 points on metric X under matched compute")
• Failure interpretation — what a negative result would mean for the paper
• Stochastic variance handling — seeds or confidence protocol if randomness matters
• Compute envelope — order-of-magnitude GPU-hours so the handoff is realistic

Additional rules:

• Every claim must have an anti-claim. Claims without an anti-claim cannot be experimentally isolated.
• Ensure one experiment block directly supports the Problem Anchor — mark it as the anchor block.
• If complexity risk exists, include one simplification or deletion check (compare final method against an overbuilt variant the paper intentionally rejects).
• If a frontier primitive is central, include one necessity check (compare the chosen primitive against the strongest plausible simpler or older alternative).
• Default to 1-3 core claims and leave the full execution roadmap to /experiment-design.

Step 1.6: Write the Initial Proposal

Save to output/refine-logs/ROUND_0_INITIAL_PROPOSAL.md.

Use this structure:

# Research Proposal: [Title]

## Problem Anchor
- Bottom-line problem:
- Must-solve bottleneck:
- Non-goals:
- Constraints:
- Success condition:

## Technical Gap
[Why current methods fail, why naive bigger systems are not enough, and what mechanism is missing]

## Method Thesis
- One-sentence thesis:
- Why this is the smallest adequate intervention:
- Why this route is timely:

## Contribution Focus
- Dominant contribution:
- Optional supporting contribution:
- Explicit non-contributions:

## Proposed Method
### Complexity Budget


### System Overview
[Step-by-step pipeline or ASCII graph]

### Core Mechanism
- Input / output:
- Architecture or policy:
- Why this is the main novelty:

### Optional Supporting Component
- Only include if truly necessary:


### Modern Primitive Usage
- Which LLM / VLM / Diffusion / RL-era primitive is used:
- Exact role in the pipeline:
- Why it is more natural than an old-school alternative:

### Integration into Base Generator / Downstream Pipeline
[Where the new method attaches, what is frozen, what is trainable, inference order]

### Training Plan
[Stagewise or joint training, losses, data construction, pseudo-labels, schedules]

### Failure Modes and Diagnostics
- [Failure mode]:
- [How to detect]:
- [Fallback or mitigation]:

### Novelty and Elegance Argument
[Closest work, exact difference, why this is a focused mechanism-level contribution rather than a module pile-up]

## Claim-Driven Validation Sketch

### Claim 1 (ANCHOR): [Main claim statement]
- Anti-claim to rule out:
- Dataset / split / task:
- Baseline family (1 strongest) + isolating ablation:
- Decisive metric:
- Success criterion (direction + magnitude):
- Failure interpretation:
- Seeds / variance protocol:
- Compute envelope (order-of-magnitude GPU-hours):

### Claim 2: [Optional supporting claim]
- Anti-claim to rule out:
- Dataset / split / task:
- Baseline family (1 strongest) + isolating ablation:
- Decisive metric:
- Success criterion (direction + magnitude):
- Failure interpretation:
- Seeds / variance protocol:
- Compute envelope:

### Simplicity / Deletion Check (required if complexity risk exists)
- Overbuilt variant being ruled out:
- Comparison setup:
- Decisive metric and success criterion:

### Frontier Necessity Check (required if a frontier primitive is central)
- Simpler / older alternative being compared:
- Comparison setup:
- Decisive metric and success criterion:

## Experiment Design Handoff

Everything `/experiment-design` needs to build the roadmap without re-deriving scope:

- **Anchor claim ID:**
- **Must-prove claims (ordered):**
- **Must-run ablations:**
- **Critical datasets / splits / metrics:**
- **Strongest baseline family per claim:**
- **Central frontier primitive (or "none"):**
- **Highest-risk assumptions:**
- **Hard constraints** (compute cap, data access, annotation limits, deadlines):
- **Nice-to-have vs must-run boundary:**

## Compute & Timeline Estimate
- Estimated GPU-hours:
- Data / annotation cost:
- Timeline:

Checkpoint: Update output/refine-logs/REFINE_STATE.json with {"phase": "proposal", "round": 0, ...}.

Phase 2: External Method Review (Round 1)

Send the full proposal to GPT-5.4 for an elegance-first, frontier-aware, method-first review. The reviewer should spend most of the critique budget on the method itself, not on expanding the experiment menu.

mcp__codex__codex:
  model: REVIEWER_MODEL
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are a senior ML reviewer for a top venue (NeurIPS/ICML/ICLR).
    This is an early-stage, method-first research proposal.

    Your job is NOT to reward extra modules, contribution sprawl, or a giant benchmark checklist.
    Your job IS to stress-test whether the proposed method:
    (1) still solves the original anchored problem,
    (2) is concrete enough to implement,
    (3) presents a focused, elegant contribution,
    (4) uses foundation-model-era techniques appropriately when they are the natural fit.

    Review principles:
    - Prefer the smallest adequate mechanism over a larger system.
    - Penalize parallel contributions that make the paper feel unfocused.
    - If a modern LLM / VLM / Diffusion / RL route would clearly produce a better paper, say so concretely.
    - If the proposal is already modern enough, do NOT force trendy components.
    - Do not ask for extra experiments unless they are needed to prove the core claims.

    Read the Problem Anchor first. If your suggested fix would change the problem being solved,
    call that out explicitly as drift instead of treating it as a normal revision request.

    === PROPOSAL ===
    [Paste the FULL proposal from Phase 1]
    === END PROPOSAL ===

    Score these 7 dimensions from 1-10:

    1. **Problem Fidelity**: Does the method still attack the original bottleneck, or has it drifted into solving something easier or different?

    2. **Method Specificity**: Are the interfaces, representations, losses, training stages, and inference path concrete enough that an engineer could start implementing?

    3. **Contribution Quality**: Is there one dominant mechanism-level contribution with real novelty, good parsimony, and no obvious contribution sprawl?

    4. **Frontier Leverage**: Does the proposal use current foundation-model-era primitives appropriately when they are the right tool, instead of defaulting to old-school module stacking?

    5. **Feasibility**: Can this method be trained and integrated with the stated resources and data assumptions?

    6. **Validation Focus**: Are the proposed experiments minimal but sufficient to validate the core claims? Is there unnecessary experimental bloat?

    7. **Venue Readiness**: If executed well, would the contribution feel sharp and timely enough for a top venue?

    **OVERALL SCORE** (1-10): Weighted toward Problem Fidelity, Method Specificity, Contribution Quality, and Frontier Leverage.
    Use this weighting: Problem Fidelity 15%, Method Specificity 25%, Contribution Quality 25%, Frontier Leverage 15%, Feasibility 10%, Validation Focus 5%, Venue Readiness 5%.

    For each dimension scoring < 7, provide:
    - The specific weakness
    - A concrete fix at the method level (interface / loss / training recipe / integration point / deletion of unnecessary parts)
    - Priority: CRITICAL / IMPORTANT / MINOR

    Then add:
    - **Simplification Opportunities**: 1-3 concrete ways to delete, merge, or reuse components while preserving the main claim. Write "NONE" if already tight.
    - **Modernization Opportunities**: 1-3 concrete ways to replace old-school pieces with more natural foundation-model-era primitives if genuinely better. Write "NONE" if already modern enough.
    - **Drift Warning**: "NONE" if the proposal still solves the anchored problem; otherwise explain the drift clearly.
    - **Verdict**: READY / REVISE / RETHINK

    Verdict rule:
    - READY: overall score >= 9, no meaningful drift, one focused dominant contribution, and no obvious complexity bloat remains
    - REVISE: the direction is promising but not yet at READY bar
    - RETHINK: the core mechanism or framing is still fundamentally off

If the external reviewer model is not configured correctly, use Claude Code subagent instead.

CRITICAL: Save the threadId from this call for all later rounds.

CRITICAL: Save the FULL raw response verbatim.

Save review to output/refine-logs/ROUND_1_REVIEW.md with the raw response in a <details> block.

Checkpoint: Update output/refine-logs/REFINE_STATE.json with {"phase": "review", "round": 1, "threadId": "<saved>", "last_score": <parsed>, "last_verdict": "<parsed>", ...}.

Phase 3: Parse Feedback and Revise the Method

Step 3.1: Parse the Review

Extract:

• Problem Fidelity
• Method Specificity
• Contribution Quality
• Frontier Leverage
• Feasibility
• Validation Focus
• Venue Readiness
• Overall score
• Verdict
• Drift Warning
• Simplification Opportunities
• Modernization Opportunities
• Action items ranked by priority

Update output/refine-logs/SCORE_HISTORY.md:

# Score Evolution

| Round | Problem Fidelity | Method Specificity | Contribution Quality | Frontier Leverage | Feasibility | Validation Focus | Venue Readiness | Overall | Verdict |
|-------|------------------|--------------------|----------------------|-------------------|-------------|------------------|-----------------|---------|---------|
| 1     | X                | X                  | X                    | X                 | X           | X                | X               | X       | REVISE  |

STOP CONDITION: If overall score >= SCORE_THRESHOLD, verdict is READY, and there is no unresolved drift warning, skip to Phase 5.

Step 3.2: Revise With an Anchor Check and a Simplicity Check

Before changing anything:

1. Copy the Problem Anchor verbatim.
2. Write an Anchor Check:
   • What is the original bottleneck?
   • Does the current method still solve it?
   • Which reviewer suggestions would cause drift if followed blindly?
3. Write a Simplicity Check:
   • What is the dominant contribution now?
   • What components can be removed, merged, or kept frozen?
   • Which reviewer suggestions add unnecessary complexity?
   • If a frontier primitive is central, is its role still crisp and justified?

Then process reviewer feedback:

• If valid: sharpen the mechanism, simplify if possible, or modernize if the paper really improves.
• If debatable: revise, but explain your reasoning with evidence.
• If wrong, drifting, or over-complicating: push back with evidence from local papers and the Problem Anchor.

Bias the revisions toward:

• a sharper central contribution
• fewer moving parts
• cleaner reuse of strong existing backbones
• more natural foundation-model-era leverage when it improves the paper
• leaner, claim-driven experiments

Do not add multiple parallel contributions just to chase score. If the reviewer requests another module, first ask whether the same gain can come from a better interface, distillation signal, reward model, or inference policy on top of an existing backbone.

Save to output/refine-logs/ROUND_N_REFINEMENT.md:

# Round N Refinement

## Problem Anchor
[Copy verbatim from round 0]

## Anchor Check
- Original bottleneck:
- Why the revised method still addresses it:
- Reviewer suggestions rejected as drift:

## Simplicity Check
- Dominant contribution after revision:
- Components removed or merged:
- Reviewer suggestions rejected as unnecessary complexity:
- Why the remaining mechanism is still the smallest adequate route:

## Changes Made

### 1. [Method section changed]
- Reviewer said:
- Action:
- Reasoning:
- Impact on core method:

### 2. [Novelty / modernity / feasibility / validation change]
- Reviewer said:
- Action:
- Reasoning:
- Impact on core method:

## Revised Proposal
[Full updated proposal from Problem Anchor through Claim-Driven Validation Sketch **and** the Experiment Design Handoff block. Every claim must still carry: anti-claim, dataset/split/task, baseline family, decisive metric, success criterion, failure interpretation. Do not drop these fields when revising.]

Checkpoint: Update output/refine-logs/REFINE_STATE.json with {"phase": "refine", "round": N, ...}.

Phase 4: Re-evaluation (Round 2+)

Send the revised proposal back to GPT-5.4 in the same thread:

mcp__codex__codex-reply:
  threadId: [saved from Phase 2]
  model: REVIEWER_MODEL
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    [Round N re-evaluation]

    I revised the proposal based on your feedback.
    First, check whether the original Problem Anchor is still preserved.
    Second, judge whether the method is now more concrete, more focused, and more current.

    Key changes:
    1. [Method change 1]
    2. [Method change 2]
    3. [Simplification / modernization / pushback if any]

    === REVISED PROPOSAL ===
    [Paste the FULL revised proposal]
    === END REVISED PROPOSAL ===

    Please:
    - Re-score the same 7 dimensions and overall
    - State whether the Problem Anchor is preserved or drifted
    - State whether the dominant contribution is now sharper or still too broad
    - State whether the method is simpler or still overbuilt
    - State whether the frontier leverage is now appropriate or still old-school / forced
    - Focus new critiques on missing mechanism, weak training signal, weak integration point, pseudo-novelty, or unnecessary complexity
    - Use the same verdict rule: READY only if overall score >= 9 and no blocking issue remains

    Same output format: 7 scores, overall score, verdict, drift warning, simplification opportunities, modernization opportunities, remaining action items.

Save review to output/refine-logs/ROUND_N_REVIEW.md.

Checkpoint: Update output/refine-logs/REFINE_STATE.json with {"phase": "review", "round": N, "threadId": "<saved>", "last_score": <parsed>, "last_verdict": "<parsed>", ...}.

Then return to Phase 3 until:

• Overall score >= SCORE_THRESHOLD and verdict is READY and no unresolved drift
• or MAX_ROUNDS reached

Phase 5: Final Report and Logs

Step 5.1: Write output/refine-logs/FINAL_PROPOSAL.md

This file is the clean, experiment-design-ready version of the proposal. It should contain no review chatter, no round history, no raw reviewer output — only the final method and the information /experiment-design needs to build a claim-driven roadmap.

Readiness gate: before saving, verify every section below has content. If any of these are blank, the handoff will fail:

• Problem Anchor (bottleneck + success condition)
• Method thesis + dominant contribution
• System overview + core mechanism + training/inference recipe
• Each claim has: anti-claim, dataset, baseline family, decisive metric, success criterion, failure interpretation
• At least one anchor claim is tagged
• Experiment Design Handoff section is fully populated

Use this structure:

# Research Proposal: [Title]

**Status**: [READY / REVISE / RETHINK]
**Final Score**: X / 10
**Anchor Preserved**: [yes / corrected / unresolved]

## Problem Anchor
- Bottom-line problem:
- Must-solve bottleneck:
- Non-goals:
- Constraints:
- Success condition:

## Method Thesis
- One-sentence thesis:
- Dominant contribution:
- Optional supporting contribution:
- Explicit non-contributions:
- Why this is the smallest adequate intervention:

## Proposed Method
### Complexity Budget
[What is frozen/reused, what is new, what was intentionally rejected]

### System Overview
[Step-by-step pipeline or ASCII graph; named modules]

### Core Mechanism
- Input / output:
- Architecture or policy:
- Representation / interface design:
- Why this is the main novelty:

### Modern Primitive Usage
- Which LLM / VLM / Diffusion / RL-era primitive (or "none"):
- Exact role (planner / teacher / critic / reward model / generator prior / search controller / distillation source):
- Why it is more natural than the strongest simpler alternative:

### Integration Point
- Where the new method attaches:
- Frozen vs trainable components:
- Inference order:

### Training Recipe
- Data source + supervision signal:
- Pseudo-labels / negatives / curriculum (if any):
- Losses + weighting:
- Stagewise vs joint training:
- Key hyperparameters:

### Failure Modes and Diagnostics
- [Failure mode] → [Detection signal] → [Fallback or mitigation]

### Novelty and Elegance Argument
- Closest prior work:
- Exact mechanism-level delta:
- Why this remains a focused contribution rather than a module pile-up:

## Claim-Driven Validation

### Claim C1 (ANCHOR): [Main claim]
- Anti-claim to rule out:
- Dataset / split / task:
- Baseline family (1 strongest) + isolating ablation:
- Decisive metric:
- Success criterion (direction + magnitude):
- Failure interpretation:
- Seeds / variance protocol:
- Compute envelope (GPU-hours order):

### Claim C2 (optional supporting): [Claim]
- [Same fields]

### Simplicity / Deletion Check (if applicable)
- Overbuilt variant ruled out:
- Comparison setup + decisive metric + success criterion:

### Frontier Necessity Check (if applicable)
- Simpler / older alternative compared:
- Comparison setup + decisive metric + success criterion:

## Experiment Design Handoff

This section is the contract `/experiment-design` will consume. Keep it self-contained.

- **Anchor claim ID:** C1
- **Must-prove claims (ordered by priority):**
- **Must-run ablations:**
- **Critical datasets / splits / metrics:**
- **Strongest baseline family per claim:**
- **Central frontier primitive (or "none"):**
- **Highest-risk assumptions (things that could invalidate the plan):**
- **Hard constraints:**
  - Compute cap:
  - Data access / licensing:
  - Annotation or human-eval limits:
  - Deadlines / venue targets:
- **Must-run vs nice-to-have boundary:**
- **Known evaluation pitfalls to avoid** (leakage, metric mismatch, unmatched compute, train-test overlap):

## Compute & Timeline Estimate
- Estimated total GPU-hours (main method + baselines + ablations):
- Data / annotation cost:
- Timeline (weeks to each milestone):
- Biggest bottleneck:

## Open Weaknesses
[Honest list of unresolved concerns the downstream experiment plan should explicitly address or accept.]

If the final verdict is not READY, still write the best current final version here and leave Open Weaknesses frank — /experiment-design needs to know what is shaky.

Step 5.2: Write output/refine-logs/REFINE_REPORT.md

This is the single consolidated report. It merges the round-by-round review record, the refinement summary, and the drift/pushback log that previously lived in a separate REVIEW_SUMMARY.md.

# Refinement Report

**Problem**: [user's problem]
**Initial Approach**: [user's vague approach]
**Input Source**: [IDEA_REPORT.md + LIT_REVIEW_REPORT.md / IDEA_REPORT.md only / LIT_REVIEW_REPORT.md only / $ARGUMENTS]
**Date**: [today]
**Rounds**: N / MAX_ROUNDS
**Final Score**: X / 10
**Final Verdict**: [READY / REVISE / RETHINK]

## Problem Anchor
[Verbatim anchor used across all rounds]

## Output Files
- Final proposal: `output/refine-logs/FINAL_PROPOSAL.md`
- Score history: `output/refine-logs/SCORE_HISTORY.md`

## Score Evolution

| Round | Problem Fidelity | Method Specificity | Contribution Quality | Frontier Leverage | Feasibility | Validation Focus | Venue Readiness | Overall | Verdict |
|-------|------------------|--------------------|----------------------|-------------------|-------------|------------------|-----------------|---------|---------|
| 1     | ...              | ...                | ...                  | ...               | ...         | ...              | ...             | ...     | ...     |

## Round-by-Round Resolution Log

| Round | Main Reviewer Concerns | What This Round Simplified / Modernized | Solved? | Remaining Risk |
|-------|-------------------------|------------------------------------------|---------|----------------|
| 1     | [top issues from review] | [main method changes]                    | [yes / partial / no] | [if any] |
| 2     | ...                     | ...                                      | ...     | ...            |

## Overall Evolution
- [How the method became more concrete]
- [How the dominant contribution became more focused]
- [How unnecessary complexity was removed]
- [How modern technical leverage improved or stayed intentionally minimal]
- [How drift was avoided or corrected]

## Final Status
- Anchor status: [preserved / corrected / unresolved]
- Focus status: [tight / slightly broad / still diffuse]
- Modernity status: [appropriately frontier-aware / intentionally conservative / still old-school]
- Strongest parts of final method:
- Remaining weaknesses:

## Final Proposal Snapshot
- Canonical clean version lives in `output/refine-logs/FINAL_PROPOSAL.md`
- Summarize the final thesis in 3-5 bullets here

## Method Evolution Highlights
1. [Most important simplification or focusing move]
2. [Most important mechanism upgrade]
3. [Most important modernization or justification for staying simple]

## Pushback / Drift Log
| Round | Reviewer Said | Author Response | Outcome |
|-------|---------------|-----------------|---------|
| 1     | [criticism]   | [pushback + anchor / evidence] | [accepted / rejected] |

## Remaining Weaknesses
[Honest unresolved issues]

## Raw Reviewer Responses

<details>
<summary>Round 1 Review</summary>

[Full verbatim response from GPT-5.4]

</details>

...

## Next Steps
- If READY: proceed to `/experiment-design` for a full experiment roadmap, then `/deploy-experiment`
- If REVISE: manually address the remaining mechanism weaknesses, then re-run `/refine-research`
- If RETHINK: revisit the core mechanism, possibly with `/generate-idea`

Step 5.3: Finalize output/refine-logs/SCORE_HISTORY.md

Ensure it contains the complete score evolution table using the new dimensions.

Step 5.4: Present a Brief Summary to the User

Refinement complete after N rounds.

Final score: X/10 (Verdict: READY / REVISE / RETHINK)

Anchor status:
- [preserved / drift corrected / unresolved concern]

Focus status:
- [tight / slightly broad / still diffuse]

Modernity status:
- [appropriately frontier-aware / intentionally conservative / still old-school]

Key method upgrades:
- [method change 1]
- [method change 2]

Remaining concerns:
- [if any]

Full report: output/refine-logs/REFINE_REPORT.md
Final proposal: output/refine-logs/FINAL_PROPOSAL.md
Suggested next step: /experiment-plan

Checkpoint: Update output/refine-logs/REFINE_STATE.json with {"phase": "done", "status": "completed", ...}.

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.

• Anchor first, every round. Always carry forward the same Problem Anchor.

• One paper, one dominant contribution. Avoid multiple parallel contributions unless the paper truly needs them.

• The smallest adequate mechanism wins. Bigger is not automatically better.

• Prefer reuse over invention. Start from strong existing backbones and add only what the bottleneck requires.

• Modern techniques are a prior, not a decoration. Use LLM / VLM / Diffusion / RL-era components when they sharpen the method, not when they only make the proposal sound trendy.

• Minimal experiments, maximal specificity. Inside this skill, experiments only need to prove the core claims — but each claim must carry anti-claim, dataset, baseline family, decisive metric, success criterion, and failure interpretation so /experiment-design can build the roadmap without re-deriving scope.

• Handoff is a hard gate. FINAL_PROPOSAL.md must include a fully populated Experiment Design Handoff section. A proposal that cannot be handed off has not actually been refined.

• Review the mechanism, not the parts count. A long module list is not novelty.

• Pushback is encouraged. If reviewer feedback causes drift or unnecessary complexity, argue back with evidence.

• ALWAYS use config: {"model_reasoning_effort": "xhigh"} for all Codex review calls.

• Save threadId from Phase 2 and use mcp__codex__codex-reply for later rounds.

• Do not fabricate results. Only describe expected evidence and planned experiments.

• Be specific about compute and data assumptions. Vague "we'll train a model" is not enough.

• Document everything. Save every raw review, every anchor check, every simplicity check, and every major method change.

Composing with Other Skills

This skill sits between idea discovery and execution:

/experiment-design-pipeline              -> one-shot refine + experiment planning
/generate-idea "direction/topic"       -> candidate ideas
/refine-research "PROBLEM: ... | APPROACH: ..."  <- you are here
/experiment-design                -> detailed experiment roadmap
/deploy-experiment                 -> execute the chosen method
/auto-review-loop               -> iterate on results and paper

Typical flow:

1. /generate-idea or local reading gives you a problem and a vague method direction
2. /refine-research turns that into an anchored, elegant, frontier-aware method plan
3. /experiment-design turns the final proposal into a detailed claim-driven experiment roadmap
4. /experiment-design-pipeline is the one-shot wrapper when the user wants both stages in a single request
5. /deploy-experiment executes the chosen runs
6. Later loops operate on results, not just ideas

This skill also works standalone if you already know the problem and just need the method to become concrete.