> ## Documentation Index
> Fetch the complete documentation index at: https://docs.embedder.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ベストプラクティス

このページでは、Embedder の精度と再現性を高めるための実践ポイントをまとめます。

最重要なのは**セッションの長さ管理**です。会話、ファイル内容、コマンド出力が増えるほどノイズも増え、判断がぶれやすくなります。**短く集中したセッションを維持することが、最も効く改善策です。**

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

<Tip>
  テスト、期待出力、成功条件を明示してください。
</Tip>

成功条件が曖昧だと、見た目は正しくても実行時に破綻する変更が出やすくなります。

良い依頼の例：

* 入力と期待出力を具体化する
* 必須テストを明記する
* 「エラーの抑制」ではなく「根本原因の修正」を要求する

## 2. まず Plan、次に Act

<Tip>
  複雑な変更は Plan モードで調査・設計してから Act モードで実装します。
</Tip>

推奨フロー：

<Steps>
  <Step title="探索">
    関連ファイル・初期化処理・制約を確認。
  </Step>

  <Step title="計画">
    変更対象ファイル、実装手順、検証手順を整理。
  </Step>

  <Step title="実装">
    計画に沿って実装し、ビルド・テスト・ログで確認。
  </Step>

  <Step title="提出">
    分かりやすいコミットメッセージで PR 作成。
  </Step>
</Steps>

小さな修正（軽微なバグ、名前変更、ログ追加）は Act 直行で問題ありません。

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

<Tip>
  制約が明確なほど、手戻りは減ります。
</Tip>

含めるべき情報：

* 対象ファイル・範囲
* 期待する挙動と境界条件
* 禁止事項（新規フレームワーク導入不可など）
* 検証方法（テストコマンド、合格条件）

## 4. `EMBEDDER.md` を短く保守する

`/init` で生成したら、そのまま肥大化させずに厳選してください。

入れるべき内容：

* 推測しづらいビルド/テスト手順
* プロジェクト固有の規約
* 環境依存の注意点

入れない内容：

* コードから明白な情報
* 変化が激しい一時情報
* 抽象的すぎるスローガン

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

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

## 6. Subagents を使い分ける

<Tip>
  広い調査は Subagents に任せ、メイン会話は実装に集中させます。
</Tip>

```txt theme={"system"}
Use subagents to investigate CAN initialization, TX/RX interrupt handling,
and existing reusable drivers in this firmware project.
```

## 7. よくある失敗

* コンテキストを掃除せず情報が混線する
* 成功条件がない依頼
* `EMBEDDER.md` が長すぎて重要ルールが埋もれる
* 「広く調べて」で範囲を指定せず、コンテキストを使い切る

<Tip>
  「範囲」「成功条件」「参照ファイル」を最初に固定するだけで、成功率は大きく上がります。
</Tip>