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 refine-logs/
  -> Optional handoff: /experiment-plan for a detailed execution-ready experiment roadmap

• 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 =

  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.

/research-refine "problem | approach" -- max rounds: 3, threshold: 9

.

• 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"?

papers/

literature/

• What mechanism do current methods use?
• Where exactly do they fail for this problem?
• Which recent LLM / VLM / Diffusion / RL era techniques are actually relevant here?
• What training objectives, representations, or interfaces are reusable?
• What details distinguish a real method from a renamed high-level idea?

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?

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

• 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?

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.

• the claim being tested
• the necessary baseline or ablation
• the decisive metric
• the expected directional outcome

• Ensure one experiment block directly supports the Problem Anchor.
• If complexity risk exists, include one simplification or deletion check.
• If a frontier primitive is central, include one necessity check showing why that choice matters.
• Default to 1-3 core experiment blocks and leave the full execution roadmap to

  /experiment-plan

  .

• Bottom-line problem:
• Must-solve bottleneck:
• Non-goals:
• Constraints:
• Success condition:

• One-sentence thesis:
• Why this is the smallest adequate intervention:
• Why this route is timely in the foundation-model era:

• Dominant contribution:
• Optional supporting contribution:
• Explicit non-contributions:

• Frozen / reused backbone:
• New trainable components:
• Tempting additions intentionally not used:

• Input / output:
• Architecture or policy:
• Training signal / loss:
• Why this is the main novelty:

• Only include if truly necessary:
• Input / output:
• Training signal / loss:
• Why it does not create contribution sprawl:

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

• [Failure mode]:
• [How to detect]:
• [Fallback or mitigation]:

• Minimal experiment:
• Baselines / ablations:
• Metric:
• Expected evidence:

• Minimal experiment:
• Baselines / ablations:
• Metric:
• Expected evidence:

• Must-prove claims:
• Must-run ablations:
• Critical datasets / metrics:
• Highest-risk assumptions:

• Estimated GPU-hours:
• Data / annotation cost:
• Timeline:

undefined

• 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

refine-logs/score-history.md

undefined

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?

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

• 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

refine-logs/round-N-refinement.md

undefined

• Original bottleneck:
• Why the revised method still addresses it:
• Reviewer suggestions rejected as drift:

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

• Reviewer said:
• Action:
• Reasoning:
• Impact on core method:

• Reviewer said:
• Action:
• Reasoning:
• Impact on core method:

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.

refine-logs/round-N-review.md

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

• [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]

• 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:

undefined

• Review summary:

  refine-logs/REVIEW_SUMMARY.md

• Final proposal:

  refine-logs/FINAL_PROPOSAL.md

• Canonical clean version lives in

  refine-logs/FINAL_PROPOSAL.md

• Summarize the final thesis in 3-5 bullets here

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

• If READY: proceed to

  /experiment-plan

  for a full experiment roadmap, then

  /run-experiment

• If REVISE: manually address the remaining mechanism weaknesses, then re-run

  /research-refine

• If RETHINK: revisit the core mechanism, possibly with

  /idea-creator

undefined

• 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. Inside this skill, experiments only need to prove the core claims.
• 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.

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

1. /idea-creator

   or local reading gives you a problem and a vague method direction

2. /research-refine

   turns that into an anchored, elegant, frontier-aware method plan

3. /experiment-plan

   turns the final proposal into a detailed claim-driven experiment roadmap

4. /research-refine-pipeline

   is the one-shot wrapper when the user wants both stages in a single request

5. /run-experiment

   executes the chosen runs
6. Later loops operate on results, not just ideas