Override for Codex users who want Gemini, not a second Codex agent, to act as the reviewer. Install this package after skills/skills-codex/*.
Robotics Idea Discovery Pipeline
Orchestrate a robotics-specific idea discovery workflow for: $ARGUMENTS
Overview
This skill chains four sub-skills into a single automated pipeline:
/research-lit → /idea-creator (robotics framing) → /novelty-check → /research-review
(survey) (filter + pilot plan) (verify novel) (critical feedback)
But every phase must be grounded in robotics-specific constraints:
- 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
The goal is not to produce flashy demos. The goal is to produce ideas that are:
- benchmarkable
- falsifiable
- feasible with available robotics infrastructure
- interesting even if the answer is negative
Constants
- 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 =
gemini-review— External reviewer route via the localgemini-reviewMCP bridge - 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 robotor/idea-discovery-robot "drone navigation" — focus on CoRL/RSS, 2 pilot ideas max
Execution Rule
Follow the phases in order. Do not stop after a checkpoint unless:
- the user explicitly says to stop, or
- the user asks to change scope and re-run an earlier phase
If AUTO_PROCEED=true and the user does not respond, continue immediately to the next phase using the strongest sim-first, benchmark-grounded option.
Phase 0: Frame the Robotics Problem
Before generating ideas, extract or infer this Robotics Problem Frame from $ARGUMENTS and local project context:
- 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
If some fields are missing, make explicit assumptions and default to:
- simulation-first
- public benchmark preferred
- no real robot execution
Write this frame into working notes before moving on. Every later decision should reference it.
Phase 1: Robotics Literature Survey
Invoke:
/research-lit "$ARGUMENTS — focus venues: CoRL, RSS, ICRA, IROS, RA-L, TRO, Science Robotics"
Then reorganize the findings using a robotics lens instead of a generic ML lens.
Build a Robotics Landscape Matrix
For each relevant paper, classify:
| Axis | Examples | |------|----------| | Embodiment | single-arm, mobile manipulator, humanoid, drone, quadruped | | Task | pick-place, insertion, navigation, locomotion, long-horizon rearrangement | | Learning setup | RL, BC, IL, offline RL, world model, planning, diffusion policy | | Observation | RGB, RGB-D, proprioception, tactile, language | | Action abstraction | torque, joint velocity, end-effector delta pose, waypoint planner | | Eval regime | pure sim, sim+real, real-only, offline benchmark | | Benchmark | ManiSkill, RLBench, Isaac Lab, Habitat, Meta-World, CALVIN, LIBERO, custom | | Metrics | success rate, collision rate, intervention count, path length, latency, energy | | Main bottleneck | sample inefficiency, brittleness, reset cost, perception drift, sim2real gap |
Search Priorities
When refining the survey, prioritize:
- 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
What to Look For
Do not stop at "who got the best success rate." Explicitly identify:
- 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
Checkpoint: Present the landscape to the user in robotics terms:
🤖 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.
Phase 2: Robotics-Specific Idea Generation and Filtering
Generate ideas only after the robotics frame is explicit.
Invoke the existing idea generator, but pass the Robotics Problem Frame and landscape matrix into the prompt so it does not produce generic ML ideas:
/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"
Then rewrite and filter the output using the robotics-specific rules below.
Each candidate idea must include:
- 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
Good Robotics Idea Patterns
Prefer ideas that:
- 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
Weak Robotics Idea Patterns
Downrank ideas that are mostly:
- "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
Filtering Rules
For each idea, reject or heavily downrank if: -