Progressive Domain Crystallization (PDC) スキル

このスキルができること

このスキルにより、任意のAIアシスタントは、ビジネスアプリケーション向けの生きたドメイン知識ベースを構築して活用できます。これは、人間とAIの協働プロトコルを通じて、セッションをまたいで段階的に蓄積されます。

AIはデフォルトではドメインを「知っていません」。しかしこのスキルを使えば、以下が可能です：

• セッション開始時に構造化された .tasks/domain.md ファイルを読む
• ビジネスが定義した内部用語とエンティティ名を正確に使用する
• 作業中のドメイン理解のギャップをインラインで指摘する
• ドメインファイルへの構造化された追加をヒューマンレビュー用に提案する
• 知識ベースを破損させない — すべての更新は提案形式で、自動適用されない
• 段階的開示を通じたドメイン知識の成長管理 — 現在のセッションに関連したもののみを読み込む

---

コアプロトコル

セッション開始時

1. プロジェクトルートで .tasks/domain.md を探す
2. 見つかった場合 → ファイル構造をチェック：
   • 単一ファイル（約200行以下）：作業を開始する前にファイル全体を読む。
   • インデックス + 詳細ファイル（分割構造）：ルートの .tasks/domain.md インデックス（Tier 1 — コアコンテキスト）を読む。その後、現在のタスクに関連するTier 2詳細ファイルを判定し、それらのみを読み込む。§ 段階的開示 参照。
3. 見つからない場合 → .tasks/domain.md のテンプレートを使って初期化を提案する
4. ユーザーに確認：「[プロジェクト名]のドメインコンテキストを読み込みました。[N]個のエンティティと[N]個のフローに精通しています。」分割モードの場合、次も付け加える：「コアコンテキストを読み込みました。作業内容に応じて、詳細ファイルを適宜読み込みます。」

作業中

• .tasks/domain.md で定義されたエンティティ名、用語、略語を正確に使用する
• 未定義の用語またはエンティティに遭遇した場合、インラインでマーク：[UNKNOWN: <term>]
• エンティティ間の関係が不明な場合、マーク：[RELATIONSHIP UNCLEAR: <entity-a> → <entity-b>]
• 暗示されているビジネスルールが文書化されていない場合：[RULE INFERRED: <description>]
• ドメイン事実を作り上げない — ドキュメント化されているもの、またはユーザーがセッション中に確認したものだけを使用する
• 特定のエンティティまたはフローで作業する場合、存在していて未読み込みのTier 2詳細ファイルを読み込む

セッション終了時

最終応答の下部に必ず ## 📋 提案されたドメイン更新 セクションを生成してください。

フォーマット：

## 📋 提案されたドメイン更新

> これらを確認して、確定した項目を .tasks/domain.md にコピーしてください

### 新たに発見されたエンティティ
- **[EntityName]**: [このセッションから理解した定義]
  - 属性: [リスト]
  - 関連先: [その他のエンティティ]

### 明確化された用語
- `[term]` → [平易な定義]

### 特定された関係
- [Entity A] → [動詞] → [Entity B]：[説明]

### 観察されたビジネスルール
- [ルール説明]

### 未解決の質問
- [ ] [曖昧な点や未解決な点についての質問]

### 追加/更新を提案する .tasks/domain.md セクション
- [ ] [更新する特定のセクションまたはエントリ]

ヒューマンがこれを確認し、必要に応じて編集し、.tasks/domain.md を手動で更新します。これにより、ヒューマンがドメインの権威者として位置付けられます。

---

段階的開示

ドメイン知識ファイルは時間とともに成長します。80行でうまく機能する単一の .tasks/domain.md は、400行になると扱いにくくなります。段階的開示により、AIは完全な知識ベースへのアクセスを失うことなく、現在のセッションに関連するもののみに焦点を当てることができます。

ドメイン知識の3つのTier

Tier	含まれるもの	読み込まれるタイミング	典型的なサイズ
Tier 1 — コア	プロジェクト概要、用語集、エンティティ名（1行説明のみ）、ビジネスルーステーブル、ユーザーロールテーブル	常に、セッション開始時	80～120行
Tier 2 — ワーキングコンテキスト	完全なエンティティ説明（ライフサイクル、注釈、エッジケース）、完全なフロー手順、リレーションシップマップ、統合ポイント	オンデマンド、セッションがそのエンティティまたはフローに触れるとき	ファイルあたり30～80行
Tier 3 — アーカイブ	変更ログ、解決済みの未解決質問、データマイグレーション注釈、ベンダー固有の詳細	明示的なリクエスト時、またはプロジェクト履歴を確認するとき	可変

各Tierに含まれるもの

Tier 1 — コア（ルート .tasks/domain.md、常に読み込まれる）：

• ## Project Overview — それが何か、誰が使うか、ビジネスゴール（5行）
• ## Domain Boundaries — スコープ内のもの、サポートするもの、明示的に除外されるもの。ビルドの過剰化を防止する。
• ## Terminology Glossary — ショートハンドテーブル
• ## Entity Registry — 名前と1行説明のみ（属性リスト全体ではない、ライフサイクル詳細ではない、注釈ではない）。これはエンティティの目次と考えてください。
• ## State Models — ステータスまたはライフサイクルステージを持つエンティティの名前付き列挙型と有効な状態遷移。AIはこれらを唯一の有効な値として扱う必要があります。
• ## Business Rules — ハードルールテーブル（BR-001、BR-002など）。これらはAIが常に知っていなければならない基本事実です。
• ## User Roles — ロールテーブル
• ## Stakeholder Map — 指名された人物、システムへの関係、主な関心事、関与のタイミング。採用と買収にとって重要です。
• ## Open Questions — 現在未解決の項目
• ## Detail Files — Tier 2ファイルのインデックス（1行説明付き、下記のファイルレイアウト参照）

Tier 2 — ワーキングコンテキスト（別個ファイル、タスクで読み込み）：

• 完全なエンティティ仕様 — 属性、ライフサイクル、リレーションシップ、注釈、エッジケース（主要エンティティあたり1ファイル）
• 完全なフロー説明 — ステップバイステップのプロセスウォークスルー（フロー1つあたり1ファイル）
• リレーションシップマップ — 完全なエンティティ間テーブル
• 統合ポイント — 外部システムの詳細

Tier 3 — アーカイブ（別個ファイル、リクエスト時読み込み）：

• 変更ログ — 何が学習され、いつだったかのセッション単位の履歴
• 解決済みの質問 — クローズされた未解決質問の履歴記録
• データマイグレーション注釈 — ベンダーカタログの詳細、インポート手順
• ベンダー固有の詳細 — 価格シート構造、ポータルアクセス注釈

分割のタイミング：~200行ルール

単一の .tasks/domain.md は初期段階のプロジェクトに適しています。分割を促すトリガーはシンプルです：

.tasks/domain.md が約200行を超えた場合、分割を提案してください。

ユーザーに伝えてください：「ドメインファイルが実質的になってきました — [N]行、[N]個のエンティティと[N]個のフロー。インデックスファイルと詳細ファイルに分割したいですか？これにより、セッションは関連のあるものに焦点を当てることができ、何も失われません。」

ユーザーが同意した場合、階層化されたファイルレイアウトに再構成してください（下記参照）。単一ファイルを好む場合は、それを尊重してください — これは必須要件ではなく、好みです。

AIがセッション開始時にTierを使用する方法

1. ルート .tasks/domain.md を読む（Tier 1 — 常に）
      ↓
2. 現在のタスクを理解する
      ↓
3. どのエンティティ/フローが関連か判定
      ↓
4. 関連するTier 2ファイルのみを読み込む
      ↓
5. 作業 — タスクが拡大した場合、追加Tier 2ファイルを読み込む
      ↓
6. 更新を提案 — 各更新がどのファイルに属するか指定

例：ユーザーが「PM更新フローを更新する必要があります」と言った。AIは：

1. ルート .tasks/domain.md を読む（コアコンテキスト — すべてのエンティティ名、すべてのビジネスルールを認識）
2. docs/domain/flows/pm-renewal.md を読み込む（関連するフロー）
3. docs/domain/entities/pm-renewal.md を読み込む（関連するエンティティ）
4. docs/domain/flows/lead-distribution.md や docs/domain/entities/customer.md は読み込まない — このタスクには関連しない。

分割モードでの更新提案

ドメインが複数ファイルに分割されている場合、提案されたドメイン更新セクションは、各更新がどのファイルに属するかを指定する必要があります：

## 📋 提案されたドメイン更新

### 更新: `.tasks/domain.md`（Tier 1 — コア）
- ビジネスルールに追加: BR-013 — [ルール説明]

### 更新: `docs/domain/entities/pm-renewal.md`（Tier 2）
- 属性を追加: `priceAdjustmentPercent` — 更新時に適用される年間価格上昇

### 新規ファイル: `docs/domain/flows/engineering-review.md`（Tier 2）
- [作成する完全なフロー説明]

### 更新: `docs/domain/archive/changelog.md`（Tier 3）
- [セッション概要エントリ]

バージョニング

.tasks/domain.md はそのfrontmatterにバージョンヘッダーを含みます。これはヒューマンが読める形式です — AIとチームにドメイン知識がどの状態にあるかを伝えます。

バージョンフォーマット： MAJOR.MINOR

• MAJOR — 根本的なスコープの変更があるときにインクリメント（新規ビジネスプロセス、主要エンティティの再構成、ドメイン境界の移動）
• MINOR — 承認された更新のたびにインクリメント（新規エンティティ、新規ルール、フロー調整、ステークホルダー追加）

誰がインクリメント： システムは各承認された更新でMINORを自動インクリメント。MAJORはチームがドメインが根本的に拡大したと判断するときに手動でインクリメント。

バージョンヘッダーは .tasks/domain.md frontmatterに存在：

> **Version:** 1.5
> **Last updated:** 2026-04-06 (Session 30)
> **Changes:** +Commission Report entity, +BR-013–015, updated Quote-to-Close flow

承認されたすべての更新でAIは以下を行う必要があります：

1. バージョン番号をインクリメント（MINOR +1）
2. 「Last updated」日付とセッション参照を更新
3. 「Changes」行を簡潔なサマリーで更新
4. 変更ログセクションにエントリを追加

システムがgitを使用している場合、コミットメッセージはChanges行を反映すべき。バージョンヘッダーとgit履歴は異なるオーディエンスに対応 — ヘッダーはAIとビジネスユーザー向け、gitはエンジニアリング向け。

---

.tasks/domain.md ファイル構造

完全なテンプレートについては .tasks/domain.md を参照してください。

単一ファイルモード（約200行以下）

ファイルは以下のトップレベルセクションを使用し、すべて1ファイル内に：

セクション	Tier	目的
## Project Overview	1	アプリが何をするか、誰が使うか、主要ゴール
## Domain Boundaries	1	スコープ内、サポート、除外
## Terminology Glossary	1	内部用語と平易な定義のマッピング
## Entity Registry	1（名前）/ 2（詳細）	属性と説明を含むビジネスオブジェクト
## State Models	1	エンティティの有効なステータス、タイプ、状態遷移
## Relationship Map	2	エンティティ間の接続方法
## Flow Catalog	2	ステップバイステップ情報フロー付きの名前付きビジネスプロセス
## Business Rules	1	制約、検証、エッジケース
## Integration Points	2	外部システム、API、データソース
## User Roles	1	システムを使用する人物とできること
## Stakeholder Map	1	指名された人物、システムへの関係、関心事、関与タイミング
## Open Questions	1	未解決の曖昧さ — 時間とともに確認・解決
## Changelog	3	何が学習されたか、いつだったか

単一ファイルモードでは、すべてのtierが1ファイル内。これで問題ありません — tierラベルは将来の分割を導く注釈に過ぎません。

分割ファイルモード（約200行以上）

your-project/
├── .tasks/domain.md                   ← Tier 1: コアインデックス（常に読み込み）
├── docs/
│   └── domain/
│       ├── entities/                  ← Tier 2: 主要エンティティ1つ1ファイル
│       │   ├── quote.md
│       │   ├── customer.md
│       │   ├── product.md
│       │   └── ...
│       ├── flows/                     ← Tier 2: ビジネスプロセス1つ1ファイル
│       │   ├── quote-to-close.md
│       │   ├── pm-renewal.md
│       │   └── ...
│       ├── relationships.md           ← Tier 2: 完全なリレーションシップマップ
│       ├── integrations.md            ← Tier 2: 外部システム詳細
│       └── archive/                   ← Tier 3: 履歴記録
│           ├── changelog.md
│           └── resolved-questions.md
└── ... (rest of your project)

分割モードのルート .tasks/domain.md は以下を含：

• Tier 1セクション全体（Project Overview、Domain Boundaries、Glossary、エンティティ名テーブル、State Models、Business Rules、User Roles、Stakeholder Map、Open Questions）
• 各Tier 2ファイルを指す ## Detail Files インデックス（1行説明付き）：

## Detail Files

| File | Contents |
|------|----------|
| `docs/domain/entities/quote.md` | Quote entity — ライフサイクル、属性、ステータスワークフロー |
| `docs/domain/entities/customer.md` | Customer/Accountエンティティ — 親子、テリトリー割り当て |
| `docs/domain/flows/quote-to-close.md` | 機会から設置までのQuote完全ライフサイクル |
| `docs/domain/flows/pm-renewal.md` | PM契約更新プロセス |
| `docs/domain/relationships.md` | 完全なエンティティリレーションシップマップ |
| `docs/domain/integrations.md` | Salesforce、Watertight、Procore、ベンダーポータル |
| `docs/domain/archive/changelog.md` | セッション単位の学習履歴 |

---

初期化ワークフロー

.tasks/domain.md が存在しない場合、AIは：

1. ユーザーに5つのシード質問を尋ねる（references/seed-questions.md 参照）
2. その回答を使ってテンプレートを入力
3. ドラフト .tasks/domain.md を作成
4. 保存前にレビュー用に提示

初期ファイルは200行を大きく下回ります。単一ファイルモードで開始。後で成長したら分割します。

---

ドメインを時間とともに成長させる

各セッションは以下のサイクルに従います：

.tasks/domain.md を読む（+ 分割されている場合は関連Tier 2ファイル）
      ↓
作業を行う（未知のものをインラインで指摘）
      ↓
更新を提案（分割されている場合はターゲットファイルを指定）
      ↓
ヒューマンレビュー & 承認
      ↓
ヒューマン .tasks/domain.md を更新（または詳細ファイル）
      ↓
（次のセッションは更新されたファイルを読む）

成長ライフサイクル

セッション1～3:    単一 .tasks/domain.md、~60～80行     （Tier 1のみ）
セッション4～10:   単一 .tasks/domain.md、~100～200行   （Tier 1 + 2混在）
セッション10+:     インデックス + 詳細ファイルに分割   （Tier 1 / 2 / 3分離）
プロジェクト成熟: アーカイブ付きの完全な3階層構造

ファイルが約200行を超えたら、AIは先制的に分割を提案すべき：

「ドメインファイルが[N]行になってきました — [N]個のエンティティと[N]個のフロー詳細をカバーしています。コアインデックスファイルと詳細ファイルに分割したいですか？各セッションは作業内容に関連する部分だけを読み込みます。何も失われません。」

ユーザーが同意した場合：

1. Tier 1コンテンツをスリムなルート .tasks/domain.md に抽出（~80～120行）
2. 各エンティティの完全な説明を docs/domain/entities/[name].md に移動
3. 各フローの完全な説明を docs/domain/flows/[name].md に移動
4. リレーションシップマップと統合ポイントを独立したTier 2ファイルに移動
5. 変更ログを docs/domain/archive/changelog.md に移動
6. ## Detail Files インデックスをルート .tasks/domain.md に追加
7. 保存前にレビュー用に新しい構造を提示

時間とともに、.tasks/domain.md は以下の単一の信頼できるソースになります：

• 新規開発者のオンボーディング
• 将来のAIセッション（任意のモデル、任意のツール）
• ドキュメントとスペック
• テストケースの基盤

---

リファレンスファイル

• .tasks/domain.md — 新しいドメインファイルを初期化するための空白テンプレート
• references/seed-questions.md — 新しいドメインをブートストラップするときに尋ねる質問
• references/entity-template.md — 個別エンティティファイルのテンプレート（大規模プロジェクト）
• references/anti-patterns.md — ドメインコンテキストを構築する際に避けるべき一般的な誤り