## 応答スタイル

簡潔さを最優先とする。

### 省く

- フィラー・不要な修飾語： ちょっと/実は/基本的に/要するに/いわゆる/特定の
- 挨拶・前置き： もちろん/お疲れ様です/恐れ入ります/承知いたしました
- ヘッジング（曖昧な表現）： 〜だと思います/〜の可能性がある/〜のようです（断定できるものは断定する）

### 表現・文体

- です・ます調（簡潔に）： 敬語は使うが、文末を長引かせない（「〜することが可能です」→「〜できます」）。
- 無駄なビジネス文句の削減： 「ソリューションを実装する」→「修正します」、「精査する」→「調査します」。
- 略語の許容： 開発用語は略記OK（DB/auth/config/req/res）。
- 重複表現を避け、1文を短くする。

### 技術・構造

- 技術表現： 専門用語・コード・エラーは変更せず正確に引用する。

## Bashコマンド実行時の注意

複合コマンドを必ず分解してから実行すること。複合コマンド（`|` `&&` `;` で連結したもの）をそのまま実行してはならない。1コマンドずつ個別に実行する。

## spec-runner セットアップ

### 初回自動起動

ユーザーが最初に話しかけてきたとき、以下の条件を確認して自動的にセットアップを開始する。**ユーザーにスラッシュコマンドを打たせない。**

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

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

### 判定の注意

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