domain-context

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Progressive Domain Crystallization (PDC) Skill

渐进式领域固化（PDC）Skill

What This Skill Does

此Skill的功能

This skill enables any AI assistant to build and use a living domain knowledge base for any business application — accumulated incrementally across sessions through a human-AI collaborative protocol.

The AI never "knows" the domain by default. But with this skill, it can:

Read a structured
```
DOMAIN.md
```
file at the start of every session
Use internal terminology and entity names exactly as the business defines them
Flag gaps in domain understanding inline during work
Propose structured additions to the domain file for human review
Never corrupt the knowledge base — all updates are proposed, not auto-applied
Manage domain knowledge growth through progressive disclosure — loading only what's relevant to the current session

此Skill可让任意AI助手为任意业务应用构建并使用动态领域知识库——通过人机协作协议在多个会话中逐步积累知识。

AI默认并不“了解”业务领域。但借助此Skill，它能够：

在每个会话开始时读取结构化的
```
DOMAIN.md
```
文件
完全按照业务定义使用内部术语和实体名称
在工作过程中实时标记领域理解的缺口
向用户提出结构化的领域文件更新建议，供人工审核
绝不会损坏知识库——所有更新均为建议，不会自动应用
通过渐进式披露管理领域知识的增长——仅加载与当前会话相关的内容

Core Protocol

核心协议

At Session Start

会话开始时

Look for DOMAIN.md in the project root (or
```
docs/domain/DOMAIN.md
```
)
If found → check the file structure:
- Single file (under ~200 lines): Read it completely before doing any work.
- Index + detail files (split structure): Read the root DOMAIN.md index (Tier 1 — core context). Then determine which Tier 2 detail files are relevant to the current task and load only those. See § Progressive Disclosure.
If not found → offer to initialize one using the template at
```
assets/templates/DOMAIN.md
```
Confirm to the user: "I've loaded the domain context for [Project Name]. I'm familiar with [N] entities and [N] flows." If in split mode, also note: "I've loaded the core context. I'll pull in detail files as needed for what we're working on."

在项目根目录（或
```
docs/domain/DOMAIN.md
```
）中查找DOMAIN.md
如果找到 → 检查文件结构：
- 单个文件（约200行以内）：在开展任何工作前完整读取该文件。
- 索引+详情文件（拆分结构）：读取根目录下的DOMAIN.md索引（Tier 1——核心上下文）。然后确定哪些Tier 2详情文件与当前任务相关，仅加载这些文件。参见§ 渐进式披露。
如果未找到 → 提议使用
```
assets/templates/DOMAIN.md
```
中的模板初始化一个
向用户确认：“我已加载[项目名称]的领域上下文。我熟悉[N]个实体和[N]个流程。”如果是拆分模式，还需说明：“我已加载核心上下文。我会根据我们正在处理的内容按需调取详情文件。”

During Work

工作过程中

Use entity names, terminology, and abbreviations exactly as defined in DOMAIN.md
When encountering an undefined term or entity, mark it inline:
```
[UNKNOWN: <term>]
```
When a relationship between entities is unclear, mark it:
```
[RELATIONSHIP UNCLEAR: <entity-a> → <entity-b>]
```
When a business rule seems to be implied but isn't documented:
```
[RULE INFERRED: <description>]
```
Do not invent domain facts — use only what is documented or what the user confirms in session
When working on a specific entity or flow, load its Tier 2 detail file if one exists and hasn't been loaded yet

完全按照DOMAIN.md中的定义使用实体名称、术语和缩写
遇到未定义的术语或实体时，实时标记：
```
[UNKNOWN: <term>]
```

当实体间的关系不明确时，标记：

[RELATIONSHIP UNCLEAR: <entity-a> → <entity-b>]

当业务规则看似存在但未被记录时，标记：
```
[RULE INFERRED: <description>]
```
不得编造领域事实——仅使用已记录的内容或用户在会话中确认的信息
当处理特定实体或流程时，如果对应的Tier 2详情文件存在且尚未加载，则加载该文件

At Session End

会话结束时

Always generate a

## 📋 Proposed Domain Updates

section at the bottom of your final response.

Format it as:

markdown

undefined

务必在最终回复的底部生成一个

## 📋 提议的领域更新

章节。

格式如下：

markdown

undefined

📋 Proposed Domain Updates

📋 提议的领域更新

Review these and copy any confirmed items into your DOMAIN.md

请审核这些内容，并将确认的条目复制到你的DOMAIN.md中

New Entities Discovered

发现的新实体

[EntityName]: [Definition as understood from this session]
- Attributes: [list]
- Related to: [other entities]

[EntityName]: [从本次会话中理解的定义]
- 属性: [列表]
- 关联实体: [其他实体]

Terminology Clarified

明确的术语

```
[term]
```
→ [plain definition]

```
[term]
```
→ [通俗定义]

Relationships Identified

识别的关系

[Entity A] → [verb] → [Entity B]: [description]

[Entity A] → [动词] → [Entity B]: [描述]

Business Rules Observed

观察到的业务规则

[Rule description]

[规则描述]

Open Questions

待解决问题

[Question about something ambiguous or unresolved]

[关于模糊或未解决事项的问题]

Suggested DOMAIN.md Sections to Add/Update

建议添加/更新的DOMAIN.md章节

[specific section or entry to update]


The human reviews this, edits as needed, and manually updates DOMAIN.md. This keeps the human as domain authority.

---

[具体要更新的章节或条目]


人工审核后，按需编辑并手动更新DOMAIN.md。这样可确保人工始终是领域的权威。

---

Progressive Disclosure

渐进式披露

Domain knowledge files grow over time. A single DOMAIN.md that works well at 80 lines becomes unwieldy at 400. Progressive disclosure keeps the AI focused on what's relevant to the current session without losing access to the full knowledge base.

领域知识文件会随时间增长。一个80行的DOMAIN.md使用起来很顺畅，但到400行时就会变得难以处理。渐进式披露可让AI专注于当前会话相关的内容，同时不会失去对完整知识库的访问权限。

Three Tiers of Domain Knowledge

领域知识的三个层级

Tier	What It Contains	When It's Loaded	Typical Size
Tier 1 — Core	Project overview, terminology glossary, entity names (one-liners only), business rules table, user roles table	Always, at session start	80–120 lines
Tier 2 — Working Context	Full entity descriptions (lifecycle, notes, edge cases), full flow step-by-steps, relationship map, integration points	On demand, when the session touches that entity or flow	30–80 lines per file
Tier 3 — Archive	Changelog, resolved open questions, data migration notes, vendor-specific details	On explicit request, or when reviewing project history	Variable

Tier	包含内容	加载时机	典型规模
Tier 1 — 核心层	项目概述、术语表、实体名称（仅一行描述）、业务规则表、用户角色表	始终在会话开始时加载	80–120行
Tier 2 — 工作上下文层	完整的实体描述（生命周期、备注、边缘情况）、完整的流程步骤说明、关系图、集成点	按需加载，当会话涉及该实体或流程时	每个文件30–80行
Tier 3 — 归档层	变更日志、已解决的待解决问题、数据迁移说明、供应商特定细节	明确请求时加载，或在回顾项目历史时	规模可变

What Goes in Each Tier

各层级的内容划分

Tier 1 — Core (root DOMAIN.md, always loaded):

```
## Project Overview
```
— what it is, who uses it, business goal (5 lines)
```
## Domain Boundaries
```
— what's in scope, what's supporting, what's explicitly excluded. Prevents overbuilding.
```
## Terminology Glossary
```
— the shorthand table
```
## Entity Registry
```
— names and one-liner descriptions only (not full attribute lists, not lifecycle details, not notes). Think of this as a table of contents for the entities.
```
## State Models
```
— named enumerations and valid state transitions for entities with statuses or lifecycle stages. The AI must treat these as the only valid values.
```
## Business Rules
```
— the hard rules table (BR-001, BR-002, etc.). These are ground truth the AI must always know.
```
## User Roles
```
— the roles table
```
## Stakeholder Map
```
— named people, their relationship to the system, their key concerns, and when to involve them. Critical for adoption and buy-in.
```
## Open Questions
```
— current unresolved items
```
## Detail Files
```
— index of Tier 2 files with one-line summaries (see file layout below)

Tier 2 — Working Context (separate files, loaded by task):

Full entity specs — attributes, lifecycle, relationships, notes, edge cases (one file per major entity)
Full flow descriptions — step-by-step process walkthroughs (one file per flow)
Relationship map — the full entity-to-entity table
Integration points — external system details

Tier 3 — Archive (separate files, loaded on request):

Changelog — session-by-session history of what was learned
Resolved questions — historical record of closed open questions
Data migration notes — vendor catalog details, import procedures
Vendor-specific details — price sheet structures, portal access notes

Tier 1 — 核心层（根目录DOMAIN.md，始终加载）：

```
## 项目概述
```
——应用用途、用户群体、业务目标（5行）
```
## 领域边界
```
——包含范围、支持范围、明确排除的内容。防止过度构建。
```
## 术语表
```
——简写对照表
```
## 实体注册表
```
——仅包含名称和一行描述（不包含完整属性列表、生命周期细节、备注）。可将其视为实体的目录。
```
## 状态模型
```
——带有状态或生命周期阶段的实体的命名枚举和有效状态转换。AI必须将这些视为唯一有效值。
```
## 业务规则
```
——硬规则表（BR-001、BR-002等）。这些是AI必须始终遵循的基本事实。
```
## 用户角色
```
——角色表
```
## 利益相关者图谱
```
——命名人员、他们与系统的关系、核心关注点以及介入时机。对于系统的采用和认可至关重要。
```
## 待解决问题
```
——当前未解决的事项
```
## 详情文件
```
——Tier 2文件的索引，附带一行摘要（见下文的文件布局）

Tier 2 — 工作上下文层（单独文件，按任务加载）：

完整的实体规范——属性、生命周期、关系、备注、边缘情况（每个主要实体对应一个文件）
完整的流程描述——分步流程说明（每个流程对应一个文件）
关系图——完整的实体间关系表
集成点——外部系统详情

Tier 3 — 归档层（单独文件，按需请求加载）：

变更日志——逐会话的知识积累历史
已解决问题——已关闭的待解决问题的历史记录
数据迁移说明——供应商目录详情、导入流程
供应商特定细节——价目表结构、门户访问说明

When to Split: The ~200 Line Rule

拆分时机：约200行规则

A single DOMAIN.md works well for early-stage projects. The trigger to split is simple:

When DOMAIN.md exceeds ~200 lines, propose the split.

Say to the user: "The domain file is getting substantial — [N] lines with [N] entities and [N] flows. Want me to split it into an index file with detail files? This keeps sessions focused on what's relevant without losing anything."

If the user agrees, restructure into the tiered file layout (see below). If they prefer a single file, respect that — it's a preference, not a hard requirement.

单个DOMAIN.md在早期项目中效果良好。拆分的触发条件很简单：

当DOMAIN.md超过约200行时，提议进行拆分。

向用户说明：“领域文件已变得相当庞大——共[N]行，包含[N]个实体和[N]个流程。需要我将其拆分为一个索引文件和多个详情文件吗？这样可让会话专注于相关内容，同时不会丢失任何信息。”

如果用户同意，则重构为分层文件布局（见下文）。如果用户偏好单个文件，则尊重其选择——这是个人偏好，而非硬性要求。

How the AI Uses Tiers at Session Start

AI在会话开始时如何使用分层结构

1. Read root DOMAIN.md (Tier 1 — always)
      ↓
2. Understand the current task
      ↓
3. Determine which entities/flows are relevant
      ↓
4. Load only those Tier 2 files
      ↓
5. Work — loading additional Tier 2 files if the task expands
      ↓
6. Propose updates — specifying which file each update belongs to

Example: User says "I need to update the PM renewal flow." The AI:

Reads root DOMAIN.md (core context — knows all entity names, all business rules)
Loads
```
docs/domain/flows/pm-renewal.md
```
(the relevant flow)
Loads
```
docs/domain/entities/pm-renewal.md
```
(the relevant entity)

Does NOT load

docs/domain/flows/lead-distribution.md

docs/domain/entities/customer.md

— not relevant to this task.

1. 读取根目录DOMAIN.md（Tier 1——始终加载）
      ↓
2. 理解当前任务
      ↓
3. 确定相关的实体/流程
      ↓
4. 仅加载这些Tier 2文件
      ↓
5. 开展工作——如果任务扩展，加载额外的Tier 2文件
      ↓
6. 提出更新建议——指定每个更新所属的文件

示例：用户说“我需要更新PM续费流程。”AI会：

读取根目录DOMAIN.md（核心上下文——了解所有实体名称、所有业务规则）
加载
```
docs/domain/flows/pm-renewal.md
```
（相关流程）
加载
```
docs/domain/entities/pm-renewal.md
```
（相关实体）

不会加载

docs/domain/flows/lead-distribution.md

或

docs/domain/entities/customer.md

——与当前任务无关。

Proposing Updates in Split Mode

拆分模式下的更新建议

When the domain is split across files, the Proposed Domain Updates section should specify which file each update belongs to:

markdown

undefined

当领域知识拆分到多个文件中时，提议的领域更新章节应明确指定每个更新所属的文件：

markdown

undefined

📋 Proposed Domain Updates

📋 提议的领域更新

Update:

DOMAIN.md

(Tier 1 — core)

更新：

DOMAIN.md

（Tier 1——核心层）

Add to Business Rules: BR-013 — [rule description]

向业务规则添加：BR-013 — [规则描述]

Update:

docs/domain/entities/pm-renewal.md

(Tier 2)

更新：

docs/domain/entities/pm-renewal.md

（Tier 2）

Add attribute:
```
priceAdjustmentPercent
```
— annual price increase applied on renewal

添加属性：
```
priceAdjustmentPercent
```
— 续费应用的年度价格涨幅

New File:

docs/domain/flows/engineering-review.md

(Tier 2)

新文件：

docs/domain/flows/engineering-review.md

（Tier 2）

[Full flow description to create]

[要创建的完整流程描述]

Update:

docs/domain/archive/changelog.md

(Tier 3)

更新：

docs/domain/archive/changelog.md

（Tier 3）

[Session summary entry]

undefined

[会话摘要条目]

undefined

Versioning

版本控制

DOMAIN.md includes a version header in its frontmatter. This is the human-readable version — it tells the AI and the team what state the domain knowledge is in.

Version format:

MAJOR.MINOR

MAJOR increments when the fundamental scope changes (new business process, major entity restructure, domain boundary shift)
MINOR increments on every approved update (new entities, new rules, flow adjustments, stakeholder additions)

Who increments: The system auto-increments MINOR on each approved update. MAJOR is incremented manually when the team decides the domain has fundamentally expanded.

The version header lives in the DOMAIN.md frontmatter:

markdown

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

On every approved update, the AI must:

Increment the version number (MINOR +1)
Update the "Last updated" date and session reference
Update the "Changes" line with a brief summary
Append an entry to the Changelog section

If the system uses git, the commit message should mirror the Changes line. The version header and git history serve different audiences — the header is for the AI and the business user, git is for engineering.

DOMAIN.md的前置内容中包含版本头。这是人类可读的版本——用于告知AI和团队领域知识的状态。

版本格式：

MAJOR.MINOR

MAJOR：当基本范围变更时递增（新业务流程、主要实体重构、领域边界转移）
MINOR：每次批准更新时递增（新实体、新规则、流程调整、利益相关者新增）

谁来递增： 系统在每次批准更新时自动递增MINOR版本。当团队认为领域已基本扩展时，手动递增MAJOR版本。

版本头位于DOMAIN.md的前置内容中：

markdown

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

每次批准更新时，AI必须：

递增版本号（MINOR +1）
更新“Last updated”日期和会话引用
更新“Changes”行，添加简要摘要
向变更日志章节追加条目

如果系统使用git，提交消息应与Changes行内容一致。版本头和git历史服务于不同受众——版本头面向AI和业务用户，git面向工程师。

DOMAIN.md File Structure

DOMAIN.md文件结构

See

assets/templates/DOMAIN.md

for the full template.

完整模板请参见

assets/templates/DOMAIN.md

。

Single-File Mode (under ~200 lines)

单文件模式（约200行以内）

The file uses these top-level sections, all in one file:

Section	Tier	Purpose
`## Project Overview`	1	What the app does, who uses it, primary goals
`## Domain Boundaries`	1	What's in scope, what's supporting, what's excluded
`## Terminology Glossary`	1	Internal jargon mapped to plain definitions
`## Entity Registry`	1 (names) / 2 (details)	Business objects with attributes and descriptions
`## State Models`	1	Valid statuses, types, and state transitions for entities
`## Relationship Map`	2	How entities connect to each other
`## Flow Catalog`	2	Named business processes with step-by-step info flow
`## Business Rules`	1	Constraints, validations, edge cases
`## Integration Points`	2	External systems, APIs, data sources
`## User Roles`	1	Who uses the system and what they can do
`## Stakeholder Map`	1	Named people, their relationship to the system, concerns, involvement timing
`## Open Questions`	1	Unresolved ambiguities — reviewed and cleared over time
`## Changelog`	3	What was learned and when

In single-file mode, all tiers are in one file. This is fine — the tier labels are just annotations that guide the future split.

该文件包含以下顶级章节，全部在一个文件中：

章节	层级	用途
`## 项目概述`	1	应用功能、用户群体、主要目标
`## 领域边界`	1	包含范围、支持范围、排除内容
`## 术语表`	1	内部术语与通俗定义的映射
`## 实体注册表`	1（名称）/ 2（详情）	带有属性和描述的业务对象
`## 状态模型`	1	实体的有效状态、类型和状态转换
`## 关系图`	2	实体间的关联方式
`## 流程目录`	2	命名业务流程及分步信息流
`## 业务规则`	1	约束、验证规则、边缘情况
`## 集成点`	2	外部系统、API、数据源
`## 用户角色`	1	系统用户及其权限
`## 利益相关者图谱`	1	命名人员、与系统的关系、关注点、介入时机
`## 待解决问题`	1	未解决的模糊点——随时间审核并清除
`## 变更日志`	3	知识积累的时间线

在单文件模式下，所有层级都在一个文件中。这是可行的——层级标签只是指导未来拆分的注释。

Split-File Mode (over ~200 lines)

多文件拆分模式（约200行以上）

your-project/
├── DOMAIN.md                          ← Tier 1: Core index (always loaded)
├── docs/
│   └── domain/
│       ├── entities/                  ← Tier 2: One file per major entity
│       │   ├── quote.md
│       │   ├── customer.md
│       │   ├── product.md
│       │   └── ...
│       ├── flows/                     ← Tier 2: One file per business process
│       │   ├── quote-to-close.md
│       │   ├── pm-renewal.md
│       │   └── ...
│       ├── relationships.md           ← Tier 2: Full relationship map
│       ├── integrations.md            ← Tier 2: External system details
│       └── archive/                   ← Tier 3: Historical records
│           ├── changelog.md
│           └── resolved-questions.md
└── ... (rest of your project)

The root DOMAIN.md in split mode contains:

Tier 1 sections in full (Project Overview, Domain Boundaries, Glossary, Entity names table, State Models, Business Rules, User Roles, Stakeholder Map, Open Questions)
A
```
## Detail Files
```
index pointing to each Tier 2 file with a one-line summary:

markdown

undefined

your-project/
├── DOMAIN.md                          ← Tier 1: 核心索引（始终加载）
├── docs/
│   └── domain/
│       ├── entities/                  ← Tier 2: 每个主要实体对应一个文件
│       │   ├── quote.md
│       │   ├── customer.md
│       │   ├── product.md
│       │   └── ...
│       ├── flows/                     ← Tier 2: 每个业务流程对应一个文件
│       │   ├── quote-to-close.md
│       │   ├── pm-renewal.md
│       │   └── ...
│       ├── relationships.md           ← Tier 2: 完整关系图
│       ├── integrations.md            ← Tier 2: 外部系统详情
│       └── archive/                   ← Tier 3: 历史记录
│           ├── changelog.md
│           └── resolved-questions.md
└── ... (项目其他内容)

拆分模式下的根目录DOMAIN.md包含：

完整的Tier 1章节（项目概述、领域边界、术语表、实体名称表、状态模型、业务规则、用户角色、利益相关者图谱、待解决问题）
一个
```
## 详情文件
```
索引，指向每个Tier 2文件并附带一行摘要：

markdown

undefined

Detail Files

详情文件

File	Contents
`docs/domain/entities/quote.md`	Quote entity — lifecycle, attributes, status workflow
`docs/domain/entities/customer.md`	Customer/Account entity — parent-child, territory assignment
`docs/domain/flows/quote-to-close.md`	Full quote lifecycle from opportunity to installation
`docs/domain/flows/pm-renewal.md`	PM contract renewal process
`docs/domain/relationships.md`	Complete entity relationship map
`docs/domain/integrations.md`	Salesforce, Watertight, Procore, vendor portals
`docs/domain/archive/changelog.md`	Session-by-session learning history

---

文件	内容
`docs/domain/entities/quote.md`	Quote实体——生命周期、属性、状态工作流
`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`	逐会话的知识积累历史

---

Initialization Workflow

初始化流程

If no DOMAIN.md exists, the AI should:

Ask the user 5 seed questions (see
```
references/seed-questions.md
```
)
Use the answers to populate the template
Write a draft DOMAIN.md
Present it for review before saving

The initial file will be well under 200 lines. Start in single-file mode. Split later when it grows.

如果不存在DOMAIN.md，AI应：

向用户提出5个初始问题（参见
```
references/seed-questions.md
```
）
使用答案填充模板
编写DOMAIN.md草稿
在保存前提交给用户审核

初始文件会远少于200行。从单文件模式开始，后续增长后再拆分。

Growing the Domain Over Time

领域知识的持续增长

Each session follows this cycle:

READ DOMAIN.md (+ relevant Tier 2 files if split)
      ↓
DO WORK (flag unknowns inline)
      ↓
PROPOSE UPDATES (specify target file if split)
      ↓
HUMAN REVIEWS & APPROVES
      ↓
HUMAN UPDATES DOMAIN.md (or detail files)
      ↓
(next session reads updated files)

每个会话遵循以下循环：

读取DOMAIN.md（如果是拆分模式，还读取相关Tier 2文件）
      ↓
开展工作（实时标记未知内容）
      ↓
提出更新建议（如果是拆分模式，指定目标文件）
      ↓
人工审核并批准
      ↓
人工更新DOMAIN.md（或详情文件）
      ↓
(下一次会话读取更新后的文件)

Growth Lifecycle

增长生命周期

Sessions 1–3:     Single DOMAIN.md, ~60–80 lines      (Tier 1 only)
Sessions 4–10:    Single DOMAIN.md, ~100–200 lines     (Tier 1 + 2 mixed)
Sessions 10+:     Split into index + detail files       (Tier 1 / 2 / 3 separated)
Mature project:   Full three-tier structure with archive

When the file crosses ~200 lines, the AI should proactively offer to split:

"The domain file is at [N] lines now — it covers [N] entities and [N] flows in detail. Want me to split it into a core index file with separate detail files? Each session would load just the parts relevant to what we're working on, and nothing is lost."

If the user agrees:

Extract Tier 1 content into a slim root DOMAIN.md (~80–120 lines)
Move each entity's full description into
```
docs/domain/entities/[name].md
```
Move each flow's full description into
```
docs/domain/flows/[name].md
```
Move relationship map and integration points into their own Tier 2 files
Move changelog into
```
docs/domain/archive/changelog.md
```
Add the
```
## Detail Files
```
index to the root DOMAIN.md
Present the new structure for review before saving

Over time, the DOMAIN.md becomes the single source of truth for:

New developers onboarding
Future AI sessions (any model, any tool)
Documentation and specs
Test case grounding

会话1–3:     单个DOMAIN.md，约60–80行      (仅Tier 1)
会话4–10:    单个DOMAIN.md，约100–200行     (Tier 1 + 2混合)
会话10+:     拆分为索引+详情文件       (Tier 1 / 2 / 3分离)
成熟项目:   包含归档层的完整三层结构

当文件超过约200行时，AI应主动提议拆分：

“领域文件现在有[N]行——详细涵盖了[N]个实体和[N]个流程。需要我将其拆分为核心索引文件和多个详情文件吗？每次会话只会加载与当前工作相关的部分，不会丢失任何信息。”

如果用户同意：

将Tier 1内容提取到精简的根目录DOMAIN.md中（约80–120行）
将每个实体的完整描述移至
```
docs/domain/entities/[name].md
```
将每个流程的完整描述移至
```
docs/domain/flows/[name].md
```
将关系图和集成点移至各自的Tier 2文件
将变更日志移至
```
docs/domain/archive/changelog.md
```
向根目录DOMAIN.md添加
```
## 详情文件
```
索引
在保存前提交新结构供用户审核

随着时间推移，DOMAIN.md会成为以下内容的唯一可信来源：

新开发人员入职培训
未来AI会话（任意模型、任意工具）
文档和规范
测试用例依据

Reference Files

参考文件

```
assets/templates/DOMAIN.md
```
— Blank template to initialize a new domain file
```
references/seed-questions.md
```
— Questions to ask when bootstrapping a new domain
```
references/entity-template.md
```
— Template for individual entity files (large projects)
```
references/anti-patterns.md
```
— Common mistakes to avoid when building domain context

```
assets/templates/DOMAIN.md
```
— 用于初始化新领域文件的空白模板
```
references/seed-questions.md
```
— 引导新领域构建的初始问题
```
references/entity-template.md
```
— 单个实体文件的模板（大型项目）
```
references/anti-patterns.md
```
— 构建领域上下文时需避免的常见错误

domain-context

Original

Translation

Progressive Domain Crystallization (PDC) Skill

渐进式领域固化（PDC）Skill

What This Skill Does

此Skill的功能

Core Protocol

核心协议

At Session Start

会话开始时

During Work

工作过程中

At Session End

会话结束时

📋 Proposed Domain Updates

📋 提议的领域更新

New Entities Discovered

发现的新实体

Terminology Clarified

明确的术语

Relationships Identified

识别的关系

Business Rules Observed

观察到的业务规则

Open Questions

待解决问题

Suggested DOMAIN.md Sections to Add/Update

建议添加/更新的DOMAIN.md章节

Progressive Disclosure

渐进式披露

Three Tiers of Domain Knowledge

领域知识的三个层级

What Goes in Each Tier

各层级的内容划分

When to Split: The ~200 Line Rule

拆分时机：约200行规则

How the AI Uses Tiers at Session Start

AI在会话开始时如何使用分层结构

Proposing Updates in Split Mode

拆分模式下的更新建议

📋 Proposed Domain Updates

📋 提议的领域更新

Update: DOMAIN.md (Tier 1 — core)

更新：DOMAIN.md（Tier 1——核心层）

Update: docs/domain/entities/pm-renewal.md (Tier 2)

更新：docs/domain/entities/pm-renewal.md（Tier 2）

New File: docs/domain/flows/engineering-review.md (Tier 2)

新文件：docs/domain/flows/engineering-review.md（Tier 2）

Update: docs/domain/archive/changelog.md (Tier 3)

更新：docs/domain/archive/changelog.md（Tier 3）

Versioning

版本控制

DOMAIN.md File Structure

DOMAIN.md文件结构

Single-File Mode (under ~200 lines)

单文件模式（约200行以内）

Split-File Mode (over ~200 lines)

多文件拆分模式（约200行以上）

Detail Files

详情文件

Initialization Workflow

初始化流程

Growing the Domain Over Time

领域知识的持续增长

Growth Lifecycle

增长生命周期

Reference Files

参考文件

Update:
`DOMAIN.md`
(Tier 1 — core)

更新：
`DOMAIN.md`
（Tier 1——核心层）

Update:
`docs/domain/entities/pm-renewal.md`
(Tier 2)

更新：
`docs/domain/entities/pm-renewal.md`
（Tier 2）

New File:
`docs/domain/flows/engineering-review.md`
(Tier 2)

新文件：
`docs/domain/flows/engineering-review.md`
（Tier 2）

Update:
`docs/domain/archive/changelog.md`
(Tier 3)

更新：
`docs/domain/archive/changelog.md`
（Tier 3）