idea-discovery-robot

ロボティクスのアイデア発見パイプライン

各レビュアースロットの前に、選択可能なレビュアーに従ってください： 呼び出しの解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） reviewer_route.py を canonical helper resolver 経由で使用し、この スロットのティア、最新のコンテキスト、ソース／画像入力、決定論的ゲートを維持します。 以下の Codex の例／ピン留め設定は backend=codex の場合にのみ適用されます。それ以外のルートでは、 それぞれの初回呼び出し／返信コントラクトを使用します。ルートと実際に返された ID を保存してください。 利用できない選択肢は REVIEW_UNAVAILABLE です。受け入れの判定は、実際のファミリー／完了状況／スコープに基づいて行います。 レビュアーを含む子プロセスには、呼び出し時のレビュアー／モデル／エフォートのオーバーライドを渡してください。 生成ワーカーに変更はありません。

$ARGUMENTSを対象に、ロボティクスに特化したアイデア発見ワークフローを調整します。

概要

このスキルは、4つのサブスキルを単一の自動パイプラインにつなぎます：

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

ただし、各フェーズではロボティクス固有の制約を考慮する必要があります：

• 身体形態：アーム、移動マニピュレーター、ドローン、ヒューマノイド、四足歩行ロボット、自動運転車など
• タスクファミリー：把持、挿入、移動、ナビゲーション、操作、並べ替え、複数ステップの計画
• 観測＋アクションインターフェース：RGB／RGB-D／触覚／言語、トルク／速度／ウェイポイント／エンドエフェクターのアクション
• シミュレーター／ベンチマークの利用可能性：デフォルトではシミュレーションを優先
• 実機の制約：ハードウェアの利用可能性、リセットコスト、安全性、オペレーターの作業時間
• 評価の品質：成功率に加え、失敗事例、安全性違反、介入回数、レイテンシー、サンプル効率
• Sim2real の見通し：アイデアをシミュレーション内で完結できるか、オフラインログが必要か、本当にハードウェアが必要か

目標は、派手なデモを作ることではありません。目標は、以下を満たすアイデアを生み出すことです：

• ベンチマークで評価できる
• 反証可能である
• 利用可能なロボティクス基盤で実現できる
• 結果が否定的でも興味深い

定数

• MAX_PILOT_IDEAS = 3 — 深く検証する上位アイデアは最大3件
• PILOT_MODE = sim-first — ハードウェアで実行する前に、シミュレーションまたはオフラインログでの試験運用を優先
• REAL_ROBOT_PILOTS = explicit approval only — 物理ロボットの利用や承認があると決めつけない
• AUTO_PROCEED = true — チェックポイントでユーザーから応答がなければ、最善のシミュレーション優先案で続行
• REVIEWER_MODEL = gpt-6-astra — Codex MCP 経由の外部レビュアーモデル
• TARGET_VENUES = CoRL, RSS, ICRA, IROS, RA-L — 新規性の検討とレビュアー向けの位置づけに使うデフォルトの投稿先

インラインで上書きできます。例：/idea-discovery-robot "bimanual manipulation" — only sim ideas, no real robot または /idea-discovery-robot "drone navigation" — focus on CoRL/RSS, 2 pilot ideas max

実行ルール

フェーズを順番に進めてください。次の場合を除き、チェックポイントの後で停止しないでください：

• ユーザーが明示的に停止を指示した場合、または
• ユーザーがスコープの変更を求め、前のフェーズからの再実行を指示した場合

AUTO_PROCEED=true でユーザーから応答がない場合は、最も有力なシミュレーション優先で、ベンチマークに根ざした案を使って、直ちに次のフェーズへ進んでください。

フェーズ 0：ロボティクスの問題を定義する

アイデアを生成する前に、$ARGUMENTS とローカルプロジェクトのコンテキストから、以下のロボティクス問題フレームを抽出するか推定してください：

• 身体形態
• タスクファミリー
• 環境の種類：卓上、倉庫、家庭、屋外、空中、運転、脚式移動の地形
• 観測モダリティ
• アクションインターフェース／コントローラーの抽象化
• 学習レジーム：RL、模倣学習、行動クローニング、ワールドモデル、計画、VLA／VLM、古典的ロボティクス、ハイブリッド
• 利用可能な資産：シミュレーター、ベンチマークスイート、テレオペレーションデータ、オフラインログ、既存のコードベース、実機ハードウェア
• 計算予算
• 安全上の制約
• 希望する貢献の種類：手法、ベンチマーク、診断、システム、sim2real、データキュレーション

項目が欠けている場合は、仮定を明示し、以下をデフォルトにしてください：

• シミュレーション優先
• 公開ベンチマークを優先
• 実機での実行なし

次に進む前に、このフレームを作業メモに記録してください。以降のすべての判断で、このフレームを参照してください。

フェーズ 1：ロボティクス文献調査

次を実行します：

/research-lit "$ARGUMENTS — focus venues: CoRL, RSS, ICRA, IROS, RA-L, TRO, Science Robotics"

続いて、一般的な ML の視点ではなく、ロボティクスの視点で調査結果を整理します。

ロボティクス分野のマトリックスを作成する

関連する論文ごとに、次の項目に分類します：

軸	例
身体形態	単腕、移動マニピュレーター、ヒューマノイド、ドローン、四足歩行ロボット
タスク	ピック・アンド・プレース、挿入、ナビゲーション、歩行、長期的な再配置
学習設定	RL、BC、IL、オフライン RL、世界モデル、プランニング、拡散ポリシー
観測	RGB、RGB-D、固有受容感覚、触覚、言語
アクションの抽象度	トルク、関節速度、エンドエフェクターのデルタポーズ、ウェイポイントプランナー
評価条件	シミュレーションのみ、シミュレーション＋実機、実機のみ、オフラインベンチマーク
ベンチマーク	ManiSkill、RLBench、Isaac Lab、Habitat、Meta-World、CALVIN、LIBERO、独自
指標	成功率、衝突率、介入回数、経路長、レイテンシー、エネルギー
主なボトルネック	サンプル効率の低さ、脆弱性、リセットコスト、知覚ドリフト、シミュレーションと実環境のギャップ

検索の優先事項

調査を深める際は、以下を優先してください：

• CoRL、RSS、ICRA、IROS、RA-L の最近の研究
• 過去 6～12 か月の最近の arXiv 論文
• ベンチマーク論文と、それに続く再現研究
• システムのボトルネックを明らかにする否定的結果や診断に関する論文

注目する点

「最も高い成功率を達成したのは誰か」だけで終わらせないでください。以下を明確に特定してください：

• 論文が解決できていない、繰り返し発生する失敗モード
• 飽和している、または誤解を招くベンチマーク
• 身体形態の変更によって、これまでの結論が無効になる箇所
• 特権的な観測に依存する手法
• 報告された性能向上が、リセットの工夫、報酬整形、または非公開のインフラによるアイデア
• 性能値は高くても、評価の質が低いタスク群

チェックポイント： ロボティクスの観点から、次のように分野の全体像をユーザーに提示します：

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

• ユーザーが承認する（または応答がなく、AUTO_PROCEED=true）→ 最適なロボティクスの枠組みを用いてフェーズ 2 に進みます。
• ユーザーが変更を希望する（例：対象とする身体形態を限定する、別のベンチマーク群を選ぶ、シミュレーションと実機の転移を扱わない、ハードウェアを使用しない）→ ロボティクスの枠組みを見直し、フェーズ 1 を再実行して、再度提示します。

フェーズ 2：ロボティクスに特化したアイデアの生成と選別

ロボティクスの枠組みを明確にしてから、アイデアを生成します。

既存のアイデア生成器を呼び出します。ただし、一般的な ML のアイデアが生成されないよう、プロンプトに ロボティクス課題の枠組み と全体像のマトリックスを渡してください：

/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"

その後、以下のロボティクス固有のルールに沿って出力を書き換え、選別します。

候補となる各アイデアには、以下を含める必要があります：

• 1 文での要約
• 対象とする身体形態
• 対象とするベンチマーク／シミュレーター／データセット
• 解決する中心的なボトルネック
• シミュレーションを優先した最小限のパイロット実験
• 必須の指標
• アイデアがうまくいかない場合に想定される失敗モード
• 実機が本当に必要かどうか

有望なロボティクスアイデアのパターン

以下に当てはまるアイデアを優先してください：

• 知覚と行動の連携における実際のボトルネックを明らかにする
• 身体形態や環境の変化に対する頑健性を高める
• オペレーターの作業時間、リセットコスト、またはデモ作成コストを削減する
• 測定可能なメカニズムによって、シミュレーションから実環境への転移を強化する
• リカバリー、再試行の挙動、または失敗検出を改善する
• より優れたベンチマーク、診断手法、または評価プロトコルを作成する
• コミュニティで繰り返し唱えられているものの、ほとんど測定されていない前提を検証する

有望でないロボティクスアイデアのパターン

次のようなアイデアは、評価を下げてください：

• ボトルネックの新たな分析がないまま、「基盤モデル／VLM／拡散モデルをロボット X に適用する」ことが中心
• デモ主体で、ベンチマークによる評価ができない
• 入手困難なハードウェア、カスタムセンサー、または大規模な非公開データセットに依存する
• 数か月にわたるインフラ構築なしでは評価できない
• すべてが完璧に機能する場合にしか興味を引かない

フィルタリングルール

各アイデアについて、以下に該当する場合は却下するか、大幅に順位を下げてください。

• 具体的なシミュレーターやベンチマークがない
• 信頼できるベースラインがない
• 「見た目が良くなる」以外の測定可能な指標がない
• 実機での実行が必要だが、ハードウェアにアクセスできるか不明
• 主張を弱める特権的な観測に依存している
• 公平な評価を行うと、期待される貢献が成り立たなくなる

チェックポイント： 新規性を確認する前に、ロボティクスのアイデアを順位付けして提示してください。

💡 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.)

• ユーザーがアイデアを選択した場合（または応答がなく、AUTO_PROCEED=true の場合）→ シミュレーションを優先した上位のアイデアでフェーズ 3 に進み、その後フェーズ 4 とフェーズ 5 に進みます。
• ユーザーが別の制約を希望する場合 → ロボティクスの枠組みを更新し、フェーズ 2 を再実行します。
• ユーザーが対象範囲を狭めたい場合 → より限定した実機構成／タスク／ベンチマークに焦点を絞り、フェーズ 1 に戻ります。

フェーズ 3：実現可能性とパイロット設計

上位のアイデアについて、最小限の検証パッケージを設計します。

リポジトリに利用可能なシミュレーター、ベンチマーク用ハーネス、またはオフラインデータセットのパイプラインがすでに含まれている場合は、上位 1～3 件のアイデアをそこで検証してもかまいません。そうでない場合は、実行を無理に行わず、具体的なパイロット計画を作成してください。

デフォルトでは、パイロットは以下のいずれかとします。

• シミュレーションパイロット
• オフラインログ／データセットパイロット
• 既存のベンチマーク出力を使った分析のみのパイロット

ユーザーが明示的に希望した場合に限り、実機パイロットを提案してください。

残った各アイデアについて、以下を指定してください。

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

実機のルール

実機でのテストに自動的に進んではいけません。 アイデアにハードウェアが必要な場合：

• needs physical validation と記載します
• まずシミュレーションまたはオフラインでの前段階を設計します
• 実機での手順に進む前に、ユーザーの明示的な確認を求めます

低コストで実施できるシミュレーション／オフラインでのパイロットがない場合も、アイデアはレポートに残し、実行リスクが高いと記載します。

フェーズ 3 の後は、パイロットを実行せず計画だけを作成した場合でも、フェーズ 4 に進んでください。すぐに実行できないことを理由に、ワークフローを止めてはいけません。

フェーズ 4：新規性の詳細検証

上位の各アイデアについて、以下を実施します。

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

ロボティクスの新規性確認には、以下を含める必要があります。

• 実機構成
• タスクファミリー
• ベンチマーク／シミュレーター
• センサースタック
• コントローラー／ポリシーの種類
• 関連する場合は sim2real または安全性の観点

以下のようなアイデアには、特に懐疑的な姿勢で臨んでください。

• 古い手法に新しいベンチマークを組み合わせただけのもの
• 標準的なマニピュレーションベンチマークに VLA/VLM を適用しただけのもの
• 新しい転移メカニズムを伴わない sim2real の主張

手法に新規性はなくても、発見または評価プロトコルに新規性がある場合は、その旨を明確に述べてください。

フェーズ 5：ロボティクス分野の外部レビュー

以下を呼び出します。

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

レビュアーには、CoRL／RSS／ICRA のシニア査読者としてレビューするよう依頼します。以下の点に焦点を当てるよう求めてください。

• 貢献が単なる ML の新規性ではなく、ロボティクス分野で本当に新しいか
• 信頼性を確保するために最低限必要なベンチマークパッケージ
• sim2real の主張に妥当性があるか
• 欠けているベースラインや失敗分析
• 現実的なインフラ制約のもとでアイデアが成り立つか

レビュアーが示した、実用最小限のエビデンスパッケージをレポートに反映します。

フェーズ 6：最終レポート

後続のワークフローとの互換性を保つため、ロボティクスに特化した構成で idea-stage/IDEA_REPORT.md を作成または更新します。

# Robotics Idea Discovery Report

**Direction**: $ARGUMENTS
**Date**: [today]
**Pipeline**: research-lit → idea-creator (robotics framing) → novelty-check → research-review

## Robotics Problem Frame
- Embodiment:
- Task family:
- Observation / action interface:
- Available assets:
- Constraints:

## Landscape Matrix
[grouped by embodiment, benchmark, and bottleneck]

## Ranked Ideas

### Idea 1: [title] — RECOMMENDED
- Embodiment:
- Benchmark / simulator:
- Bottleneck addressed:
- Pilot type: sim / offline / real
- Positive signal:
- Novelty:
- Reviewer score:
- Hardware risk:
- Next step:

## Eliminated Ideas
- [idea] — killed because benchmark unclear / hardware inaccessible / novelty weak / no fair evaluation

## Evidence Package for the Top Idea
- Required baselines:
- Required metrics:
- Required failure cases:
- Whether real robot evidence is mandatory:

## Next Steps
- [ ] Implement sim-first pilot
- [ ] Run /novelty-check on the final idea wording
- [ ] Only after approval: consider hardware validation

主なルール

• シミュレーションを優先します。 ハードウェアはデフォルトでは使用しません。
• ベンチマークの具体性は必須です。 ベンチマークがなければ、真剣に検討できるアイデアとはいえません。
• 評価には失敗を含める必要があります。 成功率だけでは不十分です。
• 実機構成は重要です。 あるロボットでの結果が別のロボットにも通用すると決めつけてはいけません。
• 基盤モデルを使った見せかけの新規性は避けてください。 新しい用語は新規性を意味しません。
• インフラの現実性も重要です。 オペレーターの作業時間、リセットの負担、安全性も研究上の制約として扱います。
• 貢献が主に診断または評価にある場合は、その旨を明示してください。 それでも論文として発表できる可能性があります。

後続の作業との連携

このワークフローで有望なロボティクスのアイデアが見つかった後は、以下を行います。

/idea-discovery-robot "direction"   ← you are here
implement sim-first pilot
/run-experiment                     ← if infrastructure exists
/auto-review-loop "top robotics idea"

シミュレーターまたはベンチマークがまだない場合は、レポートの作成で止め、インフラを構築するか、より実行しやすいアイデアに切り替えるかをユーザーに確認します。

出力プロトコル

すべての出力ファイルで、以下の共通プロトコルに従ってください。

• 出力バージョニングプロトコル — まずタイムスタンプ付きファイルを書き込み、その後、固定名のファイルにコピーします
• 出力マニフェストプロトコル — すべての出力を MANIFEST.md に記録します
• 出力言語プロトコル — プロジェクトの言語設定を尊重します