mcpField
A
aif-evolve

aif-evolve

github.com/lee-toエージェントワークフロー1.1k104 回インストール今日更新
リポジトリ

aif-evolve について

aif-evolveは、プロジェクトの背景、コード規約、過去のパッチを使って既存スキルを改善するAI Factoryのスキルです。パッチを段階的に分析し、組み込みスキルを編集せず、再利用可能なプロジェクト固有ルールをskill-contextに保存します。

主な機能

  1. 01カーソルによるパッチの逐次分析
  2. 02パッチからの予防ルール抽出
  3. 03プロジェクト規約と背景の調査
  4. 04古くなったskill-contextルールの特定
  5. 05プロジェクト固有ルールの保存

活用シーン

  1. 01過去の修正から再発防止策をまとめる
  2. 02プロジェクト規約に合わせてスキルを調整する
  3. 03既存のプロジェクト固有ルールを確認する

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/lee-to/ai-factory --skill aif-evolve

インストール後、Claude Code で/aif-evolveを入力して読み込まれたか確認します。

詳細

Evolve - スキルの自己改善

プロジェクトのコンテキスト、パッチ、コードベースを分析し、既存のスキルを改善します。実行するたびに AI Factory をより賢くします。

コアとなる考え方

patches (past mistakes) + project context + codebase patterns
    ↓
analyze recurring problems, tech-specific pitfalls, project conventions
    ↓
enhance skills with project-specific rules, guards, and patterns

パッチの取り込みポリシー

2 層の学習モデルを使用します。

  1. 生のパッチ（paths.patches、デフォルト：.ai-factory/patches/*.md）を素材とします。
  2. スキルコンテキストのルール（.ai-factory/skill-context/*）を、簡潔で再利用可能な成果物とします。

ワークフロースキル全体に適用されるポリシー：

  • /aif-evolve は、生のパッチを分析する主要なコマンドです。カーソルを使ってパッチを段階的に処理します。
  • /aif-implement、/aif-fix、/aif-improve は、まずスキルコンテキストを優先し、生のパッチはフォールバックのコンテキストとしてのみ使用します。
  • 必要な場合に限り、完全な再分析を強制します（例：カーソルをリセットして evolve を再実行する）。

重要：組み込みスキルを直接編集しないでください

組み込みの aif-* スキルディレクトリ（skills/aif-*/）内のファイルは絶対に変更しないでください。 これらのディレクトリ内のファイルはすべて ai-factory が所有しており、アップデート時に上書きされるため、直接編集した内容は失われます。

プロジェクト固有のルールは必ず skill-context に記述してください：

.ai-factory/skill-context/<skill-name>/SKILL.md

組み込みスキルを改善するための正しい保存先は、ここだけです。例外はありません。

ワークフロー

ステップ 0：対象を特定してコンテキストを読み込む
ステップ 0.1：対象を特定する

$ARGUMENTS からスキル名を正規化します：

ユーザー入力解決後のスキル名
planaif-plan
aif-planaif-plan
/aif-planaif-plan
my-custom-skillmy-custom-skill

ルール：まず、引数の先頭にある / を削除します。次に、引数が aif- で始まっておらず、aif-<argument> という名前のスキルが存在する場合は、aif-<argument> を使用します。それ以外の場合は、そのまま使用します。

スキル名を解決した後： 解決後のスキルが実際に存在することを確認します （{{skills_dir}}/<resolved-name>/SKILL.md または skills/<resolved-name>/SKILL.md を確認してください）。 スキルが見つからない場合 → ユーザーにエラーを報告して停止します： 「スキル '' が見つかりません。すべてのスキルを進化させるには引数なしで /aif-evolve を使用するか、有効なスキル名を指定してください。」

$ARGUMENTS に基づいて進化させるスキルを決定します：

  • $ARGUMENTS に特定のスキル名が含まれている場合 → そのスキルのみを進化させます
  • $ARGUMENTS が "all" または空の場合 → インストール済みのすべてのスキルを進化させます
ステップ 0.2：コンテキストを読み込む

まず、 .ai-factory/config.yaml が存在する場合は読み込み、次の項目を確認します。

  • パス： paths.description、paths.architecture、paths.rules_file、paths.rules、paths.patches、paths.evolutions
  • 言語： プロンプトには language.ui、生成されるレポートには language.artifacts
  • ルールの階層： rules.base と、名前付きの rules.<area> エントリー

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

  • DESCRIPTION.md：.ai-factory/DESCRIPTION.md
  • ARCHITECTURE.md：.ai-factory/ARCHITECTURE.md
  • RULES.md：.ai-factory/RULES.md
  • rules/：.ai-factory/rules/
  • patches/：.ai-factory/patches/
  • evolutions/：.ai-factory/evolutions/
  • 言語：en（英語）

注： 現行のスキーマでは、.ai-factory/skill-context/ は固定の内部 AI Factory パスです。パッチと進化ログの場所は、paths.patches と paths.evolutions で設定できます。

次に、 .ai-factory/DESCRIPTION.md（設定で指定されたパスを使用）を読み、以下を把握します。

  • 技術スタック
  • アーキテクチャ
  • 規約

さらに、 .ai-factory/ARCHITECTURE.md（設定で指定されたパスを使用）と、設定されているルールの階層も読みます。このコンテキストは規約の分析と不足の検出に役立ちますが、成果物の所有権は変更しません。

対象スキルの skill-context ファイルを読みます。

  • 特定のスキル（例：/aif-evolve plan）を進化させる場合 → 以下のみを読みます。
    1. .ai-factory/skill-context/aif-plan/SKILL.md（対象スキルのコンテキスト）
    2. .ai-factory/skill-context/aif-evolve/SKILL.md（存在し、かつ対象スキル自体が aif-evolve ではない場合は、evolve 自身のコンテキスト）
  • すべてのスキル（/aif-evolve または /aif-evolve all）を進化させる場合 → すべてのコンテキストファイルを読みます。 Glob: .ai-factory/skill-context/*/SKILL.md（これには evolve 自身のコンテキストも含まれるため、別途読み込まないでください）

これらのファイルには、組み込みスキル向けにこれまで蓄積されたプロジェクト固有のルールが含まれています。これらはメモリに保持してください。ステップ 5 の不足分析に影響します。

skill-context のルールはプロジェクトレベルのオーバーライドです。対象スキルの基本 SKILL.md と競合する場合は、skill-context が優先されます（ネストされた CLAUDE.md ファイルと同じ原則です）。

evolve 自身の skill-context ルール（aif-evolve）の適用方法：

  • このスキルの一般的な指示に対するプロジェクトレベルのオーバーライドとして扱います。
  • skill-context のルールがこの SKILL.md に記載された一般ルールと競合する場合は、skill-context のルールを優先します（より具体的なコンテキストが優先されます。ネストされた CLAUDE.md ファイルと同じ原則です）。
  • 競合しない場合は、SKILL.md の一般ルールと skill-context のプロジェクトルールの両方を適用します。
  • skill-context のルールがこのスキルのデフォルトと矛盾するように見えても、無視しないでください。これらは、プロジェクトの経験からデフォルトでは不十分だと判明したために存在しています。
  • 重要： skill-context のルールは、このスキルのすべての出力に適用されます。進化レポート、改善案、skill-context ファイルの編集、古くなったルールの分析も含まれます。skill-context のルールに「evolve は X を優先しなければならない」または「レポートには Y を含めなければならない」とある場合、必ず従ってください。skill-context のルールを無視した進化の出力は不具合です。

遵守の確認： 出力成果物を生成した後は、その成果物がすべての skill-context ルールに従っているか確認してください。違反がある場合は、ユーザーに提示する前に修正してください。

ステップ 1：インテリジェンスを収集する

1.1：パッチを段階的に読み込む（カーソルベース）

Glob: <resolved patches dir>/*.md

カーソルファイル：

<resolved evolutions dir>/patch-cursor.json

推奨形式：

{
  "last_processed_patch": "YYYY-MM-DD-HH.mm.md",
  "updated_at": "YYYY-MM-DD HH:mm"
}

処理ルール：

  1. パッチファイルを Glob で取得し、ファイル名の昇順で並べ替えます（タイムスタンプ形式は辞書順で扱いやすい形式です）。
  2. カーソルファイルが存在しない場合 → 初回実行：すべてのパッチを読み込みます。
  3. カーソルファイルが存在し、参照先のパッチも存在する場合 → ファイル名が > last_processed_patch のパッチのみを読み込みます。
  4. カーソルファイルは存在するものの、参照先のパッチが存在しない場合（削除または名前変更） → WARN [evolve] を出力し、全件再スキャンを実行します。
  5. 保存されたベースライン（スナップショット／ハッシュマニフェスト）がなければ、カーソルより古いパッチへの過去の編集／削除を確実に検出することはできません。デフォルトでは、この警告を出力しないでください。
  6. 信頼できるベースラインが存在し、ドリフトが実際に検出された場合に限り、過去のドリフトについて WARN [evolve] を出力します。
  7. 全件再スキャンの手順：<resolved evolutions dir>/patch-cursor.json を削除し、その後 /aif-evolve を再実行します。
  8. ステップ 1.1 ではカーソルを進めないでください。 カーソルが更新されるのは、ステップ 7.3 で適用／ログ書き込みが成功した後のみです。

重複確認ウィンドウ（見落とし防止策）：

LLM は一度の確認で予防策を見落とすことがあります。増分実行時にパッチを「永久にスキップ」する可能性を減らすため：

  1. 増分モード（カーソルが存在し、参照先のパッチも存在する場合）では、ファイル名順で最新のパッチ 5 件（ソート済みリストの末尾 5 件）も読み込み、ファイル名で重複を排除します。
  2. 次の項目をそれぞれ別に記録します。
  • 「新規パッチ」＝ファイル名が > last_processed_patch のパッチ
  • 「重複確認パッチ」＝末尾 5 件のパッチ
  • 「処理対象パッチ」＝「新規」と「重複確認」の和集合
  1. ステップ 7.3 のカーソル更新は「新規パッチ」のみを対象にしなければなりません（重複確認パッチのみを処理した場合は、カーソルを決して進めないでください）。

すべてのパッチを読み込みます。それぞれについて、次の項目を抽出します。

  • 問題カテゴリ（null チェック、非同期処理、バリデーション、型、API、DB など）
  • 根本原因のパターン（どのような種類のミスが発生したか）
  • 予防策 — Prevention／Solution セクションにある、個別に実行可能なルールをそれぞれ抽出します。 1 つのパッチに、異なるスキルを対象とした複数の独立した予防策が含まれることがよくあります。 対象スキルと合わせて、それぞれを個別に抽出してください。パッチを 1 つの単位として扱わないでください。
  • タグ

予防策レジストリを作成する — 今回処理したパッチ一式から抽出したすべての予防策を、フラットリストにまとめます。このレジストリは、ステップ 5 のギャップ分析における主な入力となります。

| # | Patch | Prevention Point (specific action) | Target Skill(s) |
|---|-------|------------------------------------|-----------------|
| 1 | <patch-file> | <concrete action to enforce> | <skill-1> |
| 2 | <patch-file> | <different action from same patch> | <skill-1>, <skill-2> |
| 3 | <other-patch> | <action> | <skill-3> |

重要： 予防策が 5 つ含まれるパッチは、1 行ではなく 5 行になります。 1 つの予防策が 2 つのスキルを対象とする場合、1 回だけ記載し、両方のスキルを列挙します。 そしてステップ 5 では、各スキルを個別に確認する必要があります。

増分実行の場合、このレジストリには今回処理したパッチ一式（新規＋重複確認）が反映されます。過去のすべてをさかのぼって確認する必要がある場合は、全件再スキャンを使用してください。

1.2：パターンを集約する

パッチをタグとカテゴリごとに分類します。次の点を特定します。

  • 繰り返し発生する問題 — 同じタグが 3 回以上登場しますか？ それはシステム上の問題です。
  • 技術固有の落とし穴 — スタックに関連する問題（例：React の再レンダリング、Laravel の N+1）
  • 不足しているガード — どのようなチェック／パターンがあれば、これらのバグを防げたでしょうか。

1.3：コードベースの規約を確認する

プロジェクト内をスキャンして、次のようなパターンを確認します。

  • Linter 設定（.eslintrc、phpstan.neon、ruff.toml など）
  • 既存のテストパターン（テストファイルの構成、使用されているアサーション）
  • エラー処理のパターン（try/catch のスタイル、エラー型）
  • ログ出力のパターン（使用するロガー、形式、レベル）
  • インポート規約、ファイル構成

特定のスキルを進化させる場合、そのスキルに関連する領域を中心に規約を確認します （例：/aif-plan ではファイル構成と命名を、/aif-fix ではエラー処理とテストを重点的に確認します）。

ステップ 2：対象スキルを読む

対象スキルのベースの SKILL.md ファイルのみを読み、すべてのスキルを読む必要はありません。

  • 特定のスキル（例：/aif-evolve plan）を進化させる場合 → そのスキルのみを読みます： Read: {{skills_dir}}/aif-plan/SKILL.md（未インストールの場合は skills/aif-plan/SKILL.md）
  • すべてのスキル（/aif-evolve または /aif-evolve all）を進化させる場合 → すべて読みます： Glob: {{skills_dir}}/*/SKILL.md（未インストールの場合は Glob: skills/*/SKILL.md）

読み込んだ SKILL.md の内容はメモリに保持してください。ステップ 3 で比較に使用するため、再度読み込まないでください。

ステップ 3：Skill-Context 内の古いルールを確認する

実行条件： skill-context ファイルがある、対象の aif-* スキルごとにこのステップを実行します。

.ai-factory/skill-context/<skill-name>/SKILL.md 内の各ルールについて：

スコープの制約： ステップ 3 では、skill-context ファイルのみを変更または削除できます。 ベースの skills/aif-*/ ファイルの編集、削除、または元に戻すことを提案してはなりません。 ベースファイルに誤りや不完全なルールが含まれていても、evolve のスコープ外です。

  1. ステップ 2 ですでに読み込んだベースの SKILL.md を使用します（ファイルを再度読み込まないでください）。

  2. skill-context の各ルールを、ベースの SKILL.md の内容と比較します。

    ケース A — ベースが skill-context のルールを完全に網羅している（同等またはそれ以上）： ベースの SKILL.md に、skill-context のルールと同等、またはそれよりも詳細なルールが含まれています。 これには次のものが含まれます。

    • 完全に同等 — ルールと内容が同じ
    • ベースが上位互換 — skill-context に含まれるすべての内容に加え、さらに多くの内容がベースにある （例：skill-context には Wave 1+3 があり、ベースには Wave 1+2+3 がある） → 自動で削除してはいけません。ユーザーにまだ確認してはいけません。 → ステップ 4 の報告用に収集し、両方のルールを含めて 「ベースが完全に網羅 — skill-context からの削除を推奨」と記載します。 注：ユーザーが skill-context のルールを残すことを選んでも問題ありません。 skill-context はベースより優先されるため、ルールを残すことで、 完全かつ正確なバージョンが常に適用されることを保証できます。

    ケース B — ベースの SKILL.md に矛盾するルールがある： ベースのスキルに、skill-context のルールと直接矛盾するルールが追加されています。 → 自動で削除してはいけません。ユーザーにまだ確認してはいけません。 → この競合をステップ 4 の報告用に収集し、両方のルールを含めて「競合 — ユーザーの判断が必要」と記載します。

    ケース C — 部分的な重複（どちらの方向も含む）： ベースの SKILL.md と skill-context のルールには重複がありますが、どちらも相手を完全には網羅していません。 これには次のものが含まれます。

    • ベースが skill-context の一部を網羅している一方で、skill-context に独自の内容もある
    • skill-context がベースの一部を網羅している一方で、ベースに独自の内容もある （例：skill-context には A→B→C があり、ベースには A→C→D がある — 両方に独自の内容がある） → 自動で範囲を狭めてはいけません。各部分が相互に依存しているか （順序、前提条件、データフロー）を分析します。 → この重複をステップ 4 の報告用に収集し、両方のルールと分析を含めて「部分的に重複 — ユーザーの判断が必要」と記載します。 優先順位に関する警告： 同じトピックでは skill-context がベースより優先されます。 ユーザーが skill-context をそのまま残す場合、ベース独自の内容は失われる可能性が高くなります （AI は skill-context のバージョンを使用し、同じルールのベースのバージョンを無視します）。 選択肢の説明では、この結果を必ず説明してください。

    ケース D — 重複なし： そのルールは引き続きプロジェクトのコンテキストに固有です。 → そのまま残し、対応は不要です。

ステップ 4：古いルールを提示して解決する

ステップ 3 でケース A／B／C のルールが見つからなかった場合は、このステップを省略します。

古いルールに関するすべての調査結果を、古いルールの報告形式 （ケース A／B／C の各セクションで、ベースと skill-context を比較）で提示します。

重要：ここでのすべての判断が影響するのは skill-context ファイルのみです。 ベースの skills/aif-*/ ファイルの編集、削除、または元に戻すことを提案してはいけません。 これらは evolve のスコープ外です。

古いルールの報告形式

古いルールごとに、次の内容を提示します。

/aif-plan — 完全にカバー済み: [ルール名]
  • ベース SKILL.md の記載: [ベースルールのテキスト]
  • スキルコンテキストの記載: [プロジェクトルールのテキスト]
  • 必要な判断: スキルコンテキストに残す（ベースより優先されます — 完全なバージョンが常に適用されることを保証） / スキルコンテキストから削除する（ベースを信頼） / スキルコンテキストのルールを書き換える
/aif-plan — 競合: [ルール名]
  • ベース SKILL.md の記載: [ベースルールのテキスト]
  • スキルコンテキストの記載: [プロジェクトルールのテキスト]
  • 必要な判断: スキルコンテキストのルールを残す（優先されます — ベースのバージョンは 無視されます） / スキルコンテキストのルールを削除する（ベースを信頼） / スキルコンテキストのルールを書き換える
/aif-fix — 部分的な重複: [ルール名]
  • ベース SKILL.md の記載: [ベースルールのテキスト]
  • スキルコンテキストの記載: [プロジェクトルールのテキスト]
  • 分析: [重複の内容と、各部分が独立しているか連続しているかを説明]
  • 必要な判断: 両方の固有部分を含めるようにスキルコンテキストを書き換える （各部分が連続している場合に推奨） / スキルコンテキストをそのまま残す（警告: ベースの固有部分は失われます — スキルコンテキストが優先されます） / スキルコンテキストを カバーされていない部分に絞り込む / スキルコンテキストから削除する（ベースを信頼 — スキルコンテキストの固有部分は失われます）
判断の収集

AskUserQuestion を使用して、古いルールの判断を収集します。AskUserQuestion 呼び出し 1 回につき最大 3 件の判断をバッチで処理します:

  • 最初のバッチを提示（最大 3 件の古いルール） → AskUserQuestion
  • 回答を取得 → 判断を適用
  • 古いルールがさらに残っている場合 → 次のバッチを提示 → AskUserQuestion
  • すべての古いルールが解決されるまで繰り返す

すべての古いルールの判断を収集して適用するまで、ステップ 5 に進まないでください。 これにより、ギャップ分析のための実際のスキルコンテキストの状態が決まります。

ステップ 5：ギャップを分析する

ギャップを分析する前に： ステップ 4 で変更した対象スキルのスキルコンテキストファイル（古いルールの削除・書き換え）を再度読み込んでください。ステップ 0.2 で読み込んだバージョンは使用しないでください。ステップ 4 の変更後は古くなっています。

各スキルについて、ベースの SKILL.md と、（ステップ 4 で古いルールに関する判断を適用した後の）現在のスキルコンテキストファイルの両方を確認してください。 どちらのソースにも記載がない場合にのみ、ギャップが存在します。

収集した情報に基づいて、各スキルで不足している点を特定してください。

5.1：パッチに基づくギャップ（予防ポイントの網羅的な確認）

重要：各予防ポイントを、各対象スキルについて個別に確認してください。

ステップ 1.1 で作成した予防ポイントレジストリを順に確認します。各行について：

  1. その行に記載された対象スキルをそれぞれ確認します。
    • ベースの SKILL.md が、この具体的な予防アクションをすでにカバーしているか確認します。
    • スキルコンテキストに、この具体的な予防アクションをカバーするルールがすでにあるか確認します。
  2. 予防ポイントがスキルで「カバーされている」と見なされるのは、説明されている具体的なアクションに対応するルールがある場合に限られます。Source フィールドに同じパッチファイル名があるだけでは不十分です。
  3. 未カバーの（予防ポイント、スキル）の組み合わせをギャップとして記録します。これらはステップ 6 の入力になります。

よくある落とし穴 — Source の参照は完全なカバーを意味しません： スキルコンテキストのルールに Source: <patch-filename> があるということは、そのパッチから1 つのルールが作成されたことを意味します。そのパッチに含まれる予防ポイントがすべてカバーされているという意味ではありません。5 つの予防ポイントがあるパッチでも、カバーされているのは 1 つだけかもしれません。既存のルールの内容を、各予防ポイントと個別に照合してください。

検証： レジストリの確認が終わったら、予防ポイントの合計数、カバー済み数、未カバー数を数えます。未カバー数が 0 より大きい場合、それらがステップ 6 で対応するギャップです。

注：インクリメンタルモードでは、件数は今回処理したパッチセットを対象とします。過去分を含めて再集計するには、全件再スキャンを実行してください。

5.2：技術スタックのギャップ

プロジェクトの技術スタックとスキルの指示を比較します。

  • スキルでは汎用的なパターンを扱っているが、プロジェクトでは特定のフレームワークを使用している場合 → フレームワーク固有のガイダンスを追加する
  • プロジェクトでは TypeScript を使用しているが、スキルには JS の例がある場合 → 例を更新する
  • プロジェクトでは特定の ORM（Prisma、Eloquent）を使用している場合 → ORM 固有のパターンを追加する

5.3：規約のギャップ

プロジェクトの規約とスキルの指示を比較します。

  • プロジェクトに特定のエラー処理パターンがある場合 → スキルでそのパターンを徹底する
  • プロジェクトで特定のロガーを使用している場合 → スキルでそのロガーに言及する
  • プロジェクトに特定のファイル構成がある場合 → スキルでそれに従う
ステップ 6：改善案を作成する

見つかったギャップごとに、具体的な改善案を作成します。

改善案の品質ルール：

  • 予防ポイント 1 つにつき、ルール 1 つ。 1 つのパッチに、互いに独立した予防項目が複数含まれている場合があります。それぞれを別のルールにしてください。曖昧な要約にまとめないでください。
  • パッチにある具体的な形式やパターンをそのまま保持します。パッチで正確な形式、構文、またはテンプレートが指定されている場合、ルールにもそれをそのまま含める必要があります。具体的な内容を曖昧な説明に言い換えないでください。
  • 各改善案は、パッチ、規約、または技術スタックの情報にたどれる必要があります。
  • 汎用的な助言は避け、プロジェクト固有の強化に限定します。
  • 改善案は最小限かつ焦点を絞ったものにします。スキル全体を書き換えないでください。
  • 既存のスキル構成を維持し、置き換えずに追加します。
ステップ 7：提示して適用する

7.1：改善案をユーザーに提示する

各改善案には、対象ファイルのパスを明記する必要があります。 以下の対象ラベルを使用してください。

  • skill-context → .ai-factory/skill-context/<skill-name>/SKILL.md
  • SKILL.md → スキル独自の SKILL.md を直接編集する（カスタムスキル／非 aif スキルのみ）
  • ネストされたファイル → スキルディレクトリに追加ファイル（例：templates/、checklists/）がある場合は、スキルディレクトリ内の正確な相対パスを指定する

形式：

## Skill Evolution Report

Based on:
- X patches analyzed
- Y recurring patterns found
- Z tech-stack specific insights

### Proposed Improvements

#### /aif-fix (N rules)
**Target:** `.ai-factory/skill-context/aif-fix/SKILL.md`

1. **Add null-check guard**
   - **Source:** patch-2026-02-10.md, patch-2026-02-12.md (5 patches involved null references)
   - **Why:** Recurring null-reference errors on optional DB relations
   - **Rule:** "Check for optional/nullable fields before accessing nested properties"

2. **Add async/await pattern**
   - **Source:** patch-2026-02-11.md (3 patches involved unhandled promises)
   - **Why:** Unhandled promise rejections in API layer
   - **Rule:** "Always use try/catch with async/await"

#### /aif-implement (N rules)
**Target:** `.ai-factory/skill-context/aif-implement/SKILL.md`

1. **Add Prisma-specific warning**
   - **Source:** patch-2026-02-13.md (2 patches from incorrect Prisma queries)
   - **Why:** Silent data loss from wrong Prisma query methods
   - **Rule:** "Log all Prisma queries in DEBUG mode"

#### /my-custom-skill (N rules)
**Target:** `skills/my-custom-skill/SKILL.md` (direct edit — custom skill)

1. **Add pattern**
   - **Source:** codebase convention
   - **Why:** Missing guard in Step 2
   - **Rule:** "..."

レポート全体を提示した後、AskUserQuestion を使用して判断を確認してください： 改善点については、次のように尋ねます:

  • はい、すべての改善を適用する
  • 自分で選ぶ
  • いいえ、レポートを保存するだけ (変更は適用しない)

選択に基づいて:

  • 「はい、すべての改善を適用する」→ すべての改善を適用して 7.2 に進みます
  • 「自分で選ぶ」→ 改善点を AskUserQuestion の呼び出しごとに最大 4 件ずつ提示します (ステップ 4 の古いルールと同じアプローチ)。各改善点について、オプションは「適用」/「スキップ」です。すべての改善点が解決されるまで続けます。その後、承認された改善点のみを適用して 7.2 に進みます。
  • 「いいえ、レポートを保存するだけ」→ 変更は適用せず、停止

ユーザーが回答するまで、いかなる変更も適用しないでください。

7.2: 承認された改善を適用する

承認された各改善点について、対象を判断します:

スキルが組み込みの aif-* スキルである場合 (その SKILL.md がパッケージの skills/ ディレクトリ内にある場合):

  1. 必要に応じてディレクトリを作成します: mkdir -p .ai-factory/skill-context/
  2. .ai-factory/skill-context/<skill-name>/SKILL.md が存在しない場合 — ヘッダーテンプレートを使用して作成します
  3. 存在する場合 — 最初にそれを読み込み、各改善点について次のように判断します:
    • 既存のルールを更新 — 同じトピックに関するルールがすでに存在する場合 (例: 3 件のパッチから null チェックのルールが存在し、5 件の新しい null チェックのパッチが到着した → 既存のルールを強化し、その Source リストを更新し、新しい証拠に基づいて重大度/文言を調整する)
    • 新しいルールを追加 — このトピックをカバーする既存のルールがない場合
    • ルールを統合 — 複数の狭いルールを 1 つのより広いルールにまとめられる場合 (例: 3 つの別々の「フィールド X をチェックする」ルール → 1 つの「オプションの DB リレーションは常に null チェックする」ルール)
  4. ヘッダーの > Last updated: 行と > Based on: 行を更新します
  5. スキルの skills/aif-*/ ディレクトリ内のファイルは絶対に編集しないでください — そこにあるすべてのファイルは ai-factory が所有しており、更新時に上書きされます。すべての改善点は skill-context にのみ反映します。
  6. すべての変更を適用した後 (古いルールの削除を含む)、skill-context ファイルにルールが残っていない場合 (ヘッダーのみが残っている場合)、そのファイルとディレクトリを削除します: rm .ai-factory/skill-context/<skill-name>/SKILL.md rmdir .ai-factory/skill-context/<skill-name> (空の場合のみ)
  7. 古いルールの削除 (ステップ 4) の影響のみを受け、新しい改善点を受け取らなかった skill-context ファイルの > Based on: カウントと > Last updated: を更新します (これらは項目 4 ですでに更新済みです)。

スキルがカスタム/プロジェクトスキルである場合 (aif-* ではない場合):

  1. スキルの SKILL.md を直接編集します (既存の動作、変更なし)

コンテキストファイルのテンプレート:

重要: すべての skill-context ファイルは英語で記述しなければなりません。ユーザーの言語やパッチ/RULES.md で使用されている言語に関係なく、英語で記述します。skill-context のルールは AI エージェントによって消費されるため、英語にすることで、すべてのスキルとセッションにわたって一貫した解釈が保証されます。

# Project Rules for /<skill-name>

> Auto-generated by `/aif-evolve`. Do not edit manually.
> Last updated: YYYY-MM-DD HH:mm
> Based on: N analyzed patches

## Rules

### [Rule Name]
**Source**: [patch filenames or "codebase convention"]
**Rule**: [Specific, actionable instruction in English]

7.3: 進化ログを保存する

<resolved evolutions dir>/YYYY-MM-DD-HH.mm.md を作成します:

mkdir -p <resolved evolutions dir>

進化ログを保存した後、カーソル状態を更新します:

定義:

  • 「処理された新しいパッチ」= ファイル名が > last_processed_patch であるパッチ。
    • カーソルが存在しない場合 (初回実行): 「新しいパッチ」はパッチリスト全体です。
    • 重複パッチは「新しいパッチ」としてカウントしません。
  • 「適用された改善」= 少なくとも 1 つの承認された改善がディスクに書き込まれたこと (skill-context が更新された、および/またはカスタムスキルの SKILL.md が編集された)。

カーソル更新ルール:

  1. 新しいパッチが処理されなかった場合、カーソルは変更しないでください。
  2. 新しいパッチが処理された場合:
    • 改善が適用された場合: カーソルを最新の「新しいパッチ」のファイル名まで進めます。
    • 改善が適用されなかった場合 (例: ユーザーが「いいえ、レポートを保存するだけ」を選択した、またはすべてスキップした):
      • デフォルトではカーソルを進めないでください。
      • それでもカーソルを進めるかどうかをユーザーに尋ねてください。
        • 推奨: 再実行を可能にするため、カーソルは変更しないでください (LLM は防止ポイントを見落とす可能性があります)。
        • ユーザーが明示的に進めることを選択した場合、通常どおりカーソルを書き込みます。
  3. 変更が確定する前に実行が失敗した場合、カーソルを進めないでください。
# Evolution: YYYY-MM-DD HH:mm

## Intelligence Summary
- Patches analyzed: X
- Recurring patterns: [list]
- Tech stack: [from DESCRIPTION.md]

## Improvements Applied

### [skill-name] → skill-context
- [change description] ← driven by patches: [patch filenames]
  **File:** `.ai-factory/skill-context/[skill-name]/SKILL.md`

### [skill-name] → SKILL.md (custom skill)
- [change description] ← driven by: [tech stack / convention]
  **File:** `skills/[skill-name]/SKILL.md`

## Patterns Identified
- [pattern]: [frequency] occurrences
- [pattern]: [frequency] occurrences
ステップ 8：次のアクションを提案する
## Evolution Complete

Skills improved: X
Improvements applied: Y

### Recommendations

1. **Run `/aif-review`** on recent code to verify improvements
2. **Next evolution** — run `/aif-evolve` again after 5-10 more fixes
3. **Consider new skill** — if pattern X keeps recurring, create a dedicated skill:
   `/aif-skill-generator <skill-name>`
コンテキストのクリーンアップ

成果物の所有権

  • 主な所有権：.ai-factory/skill-context/*、<resolved evolutions dir>/*.md、および <resolved evolutions dir>/patch-cursor.json。
  • ここでの設定の利用は一部に限られます。config.yaml では説明、ルール、パッチ、進化ログのパスを解決しますが、skill-context は AI Factory 内部の固定パスのままです。
  • 読み取り専用のコンテキスト：ロードマップ、ルール、調査、計画の成果物。ただし、ユーザーが明示的に別途依頼した場合を除きます。

進化の完了後、/clear または /compact を提案してください。パッチの分析とスキルの処理後は、コンテキストが大量になります。

ルール

  1. 追跡可能 — すべての改善を、パッチ、規約、または技術的事実に関連付ける必要があります
  2. 最小限 — ルールは skill-context に追加し、ベーススキルを書き換えないでください
  3. 元に戻せる — 変更を適用する前に、ユーザーの承認を得てください
  4. 累積的 — 各進化は、それ以前の進化を基盤にします
  5. 幻覚を起こさない — 証拠に裏付けられた改善のみを提案してください
  6. 構造を維持 — ベーススキルのワークフローは変更せず、skill-context でのみ補強してください
  7. skill-context のみ — 組み込みの aif-* スキルに関する改善はすべて .ai-factory/skill-context/ に記述し、skills/aif-*/ には絶対に記述しないでください。skills/aif-*/ 内のファイルは絶対に編集しないでください — アップデート時に上書きされます。例外はありません。
  8. 英語のみ — ユーザーの言語にかかわらず、skill-context のファイルはすべて英語で記述してください
  9. 一般的なアドバイスは禁止 — 「クリーンなコードを書く」は改善ではありません。プロジェクト固有の改善のみを記述してください
  10. 新しいスキルは禁止 — 代わりに /aif-skill-generator を提案してください
  11. 適用範囲を失わない — ルールが古くなっている場合（ステップ 3～4）を除き、ルールを削除しないでください。 ステップ 7 での統合（細分化されたルールを、より広範なルールにまとめること）は、すべての防止事項が統合後のルールで維持される限り認められます。
  12. インストール済みのもののみ — プロジェクトにインストールされていないスキルを進化させないでください
  13. 所有権の境界 — このコマンドが所有するのは <resolved evolutions dir>/*.md、<resolved evolutions dir>/patch-cursor.json、および .ai-factory/skill-context/* です。ロードマップ、ルール、調査、計画の成果物は、明示的に依頼された場合を除き、読み取り専用のコンテキストとして扱ってください

例

/aif-evolve fix

→ Found 6/10 patches tagged #null-check
→ Improvement for /aif-fix (2 rules):
  Target: .ai-factory/skill-context/aif-fix/SKILL.md
  1. "PRIORITY CHECK: Look for optional/nullable fields accessed
      without null guards. This is the #1 source of bugs in this project."
  2. "When fixing nullable relation errors, check ALL usages of that
      relation in the same file — same bug often repeats nearby."

コメント

Markdown 対応