メインコンテンツへスキップ
このページでは、Embedder の精度と再現性を高めるための実践ポイントをまとめます。 最重要なのはセッションの長さ管理です。会話、ファイル内容、コマンド出力が増えるほどノイズも増え、判断がぶれやすくなります。短く集中したセッションを維持することが、最も効く改善策です。

​
1. 検証可能な依頼にする

テスト、期待出力、成功条件を明示してください。
成功条件が曖昧だと、見た目は正しくても実行時に破綻する変更が出やすくなります。 良い依頼の例：
  • 入力と期待出力を具体化する
  • 必須テストを明記する
  • 「エラーの抑制」ではなく「根本原因の修正」を要求する

​
2. まず Plan、次に Act

複雑な変更は Plan モードで調査・設計してから Act モードで実装します。
推奨フロー：
1

探索

関連ファイル・初期化処理・制約を確認。
2

計画

変更対象ファイル、実装手順、検証手順を整理。
3

実装

計画に沿って実装し、ビルド・テスト・ログで確認。
4

提出

分かりやすいコミットメッセージで PR 作成。
小さな修正（軽微なバグ、名前変更、ログ追加）は Act 直行で問題ありません。

​
3. プロンプトは具体的に

制約が明確なほど、手戻りは減ります。
含めるべき情報：
  • 対象ファイル・範囲
  • 期待する挙動と境界条件
  • 禁止事項（新規フレームワーク導入不可など）
  • 検証方法（テストコマンド、合格条件）

​
4. EMBEDDER.md を短く保守する

/init で生成したら、そのまま肥大化させずに厳選してください。 入れるべき内容：
  • 推測しづらいビルド/テスト手順
  • プロジェクト固有の規約
  • 環境依存の注意点
入れない内容：
  • コードから明白な情報
  • 変化が激しい一時情報
  • 抽象的すぎるスローガン

​
5. コンテキスト管理を徹底する

  • タスク間で /clear
  • 同じ失敗を繰り返したら /clear して再定義
  • 長い会話は /compress
  • 途中復帰は /history
  • 失敗試行は /undo / /rewind

​
6. Subagents を使い分ける

広い調査は Subagents に任せ、メイン会話は実装に集中させます。
Use subagents to investigate CAN initialization, TX/RX interrupt handling,
and existing reusable drivers in this firmware project.

​
7. よくある失敗

  • コンテキストを掃除せず情報が混線する
  • 成功条件がない依頼
  • EMBEDDER.md が長すぎて重要ルールが埋もれる
  • 「広く調べて」で範囲を指定せず、コンテキストを使い切る
「範囲」「成功条件」「参照ファイル」を最初に固定するだけで、成功率は大きく上がります。
Last modified on March 5, 2026