/research-lit → /idea-creator (robotics framing) → /novelty-check → /research-review
  (survey)              (filter + pilot plan)         (verify novel)    (critical feedback)

• Embodiment: arm, mobile manipulator, drone, humanoid, quadruped, autonomous car, etc.
• Task family: grasping, insertion, locomotion, navigation, manipulation, rearrangement, multi-step planning
• Observation + action interface: RGB/RGB-D/tactile/language; torque/velocity/waypoints/end-effector actions
• Simulator / benchmark availability: simulation-first by default
• Real robot constraints: hardware availability, reset cost, safety, operator time
• Evaluation quality: success rate plus failure cases, safety violations, intervention count, latency, sample efficiency
• Sim2real story: whether the idea can stay in sim, needs offline logs, or truly requires hardware

• benchmarkable
• falsifiable
• feasible with available robotics infrastructure
• interesting even if the answer is negative

• MAX_PILOT_IDEAS = 3 — Validate at most 3 top ideas deeply
• PILOT_MODE =

  sim-first

  — Prefer simulation or offline-log pilots before any hardware execution
• REAL_ROBOT_PILOTS =

  explicit approval only

  — Never assume physical robot access or approval
• AUTO_PROCEED = true — If user does not respond at checkpoints, proceed with the best sim-first option
• REVIEWER_MODEL =

  gpt-5.4

  — External reviewer model via Codex MCP
• TARGET_VENUES = CoRL, RSS, ICRA, IROS, RA-L — Default novelty and reviewer framing

Override inline, e.g.

/idea-discovery-robot "bimanual manipulation" — only sim ideas, no real robot

or

/idea-discovery-robot "drone navigation" — focus on CoRL/RSS, 2 pilot ideas max

• the user explicitly says to stop, or
• the user asks to change scope and re-run an earlier phase

AUTO_PROCEED=true

$ARGUMENTS

• Embodiment
• Task family
• Environment type: tabletop, warehouse, home, outdoor, aerial, driving, legged terrain
• Observation modalities
• Action interface / controller abstraction
• Learning regime: RL, imitation, behavior cloning, world model, planning, VLA/VLM, classical robotics, hybrid
• Available assets: simulator, benchmark suite, teleop data, offline logs, existing codebase, real hardware
• Compute budget
• Safety constraints
• Desired contribution type: method, benchmark, diagnosis, systems, sim2real, data curation

• simulation-first
• public benchmark preferred
• no real robot execution

• recent work from CoRL, RSS, ICRA, IROS, RA-L
• recent arXiv papers from the last 6-12 months
• benchmark papers and follow-up reproductions
• negative-result or diagnosis papers if they reveal system bottlenecks

• recurring failure modes papers do not fix
• benchmarks that are saturated or misleading
• places where embodiment changes invalidate prior conclusions
• methods that only work with privileged observations
• ideas whose reported gains come from reset engineering, reward shaping, or hidden infrastructure
• task families where evaluation quality is weak even if performance numbers look high

🤖 Robotics survey complete. I grouped the field by embodiment, benchmark, action interface, and sim2real setup.

Main gaps:
1. [...]
2. [...]
3. [...]

Should I generate ideas under this framing, or should I narrow to a specific robot / benchmark / modality?

• User approves (or no response + AUTO_PROCEED=true) → proceed to Phase 2 with the best robotics frame.
• User requests changes (e.g. narrower embodiment, different benchmark family, no sim2real, no hardware) → refine the robotics frame, re-run Phase 1, and present again.

/idea-creator "$ARGUMENTS — robotics frame: [paste Robotics Problem Frame] — focus venues: CoRL, RSS, ICRA, IROS, RA-L — benchmark-specific ideas only — sim-first pilots — no real-robot execution without explicit approval — require failure metrics and baseline clarity"

• One-sentence summary
• Target embodiment
• Target benchmark / simulator / dataset
• Core bottleneck being addressed
• Minimum sim-first pilot
• Mandatory metrics
• Expected failure mode if the idea does not work
• Whether the idea truly needs real hardware

• expose a real bottleneck in perception-action coupling
• improve robustness under embodiment or environment shift
• reduce operator time, reset cost, or demonstration cost
• strengthen sim2real transfer with measurable mechanisms
• improve recovery, retry behavior, or failure detection
• create a better benchmark, diagnostic, or evaluation protocol
• test an assumption the community repeats but rarely measures

• "apply a foundation model / VLM / diffusion model to robot X" with no new bottleneck analysis
• demo-driven but not benchmarkable
• dependent on inaccessible hardware, custom sensors, or massive private datasets
• impossible to evaluate without a months-long infrastructure build
• only interesting if everything works perfectly

• no concrete simulator or benchmark is available
• no credible baseline exists
• no measurable metric beyond "looks better"
• real robot execution is required but hardware access is unclear
• the setup depends on privileged observations that make the claim weak
• the expected contribution disappears if evaluation is made fair

💡 Robotics ideas generated. Top candidates:

1. [Idea 1] — Embodiment: [...] — Benchmark: [...] — Pilot: sim/offline — Risk: LOW/MEDIUM/HIGH
2. [Idea 2] — Embodiment: [...] — Benchmark: [...] — Pilot: sim/offline — Risk: LOW/MEDIUM/HIGH
3. [Idea 3] — requires hardware / weak benchmark / high risk

Should I carry the top sim-first ideas into novelty checking and external review?
(If no response, I'll continue with the strongest benchmark-grounded ideas.)

• User picks ideas (or no response + AUTO_PROCEED=true) → proceed to Phase 3 with the top sim-first ideas, then continue to Phase 4 and Phase 5.
• User wants different constraints → update the robotics frame and re-run Phase 2.
• User wants narrower scope → go back to Phase 1 with a tighter embodiment / task / benchmark focus.

• simulation pilot
• offline log / dataset pilot
• analysis-only pilot using existing benchmark outputs

- Embodiment:
- Benchmark / simulator:
- Baselines:
- Pilot type: sim / offline / real
- Compute estimate:
- Human/operator time:
- Success metrics:
- Failure metrics:
- Safety concerns:
- What result would count as positive signal:
- What negative result would still be publishable:

• mark it as

  needs physical validation

• design the sim or offline precursor first
• ask for explicit user confirmation before any real-robot step

/novelty-check "[idea description with embodiment + task family + benchmark + sensor stack + controller/policy class + sim2real angle + target venues: CoRL/RSS/ICRA/IROS/RA-L]"

• embodiment
• task family
• benchmark / simulator
• sensor stack
• controller / policy type
• sim2real or safety angle if relevant

• old method + new benchmark
• VLA/VLM + standard manipulation benchmark
• sim2real claim without new transfer mechanism

/research-review "[top idea with robotics framing, embodiment, benchmark, baselines, pilot plan, evaluation metrics, and sim2real/hardware risks — review as CoRL/RSS/ICRA reviewer]"

• whether the contribution is really new for robotics, not just ML
• the minimum benchmark package needed for credibility
• whether the sim2real story is justified
• missing baselines or failure analyses
• whether the idea survives realistic infrastructure constraints

• Embodiment:
• Task family:
• Observation / action interface:
• Available assets:
• Constraints:

• Embodiment:
• Benchmark / simulator:
• Bottleneck addressed:
• Pilot type: sim / offline / real
• Positive signal:
• Novelty:
• Reviewer score:
• Hardware risk:
• Next step:

• [idea] — killed because benchmark unclear / hardware inaccessible / novelty weak / no fair evaluation

• Required baselines:
• Required metrics:
• Required failure cases:
• Whether real robot evidence is mandatory:

• Implement sim-first pilot
• Run /novelty-check on the final idea wording
• Only after approval: consider hardware validation

undefined

• Simulation first. Hardware is never the default.
• Benchmark specificity is mandatory. No benchmark, no serious idea.
• Evaluation must include failures. Success rate alone is not enough.
• Embodiment matters. Do not assume a result on one robot transfers to another.
• Avoid foundation-model theater. Novel terminology is not novelty.
• Infrastructure realism matters. Operator time, reset burden, and safety count as research constraints.
• If the contribution is mainly diagnostic or evaluative, say so. That can still be publishable.