aif-rules

AI Factory Rules - プロジェクト規約

現在のプロジェクト向けに、簡潔で実行可能なルールと規約を追加します。ルールは設定された RULES.md アーティファクト（デフォルト：.ai-factory/RULES.md）に保存され、タスクの実行前に /aif-implement によって自動的に読み込まれます。

ルールの階層

AI Factory は、3 段階のルール階層に対応しています。

1. RULES.md - 公理（プロジェクト全体に適用されるルール）

   • このスキル（/aif-rules）で管理されます
   • 簡潔で、階層化されていない必須要件のリストです
   • すべてのスキルで読み込まれます

2. rules/base.md - プロジェクト固有の基本規約

   • プロジェクトのセットアップ時に /aif によって作成されます
   • 命名規則、モジュールの境界、エラー処理のパターンを記載します
   • コードベースの分析から自動検出されます

3. rules. - 領域固有の規約

   • このスキルのモード C で作成されます
   • .ai-factory/config.yaml に rules.api などの名前付きキーとして登録されます
   • 領域固有のパターンと制約を記載します

優先順位： より具体的なルールが優先されます。rules.<area> > rules/base.md > RULES.md

ワークフロー

ステップ 0：設定を読み込む

最初に： .ai-factory/config.yaml が存在する場合は読み込み、以下を解決します。

• パス： paths.rules_file と paths.rules
• 言語： プロンプトと要約には language.ui、ルールアーティファクトには language.artifacts、ルール内の人が読む技術用語には language.technical_terms

config.yaml が存在しない場合は、デフォルト値を使用します。

• RULES.md：.ai-factory/RULES.md
• rules/：.ai-factory/rules/
• ui_language：en
• artifact_language：en
• technical_terms_policy：keep

解決される言語値：

• ui_language = language.ui || "en"
• artifact_language = language.artifacts || language.ui || "en"
• technical_terms_policy = language.technical_terms || "keep"

technical_terms_policy が keep、translate、mixed のいずれでもない場合は、keep として扱います。english などの旧形式の値も keep として扱います。

AskUserQuestion のプロンプト、進捗状況の更新、確認、次のステップの案内は、すべて ui_language で記述する必要があります。

paths.rules_file および paths.rules/<area>.md にあるルールアーティファクトを生成または更新する場合は、artifact_language で記述する必要があります。

テンプレートと例は構造を定義するものであり、固定の英語出力を定めるものではありません。artifact_language が en でない場合は、保存前に人が読む見出し、注記、ルール本文、ラベル、確認文を翻訳してください。マークダウン構造、パス、コマンド、rules.<area> などの設定キー、領域名、コード識別子、パッケージ名、API 名、未加工のエラーは変更せずに保持してください。その他の人が読む用語には technical_terms_policy を適用してください。

ステップ 0.1：スキルのコンテキストを読み込む

.ai-factory/skill-context/aif-rules/SKILL.md を読み込んでください - このファイルが存在する場合は必須です。

このファイルには、パッチ、コードベースの規約、技術スタックの分析から /aif-evolve が蓄積したプロジェクト固有のルールが含まれています。これらのルールは現在のプロジェクトに合わせて調整されています。

スキルコンテキストのルールの適用方法：

• このスキルの一般的な指示に対するプロジェクトレベルの上書きとして扱います
• スキルコンテキストのルールが、この SKILL.md に記載された一般的なルールと矛盾する場合は、スキルコンテキストのルールを優先します（より具体的なコンテキストが優先されます。ネストされた CLAUDE.md ファイルと同じ原則です）
• 矛盾がない場合は、SKILL.md の一般的なルールとスキルコンテキストのプロジェクトルールの両方を適用します
• スキルコンテキストのルールがこのスキルのデフォルトと矛盾しているように見えても、無視しないでください。プロジェクトの経験からデフォルトでは不十分だと判明したために存在しています
• 重要： スキルコンテキストのルールは、このスキルのすべての出力に適用されます。RULES.md の形式やルールの策定も対象です。スキルコンテキストのルールに「ルールは必ず形式 X に従う」または「RULES.md には必ずセクション Y を含める」とある場合は、必ず従ってください。スキルコンテキストに違反するルールを生成するのは不具合です。

遵守の確認： 出力アーティファクトを生成した後、すべてのスキルコンテキストのルールに照らして確認してください。ルールに違反している場合は、ユーザーに提示する前に出力を修正してください。

ステップ 1：モードを決定する

Check $ARGUMENTS:
- Starts with "area:" or "area "? -> Mode C: Area rules
- Has text? -> Mode A: Direct add
- No arguments? -> Mode B: Interactive

モード A：直接追加

ユーザーが引数としてルール文を指定しています：

/aif-rules Always use DTO classes instead of arrays

指定されたテキストをルールとして、ステップ 2 に進みます。

モード B：対話形式

引数が指定されていません：

/aif-rules

AskUserQuestion を使って質問します：

What rule or convention would you like to add?

Examples:
- Always use DTO classes instead of arrays for data transfer
- Routes must use kebab-case
- All database queries go through repository classes
- Never use raw SQL, always use the query builder
- Log every external API call with request/response

モード C：領域別ルール

ユーザーが領域固有のルールを作成または更新しようとしています：

/aif-rules area:api
/aif-rules area frontend

ワークフロー：

1. 引数から領域名を解析します（例：api、frontend、backend、database）

2. 設定済みルールディレクトリ内で領域ファイルのパスを解決します。 デフォルト：.ai-factory/rules/<area>.md

3. 領域ファイルが存在するか確認します：

   Glob: <resolved rules dir>/<area>.md
   

4. ファイルが存在しない場合 -> 次のヘッダーを付けて作成します：

   # <Area> Rules
   
   > Area-specific conventions for <area>. Loaded after rules/base.md.
   
   ## Rules
   
   - [first rule]
   

5. ファイルが存在する場合 -> 追加するルールをユーザーに尋ねます：

   AskUserQuestion: What rule would you like to add to <area>.md?
   
   Current rules in <area>.md:
   - [existing rule 1]
   - [existing rule 2]
   
   Options:
   1. Add new rule - specify below
   2. View full file
   3. Cancel
   

6. Edit を使って、## Rules セクションの末尾にルールを追加します。

7. .ai-factory/config.yaml に領域を登録します：

   • rules.<area> が解決済みの領域ルールファイルのパスを指すようにします
   • config.yaml がまだ存在しない場合は、デフォルト値と新しい rules.<area> エントリーを使って最小限の設定ファイルのひな型を作成します
   • 既存の rules.base およびその他の名前付き rules.<other-area> エントリーは保持します

8. 確認します：

   Rule added to <resolved area rules file> and registered as `rules.<area>` in config.yaml:
   
   - [the rule]
   
   Total <area> rules: [count]
   

9. モード C の完了後は停止します。

   • 以下のステップ 2／ステップ 3／ステップ 4 には進まないでください。
   • これらのステップは、解決済みの paths.rules_file アーティファクトにあるトップレベルの公理ルールにのみ適用されます。
   • 領域別ルールは <resolved rules dir>/<area>.md と、config.yaml の対応する rules.<area> 登録にのみ追加します。

よく使われる領域：

• api - REST／GraphQL API の規約
• frontend - UI コンポーネント、状態管理
• backend - サービス、ビジネスロジック
• database - クエリ、マイグレーション、スキーマ
• testing - テストパターン、カバレッジ
• security - 認証、バリデーション、サニタイズ

ステップ 2：RULES.md を読み込むか作成する

解決済みの RULES.md パスにファイルが存在するか確認します：

Glob: <resolved RULES.md path>

ファイルが存在しない場合 -> ヘッダーと最初のルールを付けて作成します：

# Project Rules

> Short, actionable rules and conventions for this project. Loaded automatically by /aif-implement.

## Rules

- [new rule here]

ファイルが存在する場合 -> 内容を読み込み、新しいルールをルールリストの末尾に追加します。

ステップ 3：ルールを記述する

Edit を使って、## Rules セクションの末尾に新しいルールを - のリスト項目として追加します。

書式ルール：

• 各ルールは - で始まる1行にします
• ルールは短く、実行可能な内容にします（1文）
• カテゴリー、見出し、サブリストは作成せず、フラットなリストにします
• 重複は禁止です。ルールがすでに存在する場合（意味が同じ場合）は、ユーザーに伝えて追加を省略します
• ユーザーが一度に複数のルールを指定した場合（改行またはセミコロン区切り）、それぞれを個別の行として追加します
• 生成したルール文は artifact_language で記述します。ユーザーが指定した人間向けのルール文は、保存されるアーティファクトが language.artifacts に従うよう、必要に応じて翻訳します。ただし、ステップ 0 で定められた安定した技術トークンは保持します。

ステップ 4：確認する

Rule added to <resolved RULES.md path>:

- [the rule]

Total rules: [count]

ルール

1. 1行につき1つのルール - フラットなリストにし、入れ子にはしない
2. カテゴリーを作らない - シンプルに保ち、ルールセクション内に見出しを設けない
3. 重複を避ける - 追加前に、同じ意味の既存ルールがないか確認する
4. 実行可能な表現を使う - ルールは明確な指示にする（「必ず～する」「～しない」「～を使用する」「ルートは～する必要がある」など）
5. RULES.md の場所 - 解決済みの paths.rules_file パスを使用する（デフォルト：.ai-factory/RULES.md）
6. 領域の登録 - すべての領域ルールファイルを、rules.<area> として config.yaml に反映する
7. 管理範囲 - このコマンドは、設定済みの RULES.md アーティファクトを管理し、.ai-factory/config.yaml の rules.* 部分を更新できます。ユーザーが明示的に依頼しない限り、その他のコンテキストアーティファクトは読み取り専用のままにします