self-learning

概要

自己学習スキルは、セッションをまたいでプロジェクトのコンテキストを自動的に発見し、理解して保持します。実際のプロジェクト成果物をスキャンすることで、コードベース、技術スタック、慣習、チームの好みに関するメンタルモデルを構築します。自己学習がなければ、セッションは毎回ゼロから始まります。自己学習があれば、エージェントは組織内の知識を蓄積し、時間の経過とともに精度を高め、エラーを減らします。

開始時に宣言します：「このプロジェクトを理解するために、自己学習スキルを使用しています。」

---

フェーズ 1：トリガーの特定

このスキルを起動したトリガーを特定します。

トリガー	コンテキスト	アクション
新規プロジェクト	メモリファイルが存在しない	全体の調査（フェーズ 2～5）
不慣れな領域	コードベースの未知の部分で作業している	対象を絞った調査（その領域のフェーズ 2～3）
ユーザーによる修正	ユーザーが「それは間違っています」と言う、または前提を修正する	修正プロトコル（フェーズ 6）
明示的な /learn	ユーザーがコマンドを実行する	全体の調査（フェーズ 2～5）
セッション開始	メモリファイルが存在するが、古くなっている可能性がある	メモリを読み込み、検証する（フェーズ 7）

停止：先に進む前に、トリガーを特定してください。トリガーによって必要なフェーズは異なります。

---

フェーズ 2：プロジェクト構成のスキャン

Explore エージェントを使用して、優先度順に以下のファイルを調べます。

ファイル／ディレクトリ	判明する内容	優先度
package.json / pyproject.toml / go.mod / Cargo.toml / composer.json	技術スタック、依存関係、スクリプト	最重要
README.md / CLAUDE.md / AGENTS.md	プロジェクトの目的、慣習、ルール	最重要
ディレクトリ構成（上位 2 階層）	アーキテクチャパターン（モノレポ、MVC、ヘキサゴナルなど）	最重要
tsconfig.json / eslint.config.* / .prettierrc / phpstan.neon	コーディング規約、厳格さのレベル	高
.gitignore	除外対象、デプロイの手掛かり	高
docker-compose.yml / Dockerfile	インフラストラクチャ、サービス	中
.github/workflows/ / .gitlab-ci.yml	CI/CD の構成、必須チェック	中
.env.example	環境変数、外部サービス	中
specs/ / docs/	既存の仕様とドキュメント	中

アクション： 見つかった各ファイルから重要な情報を抽出します。すべてのファイルを読むのではなく、要点を絞ってスキャンしてください。

停止：コードパターンを分析する前に、構成のスキャンを完了してください。

---

フェーズ 3：コードパターンの分析

代表的なファイルを 3～5 個調べて、パターンを特定します。

パターンのカテゴリ	確認する内容	指標の例
命名規則	変数／関数／ファイルの命名	camelCase、snake_case、kebab-case、PascalCase
インポート／エクスポート	モジュールの構成	バレルエクスポート、相対パスと絶対パス、パスエイリアス
エラー処理	失敗の管理方法	try/catch、Result 型、エラーバウンダリー、カスタム例外
テストパターン	テストフレームワークとスタイル	ファイル名（*.test.ts と *.spec.ts など）、構成（describe/it と test など）
状態管理	データの流れ	Redux、Zustand、Context、Vuex、Pinia、Livewire
API パターン	通信方式	REST、GraphQL、tRPC、RPC、WebSocket
データベースアクセス	データレイヤーの方式	ORM（Prisma、Eloquent、TypeORM）、生 SQL、クエリビルダー
コンポーネントパターン	UI の構造	アトミックデザイン、機能別フォルダー、スタイルの同一配置

アクション： コードベースの異なる領域から 3～5 個のファイルを開きます。具体例とともに、観察したパターンを記録します。

---

フェーズ 4：Git 履歴の分析

git log --oneline -20          # Recent commits — development velocity, commit style
git shortlog -sn -20           # Active contributors
git branch -a                  # Branching strategy
git log --diff-filter=A --name-only --pretty=format: -10 | head -30  # Recently added files

抽出する内容： 開発の速度、コミットメッセージの慣習、ブランチ戦略、活発な領域。

停止：メモリに保存する前に、すべての調査フェーズを完了してください。

---

フェーズ 5：メモリへの保存

以下のメモリファイルを更新します（存在しない場合は作成し、存在する場合は追記します）。

memory/project-context.md

# Project Context



## Purpose
[What this project does, who it is for]

## Tech Stack
- Language: [e.g., TypeScript 5.x]
- Framework: [e.g., Next.js 15]
- Database: [e.g., PostgreSQL via Prisma]
- Testing: [e.g., Vitest + Playwright]
- CI/CD: [e.g., GitHub Actions]

## Architecture
[e.g., Monorepo with apps/ and packages/]
[Key directories and their purposes]

## Key Dependencies
[Critical libraries and their roles]

memory/learned-patterns.md

# Learned Patterns



## Naming Conventions
[What was observed with specific examples]

## Code Organization
[Import patterns, file structure, module boundaries]

## Error Handling
[How errors are handled in this project with examples]

## Testing Approach
[Framework, patterns, naming, coverage expectations]

memory/user-preferences.md

# User Preferences



## Communication Style
[Terse? Detailed? Prefers code over explanation?]

## Workflow Preferences
[PR workflow? Branch naming? Commit style?]

## Review Preferences
[What they focus on in reviews?]

memory/decisions-log.md

# Decisions Log


## YYYY-MM-DD: [Decision Title]
**Decision:** [What was decided]
**Context:** [Why this came up]
**Rationale:** [Why this was chosen over alternatives]
**Alternatives considered:** [What else was considered]

---

フェーズ 6：修正プロトコル

ユーザーが前提を訂正した場合：

1. 受け止める — すぐに訂正を認め、誤った前提を正当化しないでください
2. 特定する — 更新すべきメモリファイルを特定してください
3. 更新する — 日付と背景情報を含めて、メモリファイルを訂正内容で更新してください
4. 適用する — 現在の作業にすぐに訂正を反映してください
5. 波及を確認する — 訂正によってメモリ内のほかの前提が無効にならないか確認してください

訂正の種類	更新するメモリファイル	例
命名規則の誤り	learned-patterns.md	「camelCaseではなく、snake_caseを使います」
技術スタックの誤り	project-context.md	「Jestではなく、Vitestを使います」
ワークフローの好み	user-preferences.md	「必ずPRを作成し、mainにはプッシュしないでください」
アーキテクチャの誤解	project-context.md	「それはモノリスではなく、マイクロサービスです」
決定の背景	decisions-log.md	「Zではなく、Yを理由にXを選びました」

メモリの更新を省略しないでください。保存されない訂正は、繰り返されます。

---

フェーズ 7：セッション開始時 — メモリの検証

メモリファイルがすでに存在する場合：

1. memory/ ディレクトリからすべてのメモリファイルを読み込みます
2. Last updated の日付を確認し、30日を超えて古いものがあればフラグを立てます
3. 2～3件の事実を現在のコードベースと照合します（例：package.json に今も同じフレームワークが記載されているか）
4. 不一致が見つかった場合、変更された領域を対象に再スキャンを実施します
5. 古くなった項目を最新情報で更新します

---

決定表：調査の深さ

状況	調査の深さ	所要時間
メモリファイルのない新規プロジェクト	全フェーズ	3～5分
既知のプロジェクトの新しい領域	対象を絞る（その領域のみフェーズ 2～3）	1～2分
ユーザーによる訂正	訂正プロトコルのみ（フェーズ 6）	30秒
既存メモリがある状態でのセッション開始	検証のみ（フェーズ 7）	1分
大規模なリファクタリングを検出（変更ファイル多数）	全体を再スキャン	3～5分

---

反パターン／よくある間違い

やってはいけないこと	失敗する理由	代わりにすること
プロジェクト内の全ファイルを読む	コンテキストウィンドウを浪費し、時間がかかります	戦略的にスキャンします。まず設定ファイルを確認し、次に代表的なコードファイルを3～5件確認します
1つのファイルから規約を推測する	そのファイルだけが例外かもしれません	保存する前に、2つ以上のファイルでパターンを確認します
メモリファイルを完全に上書きする	履歴やユーザーの訂正が失われます	履歴を残しながら、特定のセクションを追記または更新します
Gitの履歴を確認しない	開発の速度やチームのパターンを見落とします	必ず最近のコミットとコントリビューターを確認します
推測を事実として保存する	誤った情報で今後のセッションに悪影響を与えます	証拠に裏付けられた観察事項のみを保存します
ユーザーの訂正を無視する	同じ間違いを繰り返します	訂正はただちに観察事項に優先させます
実装の詳細を深掘りする	木を見て森を見失います	個別のロジックではなく、パターンと規約に注目します
セッション開始時にメモリの検証を省略する	古い情報を使ってしまいます	メモリを現在のコードベースと必ず照合します

---

自己正当化を防ぐガード

考え	実際のところ
「このフレームワークはもう知っています」	このプロジェクト固有の規約は分かりません。スキャンしてください。
「メモリファイルは十分新しいはずです」	それでも照合してください。コードは急速に変化します。
「この訂正は些細なことです」	些細な訂正が大きな間違いを防ぎます。保存してください。
「書き留めなくても覚えておけます」	覚えていられません。セッションは独立しています。メモリに保存してください。
「スキャンには時間がかかりすぎます」	スキャンをしないと誤った前提につながり、修正にさらに時間がかかります。

メモリへの保存を省略しないでください。発見したことは書き留めてください。

---

統合ポイント

スキル	関係
using-toolkit	セッション開始時に自己学習を開始します
brainstorming	アイデア生成の前にプロジェクトのコンテキストを読み込みます
planning	学習したパターンを活用し、一貫性のあるアプローチを提案します
code-review	学習した規約に照らしてコードをチェックします
auto-improvement	発見の有効性に関する指標を記録します
resilient-execution	失敗パターンを今後のアプローチ選択に活用します

---

具体例

発見コマンドの実行順序

# Step 1: Identify tech stack
cat package.json | head -50
# or
cat composer.json | head -50
# or
cat pyproject.toml

# Step 2: Check project structure
ls -la
ls -la src/ || ls -la app/ || ls -la lib/

# Step 3: Examine coding standards
cat tsconfig.json 2>/dev/null || cat phpstan.neon 2>/dev/null
cat .eslintrc* 2>/dev/null || cat .prettierrc* 2>/dev/null

# Step 4: Git activity
git log --oneline -20
git shortlog -sn -20

修正後のメモリ更新

## 2026-03-15: Naming Convention Correction
**Previous assumption:** Project uses camelCase for database columns
**Correction:** Project uses snake_case for database columns (user corrected)
**Evidence:** Checked `migrations/` directory — all columns use snake_case
**Updated:** learned-patterns.md, Naming Conventions section

---

主な原則

• 推測せず、観察する — コードベースの証拠に基づいて学習します
• 段階的に更新する — メモリファイルに追記し、上書きしません
• 保存前に検証する — 2つ以上の例で観察内容を再確認します
• 修正を尊重する — ユーザーによる修正は、直ちに観察内容より優先されます
• 最新の状態を保つ — 大きな変更があった場合は再スキャンします

---

スキルの種類

RIGID — 発見フェーズは順番どおりに実施する必要があります。メモリへの保存は必須です。修正は直ちに記録する必要があります。フェーズを省略したり、スキャンの必要性を正当化して回避したりしないでください。