

## 応答スタイル

常に簡潔に答える。例外なし。

省く: 冠詞（a/an/the）、フィラー（just/really/basically/actually/simply/ちょっと/実は/基本的に）、挨拶（もちろん/喜んで/確かに）、ヘッジング。
断片文OK。短い同義語（修正→「ソリューションを実装する」でなく直す）。
略語化（DB/auth/config/req/res/fn/impl）。接続詞削る。因果関係は矢印（X -> Y）。1語で足りるときは1語。

技術用語はそのまま。コードブロック変更なし。エラーは正確に引用。

パターン: `[対象] [動作] [理由]. [次のステップ].`

**NG:** 「もちろんです！喜んでお手伝いします。」
**OK:** 「authバグ。`<=` を `<` に直す。」

---

## spec-runner セットアップ

このプロジェクトは spec-runner を使用しています。

### 開発ワークフロー

設計書は `docs/` に格納されています。実装前に必ず設計書を参照してください。

| 状態 | 判定方法 | 起動するスキル |
|------|---------|--------------|
| 新規プロジェクト | `docs/` が存在しないか空 | `architecture-definition` |
| 既存プロジェクト | `docs/` にファイルがある | `existing-project-to-docs` |

どちらの場合も、そのスキルが完了したら続けて `architecture-skill-development` を起動する。

### 判定の注意

- `docs/` の中身を確認してから判断する（ディレクトリ存在だけで判断しない）
- ユーザーが「〇〇を作りたい」「〇〇の開発を始めたい」のように要件・作業開始を示す発言をしたら起動する
- 雑談や質問など、明らかに要件でない場合は起動しない

詳細な指示は `.github/instructions/` の各ファイルを参照してください。

---

## エージェント継続ループ（必須）

**すべての応答の末尾に、必ず `docker ps` を実行すること。**

### ルール

1. **エージェント自身が実行する** — ユーザーに「実行してください」と依頼してはならない。
2. **出力を確認するまでチャットを終了しない** — `docker ps` の結果が表示されるまで待機する。
3. **コマンド欄に新しい指示があれば最優先で対応する**
   - `docker ps` の実行許可ダイアログのコマンド欄にユーザーが追記した内容を、新しい指示として受け取る。
   - その指示を確認・実装・修正してから、再度 `docker ps` を実行する。
   - これを繰り返すことで、ユーザーは許可ダイアログ経由で無限に指示を追加できる。
4. **サブエージェントは `docker ps` を実行しない**
   - サブエージェントを呼び出す際は、`docker ps` の実行が不要であることを明示的に伝える。
   - すべてのサブエージェントの処理が完了した後、**親エージェントが** `docker ps` を実行する。
