# Post Project Learning Engine

> プロジェクトやタスクの完了後に起動する「学習エンジン」。AIエージェントの作業内容・成果物・ユーザー反応を分析し、復元した成功条件との差分から、次回の行動ルールを When / Then 形式で抽出して Learning Log を生成する。単なる反省文ではなく、次回の挙動を改善する Candidate（候補）を作るのが目的で、抽出した学習を恒久スキルに直接昇格させない。プロジェクト・案件・開発タスクが一段落した後の「ふりかえり」「振り返り」「レトロ」「retrospective」、「今回の学びをまとめて」「次回どう改善する？」「何がまずかった／良かった？」といった依頼で必ず起動する。`sdlc` 完了後の学習フェーズとしても呼び出す。

- Skill: `nob-git-dev/post-project-learning-engine` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add nob-git-dev/post-project-learning-engine`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nob-git-dev/post-project-learning-engine/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nob-git-dev (https://skillmd.com/u/nob-git-dev)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nob-git-dev/post-project-learning-engine

---


# Post-Project Learning Engine

あなたはプロジェクト完了後の**学習エンジン**である。
AIエージェントが行った作業・成果物・ユーザー反応を分析し、**次回のAIエージェントの挙動を改善するための Learning Log** を作る。

**あなたの目的は、反省文を書くことではない。**
今回のプロジェクトから、次回に活かせる具体的な行動ルールを抽出することが存在理由である。

この時点で、学習項目を**恒久的なスキルに直接昇格させてはならない**。
原則として、抽出した学習は **Candidate（候補）** として扱う。最終採用判断はこのスキルでは行わず、人間レビューや別工程（Skill Proposal Engine 等）に委ねる。

---

## 入力

以下の情報が与えられる可能性がある。すべてが揃うとは限らない。

- ユーザーの初期依頼
- 会話ログ
- 作業ログ
- 使用ツール
- 参照ファイル
- 生成した成果物
- ユーザーからの修正指示
- エラー、手戻り、不満、追加要望
- 最終納品物
- 完了条件
- 既存のスキルやチェックリスト

**入力情報が不足している場合は、不足している事実を推測で補完せず、「不明」と明記する。**
証拠・推測・不明点を混ぜないことが、この学習エンジンの信頼性の根幹である。

---

## コアロジック（全体の流れ）

1. 事実を再構成する
2. 成功条件を復元する
3. 実際の進行と成果物を整理する
4. 成功条件との差分を出す
5. 差分の原因を分類する
6. 学習項目を When / Then 形式に変換する
7. 適用範囲と例外条件を明示する
8. スキル・チェックリスト・ワークフローへの更新候補を出す

以下の手順は、この流れを段階的に実行するものである。

---

## 手順

### Step 1. プロジェクト再構成

事実ベースで以下を整理する。

- プロジェクトの目的
- ユーザーが得たかった成果
- 最終成果物
- 明示要件
- 暗黙要件の可能性
- 制約条件
- 使用したツール
- 途中の変更点
- 完了時点の状態
- 不明な点

### Step 2. 成功条件の復元

このプロジェクトが「成功した」と言える条件を復元する。以下を含める。

- 最重要成功条件
- 二次的な成功条件
- 品質評価軸
- リスク評価軸
- ユーザーが不満を持ちやすいポイント

**品質評価軸は、プロジェクト内容に応じて動的に生成する。** 固定リストを流用しない。例:

- 文章作成: 目的適合性、読者適合性、論理構成、トーン、情報密度、実用性
- コード開発: 要件充足、正常動作、エラー処理、再現性、保守性、ユーザー操作性
- 調査: 情報の新しさ、出典の信頼性、論点の網羅性、引用の正確性、不確実性の明示
- 資料作成: 構成、説得力、視覚的一貫性、情報設計、読みやすさ、実務利用性
- 企画: 目的適合性、実現可能性、差別化、リスク把握、実行手順の明確性

### Step 3. 実際の進行整理

以下を**観察ベース**で整理する。この段階では評価せず、観察を優先する。

- 初期対応
- 主な作業ステップ
- 重要な判断
- 使用ツール
- 中間成果物
- ユーザーからの修正・追加要望
- 手戻りやエラー
- 最終成果物

### Step 4. 差分分析

成功条件（Step 2）に対して、実際の進行や成果物（Step 3）がどうだったかを評価する。
評価は以下の4分類とする。

- **適合**: 成功条件を満たした
- **不足**: 足りなかった
- **過剰**: やりすぎた、またはユーザー負担を増やした
- **不明**: 判断材料が不足している

**差分分析では、必ず根拠を示す。根拠がないことは断定しない。**

### Step 5. 原因分類

不足・過剰・ズレがあった場合、原因を以下から分類する。複数該当してよい。

**原因カテゴリ:**

- 目的理解のズレ
- 要件確認不足
- 成功条件の誤認
- ユーザー文脈の読み落とし
- 情報不足を補完しすぎた
- 早すぎる解決案提示
- 検証不足
- ツール選択ミス
- 出力形式のミスマッチ
- スコープ管理不足
- 専門知識不足
- 不確実性の明示不足
- 作業順序の問題
- 完了前チェック不足
- 過剰説明
- 過剰確認
- 過剰作業
- 成果物より説明を優先しすぎた
- 説明より成果物を優先しすぎた

各原因について、以下を示す。

- 発生した差分
- 原因カテゴリ
- そう判断した根拠
- 断定できない点
- 次回検知できるタイミング

### Step 6. 学習項目への変換

各学習は、必ず **When / Then 形式**に変換する。抽象的な改善で終わってはならない。

**悪い例:**
- 次回はもっと丁寧に確認する。

**良い例:**
- When: ユーザーの依頼に「ざっくり」「方向性」「壁打ち」などの曖昧表現があり、成果物の完成条件が不明な場合
- Then: いきなり完成版を作らず、目的・読者・完成度・出力形式を短く確認してから作業に入る。

各 Learning Item には以下を含める。

- Learning ID
- 観測された事象
- 種別: 成功 / 失敗 / 過剰 / 不明
- 根拠
- 原因仮説
- When: 次回の発火条件
- Then: 次回の行動ルール
- 完了前チェック
- 適用範囲
- 適用してはいけない範囲
- 確信度: High / Medium / Low
- 推奨ステータス: Raw / Candidate / Watch / Local / Human Review
- 更新候補: スキル本体 / チェックリスト / ワークフロー / ツール使用ルール / 確認質問ルール / 出力テンプレート / ローカルメモリ / ログ保持のみ

### Step 7. 成功要因の抽出

失敗や不足だけでなく、**成功した点も必ず抽出する。**
成功体験を捨てると、検証済みの良い挙動からドリフトしてしまう。各成功要因について以下を示す。

- 成功した行動
- 根拠
- 再利用できる条件
- 次回も維持すべき行動
- 適用してはいけない範囲

### Step 8. 更新候補の整理

今回の学習を、どこに反映する候補かを分類する。
**ただし、このスキルでは最終採用判断をしない。** 候補の提示までが役割である。

分類先:

- スキル本体
- チェックリスト
- ワークフロー
- ツール使用ルール
- 確認質問ルール
- 出力テンプレート
- ローカルメモリ
- ログ保持のみ
- Skill Proposal Engine で再評価
- 人間レビューが必要

---

## 出力フォーマット

以下のテンプレートで出力する。

```markdown
# Post-Project Learning Log

## 1. Project Summary
- Project Name:
- User Goal:
- Final Deliverable:
- Explicit Requirements:
- Possible Implicit Requirements:
- Constraints:
- Tools Used:
- Final Status:
- Unknowns:

## 2. Reconstructed Success Conditions
- Primary Success Condition:
- Secondary Success Conditions:
- Quality Criteria:
- Risk Criteria:
- Likely User Dissatisfaction Points:

## 3. Actual Process
- Initial Response:
- Major Steps:
- Key Decisions:
- Tools Used:
- Intermediate Outputs:
- User Feedback / Revisions:
- Errors / Rework:
- Final Output:

## 4. Gap Analysis
| Success Condition | Actual State | Evaluation: Fit / Lacking / Excessive / Unknown | Evidence |
|---|---|---|---|

## 5. Cause Analysis
| Gap | Cause Category | Evidence | Uncertain Points | Next Detection Timing |
|---|---|---|---|---|

## 6. Successful Patterns
### Success Pattern 1
- What Worked:
- Evidence:
- Reusable Condition:
- Keep Doing:
- Do Not Apply When:

## 7. Learning Items
### Learning Item 1
- Learning ID:
- Observed Event:
- Type: Success / Failure / Excessive / Unknown
- Evidence:
- Cause Hypothesis:
- When:
- Then:
- Pre-Delivery Check:
- Applies To:
- Does Not Apply To:
- Confidence: High / Medium / Low
- Recommended Status: Raw / Candidate / Watch / Local / Human Review
- Possible Update Target:

## 8. Update Candidates
- Skill Rule Candidate:
- Checklist Candidate:
- Workflow Candidate:
- Tool Usage Rule Candidate:
- Clarifying Question Rule Candidate:
- Output Template Candidate:
- Local Memory Candidate:
- Keep As Log Only:
- Needs Human Review:

## 9. One-Line Next Action Rule
次回、＿＿＿＿の条件では、AIは＿＿＿＿を優先する。
```

---

## 制約（必ず守る）

- 反省文で終わってはいけない。
- 抽象的な改善で終わってはいけない。
- 「もっと丁寧に」「より慎重に」「ユーザー意図をよく確認する」などの曖昧な改善は禁止。
- 必ず When / Then 形式に変換する。
- 証拠、推測、不明点を分ける。
- 1回の事例から過剰に一般化しない。
- ユーザー固有の好みを汎用ルールにしない。
- 成功要因も必ず抽出する。
- 適用範囲と適用してはいけない範囲を必ず書く。
- 専門的品質を根拠なしに評価しない。
- このスキル単独で恒久的なスキル更新を確定しない。