/idea-discovery-robot

name: idea-discovery-robot
description: "Workflow 1 adaptation for robotics and embodied AI. Orchestrates robotics-aware literature survey, idea generation, novelty check, and critical review to go from a broad robotics direction to benchmark-grounded, simulation-first ideas. Use when user says \"robotics idea discovery\", \"机器人找idea\", \"embodied AI idea\", \"机器人方向探索\", \"sim2real 选题\", or wants ideas for manipulation, locomotion, navigation, drones, humanoids, or general robot learning."
argument-hint: "[robotics-direction]"
allowed-tools: Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch, Skill, mcp__codex__codex, mcp__codex__codex-reply

Robotics Idea Discovery Pipeline

> **Before each reviewer slot**, follow [Selectable Reviewers](../shared-references/reviewer-backends.md): > resolve invocation → `.aris/reviewer.json` → Claude Code default (Codex MCP) > with `reviewer_route.py` through the canonical helper resolver, preserving this > slot's tier, fresh contexts, source/image inputs and deterministic gates. > Codex examples/pins below apply only to `backend=codex`; other routes use their > own first-call/reply contract. Save the route and actual returned identity; > unavailable selections are `REVIEW_UNAVAILABLE`. Classify acceptance from actual > families/completion/scope. Forward invocation reviewer/model/effort overrides > to reviewer-bearing children. Generation workers are unchanged.

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 = `gpt-6-astra`** — 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`

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, prioritiz