self-improving-agent

Self-Improvement Skill

継続的な改善のために、学びやエラーを Markdown ファイルに記録します。エージェントは後からこれらを処理して修正に反映でき、重要な学びはワークスペースのメモリに昇格されます。このバージョンのスキルは OpenClaw 専用です。他のエージェント向けには、https://github.com/pskoett/pskoett-ai-skills にある元のマルチエージェント版を参照してください。

記録、確認、再利用、昇格、メンテナンスは、この中だけで完結します。補助スキル、サービス、プラグイン、メモリバックエンド、OpenClaw コアの変更は不要です。オプションのフックは、リマインダーの表示とエラーの可能性の検出のみを行います。このワークフローを強制したり、主張を再検証したりするものではありません。

初回使用時の初期化

何かを記録する前に、プロジェクトまたはワークスペースのルートに .learnings/ ディレクトリとファイルが存在することを確認してください。足りないものがあれば作成します。

mkdir -p .learnings
[ -f .learnings/LEARNINGS.md ] || printf "# Learnings\n\nCorrections, insights, and knowledge gaps captured during development.\n\n**Categories**: correction | insight | knowledge_gap | best_practice\n\n---\n" > .learnings/LEARNINGS.md
[ -f .learnings/ERRORS.md ] || printf "# Errors\n\nCommand failures and integration errors.\n\n---\n" > .learnings/ERRORS.md
[ -f .learnings/FEATURE_REQUESTS.md ] || printf "# Feature Requests\n\nCapabilities requested by the user.\n\n---\n" > .learnings/FEATURE_REQUESTS.md

既存のファイルは上書きしないでください。.learnings/ がすでに初期化されている場合、何も行いません。

ユーザーが明示的にその詳細度を求めない限り、シークレット、トークン、秘密鍵、環境変数、ソース／設定ファイル全体を記録しないでください。生のコマンド出力や会話の全文ではなく、簡潔な要約や機密情報を伏せた抜粋を優先してください。

自動リマインダーとセッション終了時のエラー検出を有効にする場合は、オプション：フックを有効にするで説明しているオプトイン方式のフックを有効にしてください。

クイックリファレンス

状況	対応
コマンド／操作が失敗した	.learnings/ERRORS.md に記録します
ユーザーに修正された	カテゴリー correction を付けて .learnings/LEARNINGS.md に記録します
ユーザーが不足している機能を求めた	.learnings/FEATURE_REQUESTS.md に記録します
API／外部ツールが失敗した	連携の詳細とともに .learnings/ERRORS.md に記録します
知識が古くなっていた	カテゴリー knowledge_gap を付けて .learnings/LEARNINGS.md に記録します
より良い方法を見つけた	カテゴリー best_practice を付けて .learnings/LEARNINGS.md に記録します
繰り返し発生するパターンを簡素化／堅牢化する	Source: simplify-and-harden と安定した Pattern-Key を付けて .learnings/LEARNINGS.md に記録または更新します
既存の記録と似ている	Pattern-Key で検索し、同じ主張／適用範囲であることを確認します。新たに発生した場合のみ回数に加えます
保存した知識を再利用または昇格する	以下のメンテナンスに従い、一度限り／未昇格の記録も含め、関連する主張や確認時期が来た主張を確認します
ソース、判断、依存関係、タスクに変更があった	影響を受ける主張を再検証します。経過期間だけを理由に失効させないでください
ワークフローを改善する	AGENTS.md（ワークスペース）に昇格します
ツール固有の注意点	TOOLS.md（ワークスペース）に昇格します
行動パターン	SOUL.md（ワークスペース）に昇格します

OpenClaw のセットアップ

OpenClaw はワークスペースベースのプロンプトインジェクションを使用し、スキルを自動的に読み込みます。

インストール

OpenClaw 組み込みインストーラーを使用（推奨） — アクティブな OpenClaw ワークスペースにインストールします。

openclaw skills install @pskoett/self-improving-agent

ClawHub CLI を使用（npm i -g clawhub）— ワークスペースではなく、現在の作業ディレクトリ内の ./skills にインストールします。

clawhub install @pskoett/self-improving-agent

手動（このスキルはリポジトリの self-improving-agent/ サブフォルダーにあります。リポジトリのルートではなく、そのフォルダーをコピーしてください）。

git clone https://github.com/pskoett/self-improving-agent.git /tmp/self-improving-agent-repo
cp -r /tmp/self-improving-agent-repo/self-improving-agent ~/.openclaw/skills/self-improving-agent

元のリポジトリを基に openclaw 向けに作り直しました：https://github.com/pskoett/pskoett-ai-skills - https://github.com/pskoett/pskoett-ai-skills/tree/main/skills/self-improvement

ワークスペースの構成

OpenClaw は、これらのファイルをすべてのセッションに挿入します。

~/.openclaw/workspace/
├── AGENTS.md          # Multi-agent workflows, delegation patterns
├── SOUL.md            # Behavioral guidelines, personality, principles
├── TOOLS.md           # Tool capabilities, integration gotchas
├── MEMORY.md          # Long-term memory (main session only)
├── memory/            # Daily memory files
│   └── YYYY-MM-DD.md
└── .learnings/        # This skill's log files
    ├── LEARNINGS.md
    ├── ERRORS.md
    └── FEATURE_REQUESTS.md

学習ファイルの作成

mkdir -p ~/.openclaw/workspace/.learnings

次にログファイルを作成します（または assets/ からコピーします）。

• LEARNINGS.md — 修正、知識の不足、ベストプラクティス
• ERRORS.md — コマンドの失敗、例外
• FEATURE_REQUESTS.md — ユーザーが求めた機能

昇格先

学びが広く適用できると確認できたら、ワークスペースファイルに昇格させます。

学びの種類	昇格先	例
行動パターン	SOUL.md	「簡潔にし、免責事項を避ける」
ワークフローの改善	AGENTS.md	「長いタスクではサブエージェントを起動する」
ツール固有の注意点	TOOLS.md	「Git push の前に認証を設定する必要がある」

セッション間の通信

OpenClaw には、セッション間で学びを共有するためのツールがあります。

• sessions_list — アクティブなセッション／最近のセッションを表示します
• sessions_history — 別のセッションのトランスクリプトを読み取ります
• sessions_send — 学びを別のセッションに送信します
• sessions_spawn — バックグラウンド作業用のサブエージェントを起動します

これらは信頼できる環境で、ユーザーがセッション間の共有を明示的に希望している場合にのみ使用してください。生のトランスクリプト、シークレット、コマンド出力全体ではなく、サニタイズした短い要約と関連するファイルパスを送ることを優先してください。

オプション：フックを有効にする

セッション開始時の自動リマインダーとセッション終了時のエラー検出を有効にするには、 フックのインストールまたはアップグレードに従ってから、 openclaw hooks enable self-improvement で有効にしてください。実際の スキル／フックのパスを選び、ローカルのパッチを確認し、置き換える前に古いコピーを保存してください。

agent:bootstrap で実行されます（リマインダーに加え、自動検出されたエラーのレビュー待ちがある場合はトリアージ待ちのメモを挿入します）。また、command:new／command:reset では、終了したセッションのトランスクリプトからエラーパターンを検索し、 <workspace>/.learnings/ERRORS.md に記録します（オプトイン方式で、.learnings/ が存在する場合にのみ実行されます）。内部の HOOK.md イベントにはツール呼び出しごとのコールバックがないため、この統合ではセッション終了時にエラーを検出します。OpenClaw の型付きプラグインフックでは、別途 after_tool_call が公開されています。フックシステムと制限を参照してください。

ログ形式

assets/LEARNINGS.md、assets/ERRORS.md、または assets/FEATURE_REQUESTS.md のテンプレートを使って、項目を追記します。観察内容、コンテキスト、推奨アクション、メタデータを記載してください。記入済みの項目については、例を参照してください。

記録時には、再利用可能な主張ごとに、以下の Maintenance ブロックを追加してください。推論がまだ確立されていない場合は、ルールを作り上げるのではなく、Claim: unknown — needs triage と記録してください。既存の項目は引き続き有効なログ記録です。関連するレビューで記録または編集するときに限り、メタデータを初期化してください。まとめて移行する必要はありません。

Maintenance：原因に応じたコンテキストの経時的な陳腐化

過去の観察内容は失効しません。インシデントが起きたかどうかではなく、再利用可能な推論や指示を維持してください。これは、単発の項目や昇格されていない項目も含め、3 つすべての .learnings/ ファイルに適用されます。真実であることと有用であることは別です。事実が正しくても今回のタスクには無関係な場合があり、有用な回避策がすでに正しくない場合もあります。

再検証の方法は種類によって異なります

種類	確認方法
reality	対象範囲の事実について、現在の信頼できる情報源を読むか、現在の環境を調べます。
decision	信頼でき、適用対象となる、後続の決定を探し、その適用範囲と有効状態を確認します。経過時間や別のチームの選択だけでは、決定は置き換わりません。
dependency	関連するバージョン／構成を特定してから、その環境で代表的な動作確認を行います。アップグレードは確認を促すものであり、自動的な廃止を意味しません。
relevance	現在のタスク／プロジェクトに対する適用性と有用性を評価します。使われていないことは、誤りの証明にはなりません。

原因が特定されていない場合は、unknown を使用してください。主張に複数の原因がある場合は、それぞれを確認するか、名前付きの Maintenance ブロックに分けてください。優先度、ステータス、再発状況、Pattern-Key の正規表現マッチから、意味的な種類や頻度を推測しないでください。セッションのスイープ結果には無関係なエラーが混在する場合があります。元のスイープ結果を保持してリンクしたうえで、トリアージ時に主張を分類してください。

Rate はレビューのタイミングを示します

• fast：変化しやすいため、関連する用途ごとに確認します。
• medium：作業中に、関連するタスクやプロジェクトの節目で見直します。
• slow：安定しているため、関連する大きな変更や節目に合わせて、ときどき見直します。
• durable：継続することが想定されます。権威性、前提、または適用可能性に疑義が生じたときに見直します。
• unknown：確認された見直し頻度はまだありません。これに依拠する前に優先度を判断します。

これらは定性的な頻度であり、普遍的な半減期、有効期限、削除ルールではありません。主張に対する具体的なトリガーを記録してください。関連する出来事（情報源の更新、後継となる決定、依存関係や設定の変更、プロジェクトやタスクの変化、矛盾）があれば、durable の主張であっても、見直し頻度にかかわらず見直してください。スケジューラーや自律的なバックグラウンドでの再検証は不要です。

元のエントリーの横に付ける軽量なメタデータ

### Maintenance
- Claim: reusable inference/instruction, or unknown — needs triage
- Scope: applicable project/task/environment and limits, or unknown
- Authority: source path/section, decision ID, environment, or unknown
- Decay: reality | decision | dependency | relevance | unknown / fast | medium | slow | durable | unknown
- Revalidate: event/cadence; specific check to perform
- Validation: pending | verified | unresolved | contradicted
- Evidence: none yet; when checked, actual date, source/version/configuration, check and result (including failures/conflicts)
- Disposition: retain | revise | externalize | retire; reason and task applicability
- Guidance: none, or target file + section and source-learning ID

実際のエビデンスがそれ以上を裏付けていない限り、Validation: pending、Evidence: none yet、Disposition: retain — provisional, not validated から始めてください。レビューを試みただけでは検証になりません。エビデンスを入手できない場合や矛盾する場合は、unresolved のままにし、試行日、障害となっている事項、次回確認日を記録してください。検証が成功した日付を更新してはいけません。後から結果を追記する際は、過去のエビデンスに日付と適用範囲を付けて保持してください。Status は問題の解決や昇格を追跡し、Validation は主張の裏付けを追跡し、Disposition は現在有効な指針を追跡します。いずれも、他の項目の状態を示すものではありません。

レビュー、再利用、昇格のループ

1. 選択 現在のタスクに関連する項目を、領域、ファイル、キーワード、ソース ID、さらに自然な区切りで影響を受ける主張や期限を迎える主張に基づいて選びます。毎ターンログ全体を監査したり、保留中・昇格済み・繰り返し発生した項目だけを選んだりしないでください。
2. トリアージ レガシー項目や複数の内容が混在する項目を確認します。再利用可能な主張、その適用範囲、根拠、種類／割合、トリガーを特定します。不明な点は明示したままにします。インシデントが解決したこと、復旧に成功したこと、または同じ事象が繰り返し発生したことは、どこでも通用するルールの証明にはなりません。
3. 確認 再利用または昇格の前に、適用可能性と、トリガーが作動したか、または証拠の確認時期が来ているかを確認します。必要に応じて種類に適したチェックを実施し、実行する予定だったコマンドではなく、実際の証拠を記録します。証拠がない、または矛盾している場合、その主張を検証済みとして提示または昇格しないでください。不確実性を明示し、情報源を探すか、適切な適用範囲の代替策を使用します。問題が解決するまで、安全策を取り除かないでください。
4. 選択 retain（裏付けがあり有用なもの、または問題の解決待ちであることを明示した暫定的なもの）、revise（証拠に基づいて修正または適用範囲を狭める）、externalize（変わりやすい詳細を、実行可能な参照手順に置き換える）、retire（証拠に基づく理由を添えて、アクティブなガイダンスから除外する）のいずれかを選びます。外部化する場合は、参照先、読み取る／テストする内容、アクセスできない場合や内容が矛盾する場合の対応を明記します。「ドキュメントを確認」のような曖昧な指示では不十分です。検証済みとして扱う前に、参照手順が実際に利用できることを確認してください。
5. 記録して反映：結論、理由、証拠、および変更した場合は変更前 → 変更後の主張を含む、日付入りのレビューノートを追記します。元の観察、解決内容、昇格先／昇格日、過去のレビューを保持します。レビューを実施しただけで Recurrence-Count／Last-Seen を増やさないでください。

学習／昇格の履歴を消去したり、経過時間を理由に削除したりしないでください。古い、または未使用というだけの理由で、ユーザーの設定を変更したり、セキュリティポリシーを弱めたり、スキルのアセットを書き換えたりしないでください。スキルの作成／変更には、対象を明示した承認が必要です。この連携に対する承認は、今後のスキルの書き換えを許可するものではありません。必要な編集先が許可された範囲外にある場合は、提案する変更をソース項目に保留中として記録し、更新済みだと黙って主張するのではなく、現在も有効なガイダンスを報告してください。

レビュー結果の作業例と来歴については、保守の例を参照してください。 保守指示を評価するには、保守の動作評価にある隔離されたシナリオを使用してください。 これらは評価用のフィクスチャであり、通常の学習記録中に実行するチェックではありません。

ID の生成

形式：TYPE-YYYYMMDD-XXX

• TYPE：LRN（学習）、ERR（エラー）、FEAT（機能）
• YYYYMMDD：現在の日付
• XXX：連番またはランダムな 3 文字（例：001、A7B）

例：LRN-20250115-001、ERR-20250115-A3F、FEAT-20250115-002

項目の解決

問題を修正したら、項目を更新します。

1. **Status**: pending → **Status**: resolved に変更します
2. Metadata の後に解決ブロックを追加します：

### Resolution
- **Resolved**: 2025-01-16T09:00:00Z
- **Commit/PR**: abc123 or #42
- **Notes**: Brief description of what was done

その他のステータス値：

• in_progress - 対応中
• wont_fix - 対応しないことを決定（Resolution notes に理由を追加）
• promoted - ワークスペースファイル（SOUL.md、TOOLS.md、AGENTS.md）に昇格済み

昇格時も Resolution ブロックを保持します。修正が機能したことは、そのインシデントで何が起きたかを示します。再利用可能なルールは、別途 Maintenance を通じて検証してください。

ワークスペースメモリへの昇格

学習内容が広く適用できる場合（単発の修正ではない場合）は、ワークスペースファイルに昇格させ、すべてのセッションに引き継がれるようにします。

昇格するタイミング

• 複数のファイル／機能にまたがって適用される学習内容
• 人間または AI のすべてのコントリビューターが知っておくべき知識
• 繰り返し発生するミスを防ぐ
• プロジェクト固有の慣習を記録する

昇格先

対象	記載する内容
SOUL.md	行動指針、コミュニケーションスタイル、原則
TOOLS.md	ツールの機能、使用パターン、統合時の注意点
AGENTS.md	ワークフロー、委任パターン、自動化ルール

学びが、作業するワークスペースではなく特定のプロジェクトリポジトリに関するものである場合は、そのプロジェクト独自のエージェントファイル（例：そのプロジェクトの AGENTS.md）に昇格させてください。

昇格方法

1. 確認：まず Maintenance を通じて、対象範囲を限定した主張を確認します。未解決の仮定や、単に繰り返し発生したという理由だけではなく、裏付けのある有用なガイダンスのみを昇格させてください。
2. 要約して追加：適切な対象に、簡潔で対象範囲を限定したルール、または実際に使える検索指示を追加します。その横に Source: .learnings/<file>.md#<entry-ID> を記載してください（対象ファイルからの実際の相対パスを使用します。レンダラーのアンカーが異なっても、IDで検索できます）。
3. 元のエントリを更新：**Status**: promoted に設定し、昇格日と対象ファイル／セクションを追記して、Guidance をその場所に設定します。解決内容と過去の昇格履歴は保持してください。以後の改訂では、この相互リンクに従います。

昇格の例

学び（冗長）：

プロジェクトでは pnpm ワークスペースを使用します。npm install を試しましたが失敗しました。
ロックファイルは pnpm-lock.yaml です。pnpm install を使用する必要があります。

TOOLS.md 内（検索経路の確認後に外部化）：

## Build & Dependencies
- Before installing, read this repo's `package.json` `packageManager` field and lockfile. Use the declared manager; if missing or conflicting, consult the build instructions/maintainer before installing. Source: .learnings/LEARNINGS.md#LRN-20250115-002

学び（冗長）：

API エンドポイントを変更する際は、TypeScript クライアントを再生成する必要があります。
これを忘れると、実行時に型の不一致が発生します。

AGENTS.md 内（実行可能）：

## After API Changes
1. Regenerate client: `pnpm run generate:api`
2. Check for type errors: `pnpm tsc --noEmit`
Source: .learnings/LEARNINGS.md#LRN-20250116-001 (scope: this repo's current generator/configuration)

パターンキーの分類

Pattern-Key は、3つすべてのログファイルのエントリにおける、安定した重複排除・再発判定キーです。キーワード検索では、意味は同じでも表現が異なるエントリを見落としますが、共通のキーなら見落としません。また、信頼できるキーがあってこそ、Recurrence-Count と昇格ルールが機能します。

形式：area.symptom — 小文字とハイフンを使った、正確に2階層の形式です（例：deps.module-not-found）。キーにはファイル名、バージョン、ホスト名を含めず、症状は再発しうる汎用的なものにしてください。

分野	範囲	キーの例
api	外部 API／サービスの動作	api.rate-limit、api.schema-mismatch、api.missing-endpoint
auth	認証情報、トークン、スコープ	auth.token-expired、auth.missing-scope
build	コンパイル、バンドル、CI	build.type-error、build.missing-artifact
config	設定ファイル、環境変数、設定	config.missing-env、config.invalid-json
deps	パッケージマネージャー、依存関係	deps.module-not-found、deps.npm-error、deps.version-conflict
fs	ファイルシステム	fs.no-such-file、fs.permission-denied
net	ネットワーク接続	net.connection-refused、net.timeout
runtime	上記でカバーされない言語／ランタイムエラー	runtime.type-error、runtime.python-exception
shell	シェル／コマンドラインの動作	shell.command-not-found、shell.nonzero-exit
vcs	Git およびその他のバージョン管理	vcs.fatal-error、vcs.merge-conflict
simplify / harden	simplify-and-harden フィードからのコード品質パターン	simplify.dead_code、harden.input_validation

ルール：

1. 新規作成より再利用を優先：grep -rh "Pattern-Key:" .learnings/ | sort -u — 新しいキーを作るより、ほぼ一致するキーを使ってください。
2. 手動のエントリにはキーを1つだけ付与します。自動収集された OpenClaw のエントリには複数のキーが付く場合があります。無関係な主張は個別にトリアージし、保持された収集記録へのリンクを付けてください。
3. 新しい分野の追加は控えめに行ってください。同じ分野を共有するエントリが複数ある場合に限ります。
4. 汎用的な収集キー（runtime.error、runtime.failure）は「未分類」を意味します。トリアージ時に、より具体的なキーに置き換えてください。

再発パターンの検出

既存のエントリーに似た内容を記録する場合：

1. まずキーで検索する：grep -n "Pattern-Key: area.symptom" .learnings/*.md — これがデフォルトの重複チェックです。キーワード検索では見つからない言い換えも検出できます
2. キーワード検索で補完する：キーなしで記録されたエントリーを対象に、grep -ri "keyword" .learnings/ を実行します
3. 重複させず、統合する：キーが一致するだけでなく、主張と適用範囲が同じであることを確認します。実際に新たな事例が発生した場合は、Recurrence-Count を増やし、Last-Seen を設定して、証拠へのリンクを追加します。レビューや再読は再発には該当しません
4. 問題が繰り返し発生する場合は、優先度を上げる
5. システム上の修正を検討する：問題の再発は、多くの場合、次のような不足を示しています。
   • ナレッジの不足（→ TOOLS.md または SOUL.md に昇格する）
   • 自動化の不足（→ AGENTS.md に追加する）
   • アーキテクチャ上の問題（→ 技術的負債のチケットを作成する）

簡素化と堅牢化のフィード

タスクで簡素化・堅牢化の候補が提示された場合は、ここに取り込みます。他のスキルは必要ありません。手動で記録する場合も、同じ再発およびメンテナンスのルールに従います。

取り込みワークフロー

1. タスクの要約から simplify_and_harden.learning_loop.candidates を読み取ります。
2. 各候補について、安定した重複排除キーとして pattern_key を使用します。
3. .learnings/LEARNINGS.md で、そのキーを持つ既存のエントリーを検索します。
   • grep -n "Pattern-Key: <pattern_key>" .learnings/LEARNINGS.md
4. 見つかった場合：
   • 同じ適用範囲の主張について新たな事例が発生した場合に限り、Recurrence-Count を増やし、Last-Seen を更新します
   • 関連するエントリーやタスクへの See Also リンクを追加します
5. 見つからなかった場合：
   • 新しい LRN-... エントリーを作成します
   • Source: simplify-and-harden を設定します
   • Pattern-Key、Recurrence-Count: 1、および First-Seen／Last-Seen を設定します

昇格ルール（システムプロンプトへのフィードバック）

次の条件をすべて満たす場合、再発パターンの昇格を検討します。

• Recurrence-Count >= 3
• 少なくとも 2 つの異なるタスクで確認されている
• 30 日以内に発生している

これらは候補となるシグナルであり、証明や期限のルールではありません。昇格の前にメンテナンスを適用してください。これらのしきい値を満たさない一度限りの学びにも、引き続きメンテナンスを行います。

昇格先：SOUL.md、TOOLS.md、AGENTS.md（ワークスペース）、またはパターンがプロジェクト固有の場合は、そのプロジェクト独自のエージェントファイルです。

昇格するルールは、長いインシデント報告ではなく、短い予防ルール（コーディングの前または最中に行うこと）として記述します。

定期レビュー

ログ全体を毎ターン確認するのではなく、自然な区切りでメンテナンスを適用し、関連する主張やレビュー時期を迎えた主張を確認します。

レビューするタイミング

• 新しい大規模なタスクを始める前
• 機能を完成させた後
• 過去の学びがある領域に取り組むとき
• 開発を積極的に進めている間は毎週

簡易ステータスチェック

# Count pending items
grep -h "Status\*\*: pending" .learnings/*.md | wc -l

# List pending high-priority items
grep -B5 "Priority\*\*: high" .learnings/*.md | grep "^## \["

# Find learnings for a specific area
grep -l "Area\*\*: backend" .learnings/*.md

レビュー時の対応

• 修正済みの項目を解決済みにする
• 一度限りの学びや未昇格の学びも含め、ステータスを問わず、関連する主張やレビュー時期を迎えた主張を再検証する
• 履歴を保持しながら、アクティブなガイダンスを維持、改訂、外部化、または廃止する
• 裏付けがあり適用可能な学びを、出典リンクとともに昇格する
• 関連するエントリーをリンクする
• 再発する問題をエスカレーションする

検出トリガー

記録する前に、イベントを文脈に沿って評価してください。以下のフレーズは手がかりであり、 自動的に記録する指示ではありません。通常の質問やフォローアップタスクだけでは、 永続的なエントリを作成する理由にはなりません。

訂正（→ correction カテゴリの学習）：

• 「いいえ、それは違います……」
• 「実際には、こうなるはずです……」
• 「その点については間違っています……」
• 「それは古い情報です……」

機能リクエスト（→ 機能リクエスト）：

• 関連するツール／バージョンに存在しないことが示された機能のみを記録します。根拠と制限事項を記録してください。
• 「これもできますか？」や「何か方法はありますか？」だけでは、機能が欠けている根拠にはなりません。通常どおり既存の機能を使用し、通常のフォローアップは記録しないでください。
• 利用可能かどうかが不明な場合は、ドキュメントまたはツールの動作を確認するか、質問してください。表現だけを根拠に機能リクエストを作成しないでください。

知識の不足（→ knowledge_gap カテゴリの学習）：

• ユーザーが、知らなかった情報を提供した
• 参照したドキュメントが古い
• API の動作が理解と異なる

エラー（→ エントリのエラー）：

• コマンドがゼロ以外の終了コードを返す
• 例外またはスタックトレースが発生する
• 予期しない出力または動作がある
• タイムアウトまたは接続失敗が発生する

優先度のガイドライン

優先度	使用する状況
critical	コア機能がブロックされる、データ損失のリスクがある、セキュリティ上の問題がある
high	影響が大きく、一般的なワークフローに影響する、問題が繰り返し発生する
medium	影響は中程度で、回避策がある
low	軽微な不便、まれなケース、あると便利な機能

領域タグ

コードベースの領域ごとに学習内容を絞り込むために使用します。

領域	対象範囲
frontend	UI、コンポーネント、クライアント側のコード
backend	API、サービス、サーバー側のコード
infra	CI/CD、デプロイ、Docker、クラウド
tests	テストファイル、テスト用ユーティリティ、カバレッジ
docs	ドキュメント、コメント、README
config	設定ファイル、環境、設定値

ベストプラクティス

1. すぐに記録する - 問題の直後が最も文脈を把握しやすいタイミングです
2. 具体的に記述する - 後続のエージェントがすばやく理解できるようにします
3. 再現手順を含める - 特にエラーの場合は重要です
4. 関連ファイルにリンクする - 修正が容易になります
5. 具体的な修正案を提案する - 「調査する」だけで終わらせないでください
6. 一貫したカテゴリを使用する - 絞り込みが可能になります
7. 根拠のあるガイダンスを昇格する - まず対象範囲と有用性を検証し、出典情報を保持します
8. 原因と頻度に基づいて見直す - 古いというだけでは、誤りや役に立たないことの証明にはなりません

Gitignore のオプション

学習内容をローカルに保持する（開発者ごと）：

.learnings/

このリポジトリでは、機密性の高いローカルログやノイズの多いローカルログを誤ってコミットしないよう、この既定の設定を使用しています。

リポジトリで学習内容を追跡する（チーム全体）： .gitignore に追加しないでください。学習内容が共有ナレッジになります。

ハイブリッド（テンプレートを追跡し、エントリは無視する）：

.learnings/*.md
!.learnings/.gitkeep

アップグレードとアンインストール

アップグレードする前に CHANGELOG.md を読んでください。バージョンごとの注意事項が記載されており、 フックを変更した場合は、フックを再コピーしてゲートウェイを再起動する必要があります。 スキルを無効化または削除するには、references/uninstall.md の手順に従ってください。 無効化とアンインストールでは、.learnings/ と昇格済みのワークスペースルールが保持されます。 データの完全な削除や、昇格済みガイダンスの編集には、別途明示的な承認が必要です。これらはアンインストールには含まれません。

スキルの抽出（承認が必要）

学習内容が再利用可能なスキルの根拠になり得る場合は、assets/SKILL-TEMPLATE.md を使用してください。抽出は任意であり、メンテナンスの前提条件ではありません。スキルアセットを作成または変更する前に、対象範囲を明示した承認を得てください。

テンプレートには、候補の基準、ヘルパーコマンド、品質ゲート、双方向の出典情報が含まれています。抽出する前に対象範囲を明示した主張を確認してください。インシデントが解決したことや再発したことだけでは、検証になりません。以降のアセット変更にも、それぞれ個別の対象範囲を明示した承認が必要です。