chief-rule

ユーザーが単一のルールを .chief/_rules/ に記録できるよう支援します。これは /chief-retro の事前対応版です。ユーザーがルールを思いつき、今すぐ書き留めたい場合に使用してください。

1 回の実行につき、1 つのルール（パス 2）、または足場の作成のみ（パス 1）を行います。さらにルールを記録する場合は、再度実行してください。

手順

1. 事前確認

確認するだけにしてください。まだ何も作成しないでください。後で使用するため、以下を確認してください。

• .chief/ が存在するか
• .chief/_rules/ が存在するか
• .chief/_rules/README.md が存在するか

足場（.chief/、.chief/_rules/、README の作成）は、今ではなく、選択したパスの最後に行います。ユーザーが途中でやめた場合、ファイルシステムには変更を加えません。

2. 事前インタビューの分岐

次の 2 つの選択肢だけをユーザーに提示してください。

どちらかを選んでください：

1. .chief/_rules/ の足場だけを作成する（ルールは後で手動で書くか、作業後に /chief-retro を使用します）
2. インタビューを受ける — 今すぐルールを書く

1 の場合 → 以下の足場作成ルーチンを実行してから終了します。 2 の場合 → ステップ 3 に進みます。（足場の作成は後で、ステップ 7 でルールの書き込みと合わせて行います。）

足場作成ルーチン（パス 1、および _rules/ がない場合のパス 7 で使用）

1. .chief/ が存在しない場合は作成します。

2. .chief/_rules/ が存在しない場合は作成します。

3. .chief/_rules/README.md が存在しない場合は、次の内容で作成します。

   # .chief/_rules/
   
   Global rules that govern this project's autonomous AI work. Lower priority than `AGENTS.md`, higher than milestone goals.
   
   ## Categories
   
   - `_standard/` — Coding standards, architecture constraints
   - `_contract/` — Data models, API contracts, schemas
   - `_goal/` — High-level goals (shared across milestones)
   - `_verification/` — Test commands, build requirements, definition of done
   
   Subfolders are created **lazily** — on first rule in that category. Empty subfolders are not required.
   
   Use `/chief-rule` to add rules proactively, or `/chief-retro` to capture them after a milestone retrospective.
   

4. 4 つのカテゴリサブフォルダーは作成しないでください。各カテゴリに最初のルールが追加されるまで、必要になるまで作成しません。

パス 1 の足場作成後は、README のパスをユーザーに伝えて終了します。

3. インタビュー（一度に焦点を絞った質問を 1 つ）

各質問を個別に行ってください。次に進む前に回答を待ちます。質問は簡潔にしてください。ユーザーが「skip」または「n/a」と言った場合は質問を省略します。ただし、Q1（内容）は省略しないでください。

1. ルールは何ですか？ — ルールを 1 文で述べます。
2. なぜ必要ですか？ — 背景となる動機（インシデント、好み、制約、決定など）です。
3. いつ、どこで適用されますか？ — 適用範囲（常時／特定の領域／特定のマイルストーン／特定のファイル形式など）です。
4. コードやテキストの例はありますか？ — 任意です。正しい例と誤った例を示す短いスニペットや、具体例を提示します。
5. ファイル名は何にしますか？ — 短いケバブケース（例：commit-style、db-naming、pr-size）にします。.md 拡張子は不要です。

4. カテゴリに分類する

回答に基づいて、次の 4 つのカテゴリのいずれかを提案します。

• _standard/ — コーディング規約、命名、書式設定、アーキテクチャ上の制約、「コードの書き方」
• _contract/ — データモデル、API コントラクト、スキーマ、型レベルの不変条件
• _goal/ — マイルストーンをまたいで共有される上位目標、製品の方向性
• _verification/ — テストコマンド、ビルド要件、完了の定義、CI ゲート

選択したカテゴリとその理由を 1 文でユーザーに伝え、確認または変更を依頼してください。

5. ファイルの下書きを作成する

フロントマターなしのプレーンな Markdown で下書きを作成します。

# <The rule statement, as a single declarative sentence>

**Why:** <motivation from Q2>

**How to apply:** <scope from Q3>

## Example

<code or prose example from Q4 — omit this section if user skipped Q4>

レンダリングした下書きをユーザーに表示し、次のように一度だけ尋ねます。「これを .chief/_rules/<category>/<filename>.md に書き込みますか？」

ユーザーが変更を依頼した場合は、変更を反映して再表示します。やり取りは 3 回を超えて繰り返さないでください。意見の一致が難しい場合は、現在の下書きを書き込み、手動で編集できることをユーザーに伝えてください。

6. 衝突の処理（内容を考慮）

書き込む前に、.chief/_rules/<category>/<filename>.md がすでに存在するか確認します。

存在する場合は、まず既存ファイルを読み、そのうえで両者の関係を分類し、適切な対応を提案します。

関係	検出の目安	対応
同一	新しいルールの記述、理由、適用方法が既存の内容と実質的に一致する	スキップします。ルールはすでに反映されていることをユーザーに伝え、終了します。
詳細化／拡張	同じ懸念事項を扱っており、新しいルールで詳細が加わる（例：適用範囲を明確化する、例を追加する、表現を厳密にする）	統合します：両方の内容を維持した統一版を作成します。差分を表示し、既存ファイルを <filename>.md.bak にバックアップします。確認を得てから書き込みます。
矛盾	新しいルールが既存のルールを覆す、または置き換える	置き換えます：旧版と新版を並べて表示します。既存ファイルを <filename>.md.bak にバックアップします。確認を得てから書き込みます。
異なる懸念事項、名前が衝突	ファイル名が同じでも、既存ファイルの H1／Why が別の内容を扱っている	より具体的なファイル名を提案します。ステップ 3 の質問 5（ファイル名）に戻り、ユーザーに確認します。

バックアップを .bak に作成せずに上書きしてはいけません。衝突時に、読み取りをせず書き込んではいけません。

7. 書き込みと報告

1. .chief/_rules/ がまだ存在しない場合は、先にステップ 2 の足場作成ルーチンを実行します（.chief/、.chief/_rules/、および _rules/README.md を作成します）。
2. 対象カテゴリのサブフォルダー（例：.chief/_rules/_standard/）が存在しない場合は作成します。ここが遅延作成のタイミングです。
3. ルールファイルを書き込みます。

その後、以下を報告します。

• 書き込んだパス
• バックアップのパス（衝突により .bak を作成した場合）
• chief-agent は次回 .chief/_rules/** を読み込む際にこのルールを取り込むことを伝えます

終了します。「ほかにも追加しますか？」とは尋ねません。1 回の実行につき 1 つのルールです。次のルールには、ユーザーが再実行します。

重要なルール

• このスキルが作成するのは、ルールファイル（および初回実行時の .chief/_rules/README.md）のみです。マイルストーン、project.md、その他のものは作成しません。
• 空のカテゴリサブフォルダーは作成してはいけません。遅延作成とします。最初のルールを配置するときにのみ、_standard/、_contract/、_goal/、または _verification/ を作成します。
• .bak バックアップを作成し、ユーザーの確認を得ずに既存のルールファイルを上書きしてはいけません。
• .chief/_rules/ の外部にあるファイルを読み取ったり変更したりしてはいけません（コンテキストが必要な場合の AGENTS.md の読み取りを除きます。ただし、通常は不要です）。
• ヒアリングは短くします。一度に尋ねるのは、焦点を絞った質問 1 つだけです。複数の質問を組み合わせてはいけません。
• プレーンな Markdown を使用します。フロントマターは使いません。リポジトリ内の既存の .chief/_rules/ ファイルはプレーンな Markdown なので、その慣例に従います。
• ユーザーがパス 1（足場作成のみ）を選んだ場合は、ヒアリングに進んではいけません。README を書き込んだら終了します。