# Knowledge Capture

> 公開されうる skill や reference に流用される文書を、匿名化ゲート付きで構造化して残す。Use when: ふりかえり、ADR、インシデント記録、学習メモなどを再利用可能な知識資産として整理したいとき。

- Skill: `ryomurakami1983/knowledge-capture` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ryomurakami1983/knowledge-capture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ryomurakami1983/knowledge-capture/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: RyoMurakami1983 (https://skillmd.com/u/ryomurakami1983)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/ryomurakami1983/knowledge-capture

---

# Knowledge Capture（知識の捕捉）

セッション、インシデント、意思決定から得た知識を構造化文書に変換するための横断的ユーティリティ。匿名化ゲートにより、固有データが公開スキルやリファレンスに漏洩するのを防ぐ。

## こんなときに使う
次のような場面で使います。
- ふりかえり・インシデントレポート等、後にスキルの実例になりうる文書を作成する時
- 実プロジェクトの経験を再利用可能なスキルパターンに変換する時
- 固有システムを参照するADR・学習ノート・ポストモーテムを書く時
- 既存スキルの実例に固有データが残っていないかレビューする時
- 文書ワークフローに匿名化品質ゲートが必要な時

## Related Skills

- **`furikaeri-practice`** — ふりかえりワークフロー（本スキルの匿名化ゲートを参照）
- **`skill`** — スキル作成・改善ワークフロー（本スキルの匿名化チェックリストを参照）
- **`github-issue-intake`** — 改善項目をIssueとして捕捉

---

## Dependencies

- なし（会話ベースのワークフロー）
- オプション: GitHub CLI (`gh`) — 改善issueの作成用

## Core Principles

1. **知識は外へ流れる** — すべての文書はプロジェクト外で読まれる前提で書く。内部限定の前提は漏洩リスクを生む（ニュートラルな視点）。**なぜ？** — 内部ふりかえりがスキルの実例になり、内部ADRが公開リファレンスになる。「誰も見ない」という前提は一時的なものに過ぎない
2. **入口で匿名化** — 文書作成時に固有データを置換する。後からの修正は漏れやすくコストが高い（基礎と型）。**なぜ？** — SLOP-001 事件で実証済み。ふりかえり文書の固有データがそのままスキルに流入した。入口で防げば出口での事故はゼロになる
3. **構造化 > 散文** — 構造化文書（テーブル、チェックリスト、コードブロック）は匿名化と再利用が容易（成長の複利）。**なぜ？** — 散文に埋もれた固有名詞は見落としやすい。テーブルの1セルなら一目で判別できる
4. **教育的価値を守る** — 匿名化で教訓が消えてはならない。同じ概念を示すダミーデータを選ぶ（温故知新）。**なぜ？** — 「ハイフンを含む値がSplitで壊れる」を教えるなら、ダミーデータもハイフンを含まなければ意味がない

---

## ワークフロー: 捕捉とゲート

### Step 1 — 知識タイプの特定

文書タイプとその下流の行き先を決定する：

| タイプ | 主要スキル | 保存先 | 匿名化 |
|--------|----------|--------|--------|
| ふりかえり | `furikaeri-practice` | `docs/furikaeri/` | 要（スキル化候補） |
| アーキテクチャ決定 | ADRワークフロー | `docs/adr/` | 要（公開リポジトリ） |
| インシデントレポート | インシデントワークフロー | `docs/incidents/` | 要 |
| 学習ノート | 単独 | プロジェクトdocs | 状況依存 |
| GitHub Issue | `github-issue-intake` | 公開リポジトリのIssue | 要 |

**判断基準**: 「この文書の内容が公開リポジトリに届く可能性があるか？」 → Yes = 匿名化必須。

> **Values**: ニュートラルな視点（前提を明確にし、判断基準を形式知化）

### Step 2 — 構造化して記述

事実と固有詳細を分離する構造化フォーマットを使用する：

```markdown
## ✅ 構造化（匿名化しやすい）

| 入力 | 期待値 | 実際 |
|------|--------|------|
| `20240101-MFG001-AL-6XN-H12345` | ProductType=`AL-6XN` | ProductType=`AL` |

## ❌ 散文（匿名化しにくい）

OrderProcessorの出力で注文ORD-394072を処理した際、
製品型番X-200-Bが誤ってパースされた。なぜなら...
```

> **Values**: 基礎と型（構造が品質を生む）

### Step 3 — 匿名化ゲートの適用

文書を出力する前に、**匿名化チェックリスト**（下記参照）を通す。これが重要な品質ゲート。

スキルの実例として使用する場合：
1. 匿名化チェックリストの全項目を適用
2. 匿名化後も意図した教訓が伝わるか検証
3. 第二の読者（人間またはAI）に残存する固有データがないかチェックを依頼

> **Values**: 基礎と型（ゲートを通さなければ出力しない）

### Step 4 — 出力のルーティング

文書を適切な保存先に届け、次のアクションに繋げる：

| 保存先 | アクション |
|--------|----------|
| `docs/furikaeri/` | コミット、PR、改善issueにリンク |
| スキルの実例 | 作成または改善のため `skill` に連携 |
| ADR | `docs/adr/` にコミット、ADRインデックスを更新 |
| GitHub Issue | 書く前に AC-1〜AC-4 を適用；`github-issue-intake` で作成 |

> **Values**: 継続は力（知識を正しい場所に届け、次のアクションに繋げる）

---

## 匿名化チェックリスト

このセクションは他スキルから直接参照されるよう設計されている。公開リポジトリに掲載される可能性のあるすべてのコンテンツに各チェックを適用する。

### AC-1: プロジェクト名・会社名

**チェック**: 実プロジェクト名、会社名、製品名が含まれていないか？

**アクション**: 削除するか、汎用名に置換する。

```
❌ "InvoiceParser PR#15"
✅ （プロジェクト参照を削除、または "Example:" のみ）
```

### AC-2: データフォーマット・識別子

**チェック**: 実データ値、IDフォーマット、レコード構造が含まれていないか？

**アクション**: 同じ構造特性を持つダミー値に置換する。

```
❌ "2024_03_15-WO7890-TYP-A-B-SN45678"
✅ "20240101-MFG001-AL-6XN-H12345"
    （保持: 日付接頭辞、ハイフン区切り、値内のハイフン）
```

**核心原則**: ダミーデータは同じエッジケースを示す必要がある。

### AC-3: ドメイン固有用語

**チェック**: 特定の業界・顧客・内部システムを示す用語が使われていないか？

**アクション**: 業界中立の用語に一般化する。

```
❌ "基板型番"、"ロット管理番号"
✅ "製品型番"、"ロット番号"
```

### AC-4: 数値・閾値

**チェック**: 実測値、閾値、ビジネス固有の数値が含まれていないか？

**アクション**: 代表的なダミー値に置換する。

### 判断基準

> 「このコンテンツから元のプロジェクト、顧客、固有システムを特定できるか？」
> → **Yes** = AC-1〜AC-4 を適用 / **No** = 公開可

---

## Good Practices

### 1. 書きながら匿名化する

**What**: 別のレビューパスではなく、書く過程で匿名化を適用する。

**Why**: 後付けは漏れやすい。文書完成後、どの詳細が固有かを書き手は忘れがち。

**Values**: 基礎と型（入口で品質を確保する）

### 2. ダミーデータのパレットを持つ

**What**: よく使うパターン（日付、ID、製品コード）のダミー値セットを維持する。

**Why**: スキル間で一貫したダミーデータは可読性を高め、認知負荷を減らす。

**Values**: 継続は力（再利用可能な素材を積み上げる）

---

## Common Pitfalls

### 1. 教訓を匿名化で消す

**Problem**: データを過剰に置換し、例が意図した概念を示さなくなる。

**Fix**: 教えたい構造特性を保持するダミーデータを選ぶ。「ハイフンを含む値がSplitで壊れる」を教えるなら、ダミー値もハイフンを含むこと。

### 2. 部分的な匿名化

**Problem**: プロジェクト名は置換したが、データフォーマット・クラス名・ドメイン用語は残っている。

**Fix**: AC-1〜AC-4を体系的に通す。固有データは組み合わせで漏洩する。

### 3. 内部文書をスキップ

**Problem**: 「公開されない」前提で内部文書の匿名化を省略する。

**Fix**: 判断基準を適用：「このコンテンツが公開リポジトリに届く可能性は？」文書は内部記録からスキルへ頻繁に流れる。

---

## Anti-Patterns

### 「誰も見ない」

**What**: 内部リポジトリの文書だから匿名化不要と判断する。

**Why It's Wrong**: 知識は外へ流れる。内部ふりかえりがスキルの実例になる。プライバシーの前提は一時的。

**Better Approach**: 入口で匿名化する。コストは最小限、漏洩リスクは永続的。

### 本番データのコピペ

**What**: 実エラーメッセージ、ログ出力、データサンプルをそのまま文書にコピーする。

**Why It's Wrong**: 本番データには顧客情報、内部システム名、固有フォーマットが含まれる。

**Better Approach**: 同じエラーパターンを再現する合成例をダミーデータで作成する。

---

## Quick Reference

### 匿名化チェックリスト（サマリー）

| # | チェック | アクション |
|---|---------|----------|
| AC-1 | プロジェクト/会社名 | 削除または汎用名 |
| AC-2 | データフォーマット/ID | 構造等価なダミーに置換 |
| AC-3 | ドメイン用語 | 業界中立の用語に一般化 |
| AC-4 | 数値 | 代表的なダミー値 |

### 判断フロー

```
文書作成
    │
    ├─ 公開リポジトリに届く可能性は？
    │     │
    │     ├─ Yes → AC-1〜AC-4 を適用
    │     │         │
    │     │         └─ 匿名化後も教訓が伝わるか？
    │     │               │
    │     │               ├─ Yes → ✅ 出力
    │     │               └─ No  → ダミーデータを見直す
    │     │
    │     └─ No  → ✅ 出力（ただし将来の流れを考慮）
    │
    └─ スキルに組み込む？
          │
          ├─ Yes → 必須: 全チェックリスト適用
          └─ No  → 上記の判断基準を適用
```

---

## Resources

- [PHILOSOPHY.md](../../PHILOSOPHY.md) — 開発憲法とValues
- [furikaeri-practice](../furikaeri-practice/SKILL.md) — ふりかえりワークフロー
- [skill](../skill/SKILL.md) — スキル作成ワークフロー

---