context-and-decisions

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Domain Context and Decision Handoff

领域上下文与决策移交

Govern “what these business terms mean” separately from “why this option was chosen.” Do not create an empty shell when no stable content exists.

将“这些业务术语的含义”与“为何选择此方案”分开管理。没有稳定内容时，不要创建空壳文件。

Domain Context Artifact: Domain Language Only

领域上下文产物：仅包含领域语言

When terms require repeated explanation, one term has multiple meanings, or unclear language causes module-boundary errors, first reuse the repository's existing glossary/domain-model document or the

context

role in

.governance/docs-map.json

. Only when no equivalent exists should you lazily create the default

CONTEXT.md

from

templates/context.example.md

Record only:

domain terms and precise definitions;
relationships among core concepts;
confirmed ambiguities and the chosen interpretation;
ambiguities still awaiting confirmation from a domain owner.

Do not include implementation details, current state, task schedules, full requirements, decision rationale, or history. Keep those in code/MAP, STATUS/Issue Tracker, Spec, ADR, and LOG respectively. Terms must be traceable to code, contracts, or business evidence. Mark unconfirmed items as

needs confirmation

; do not guess.

当术语需要反复解释、某个术语有多重含义，或不清晰的措辞导致模块边界错误时，应首先复用仓库现有的术语表/领域模型文档，或

.governance/docs-map.json

中的

context

角色。只有在不存在等价文档时，才从

templates/context.example.md

按需创建默认的

CONTEXT.md

。

仅记录：

领域术语及其精确定义；
核心概念之间的关系；
已确认的歧义及所选解释；
仍待领域负责人确认的歧义。

不要包含实现细节、当前状态、任务排期、完整需求、决策理由或历史记录。分别将它们保留在 code/MAP、STATUS/Issue Tracker、Spec、ADR 和 LOG 中。所有术语都必须能够追溯到代码、契约或业务证据。将未确认的条目标记为

needs confirmation

；不要猜测。

ADR Handoff: Reuse the Existing Capability

ADR 移交：复用现有能力

This skill does not define a second ADR directory, numbering scheme, lifecycle, or template. When a decision is hard to reverse, would confuse a future reader without context, and involves a real tradeoff:

Read and execute
```
architecture-decision-records
```
, preserving the repository's existing ADR location and format.
If no convention exists, let that skill choose the minimum viable location; do not create a separate system here.
Link to the ADR from
```
CONTEXT.md
```
, the project map, or the relevant Spec/Issue instead of copying the decision body.
When a decision is accepted, superseded, or deprecated, append an event to project history according to the living-document rules.

Routine implementation details, easily reversible changes, and short-lived experiments do not need ADRs.

此 skill 不会定义第二套 ADR 目录、编号方案、生命周期或模板。当某项决策难以逆转、缺少上下文会令未来读者感到困惑，并且涉及真实的权衡时：

阅读并执行
```
architecture-decision-records
```
，保留仓库现有的 ADR 位置和格式。
如果不存在相关约定，则让该 skill 选择最小可行的存放位置；不要在此创建另一套独立系统。
从
```
CONTEXT.md
```
、项目映射或相关的 Spec/Issue 链接至 ADR，而不是复制决策正文。
当决策被接受、取代或废弃时，按照 living-document 规则向项目历史追加事件。

日常实现细节、易于撤销的变更和短期实验不需要 ADR。

When to Activate

何时启用

Domain terms are repeatedly re-explained or ambiguous language causes implementation drift.
The project needs a stable domain-language entry point but has no equivalent document.
Context work uncovers a durable decision that should be handed to
```
architecture-decision-records
```
.

领域术语需要反复重新解释，或含糊的措辞导致实现方向偏移。
项目需要一个稳定的领域语言入口，但没有等价的现有文档。
上下文工作发现了一项应移交给
```
architecture-decision-records
```
的长期有效决策。

When to Use

何时使用

Use this skill when stable domain language needs one evidence-backed home, or when context work reveals a hard-to-reverse decision that belongs in the repository's existing ADR system.

当稳定的领域语言需要一个有证据支撑的统一归属位置时，或当上下文工作暴露出应纳入仓库现有 ADR 系统的难以逆转决策时，使用此 skill。

How It Works

工作原理

Reuse the mapped context or glossary artifact when one exists; create
```
CONTEXT.md
```
only when no equivalent source of truth is available.
Record precise domain definitions, relationships, confirmed interpretations, and explicitly unconfirmed ambiguities without mixing in implementation or task state.
Route durable tradeoffs to
```
architecture-decision-records
```
and link the resulting ADR instead of copying its rationale into context documents.
Keep schedules, blockers, and execution status in the existing issue tracker.

如果已有映射的上下文或术语表产物，则直接复用；只有在不存在等效事实来源时才创建
```
CONTEXT.md
```
。
记录精确的领域定义、关系、已确认的解释和明确标出的未确认歧义，不混入实现或任务状态。
将长期有效的权衡决策移交给
```
architecture-decision-records
```
，并链接生成的 ADR，而不是将决策理由复制到上下文文档中。
将排期、阻塞项和执行状态保留在现有的 Issue Tracker 中。

Examples

示例

Define an overloaded business term once and link it to the code or contract that proves its meaning.
Mark a domain interpretation as
```
needs confirmation
```
until a domain owner resolves it.
Hand off a durable storage or boundary decision to the existing ADR workflow and link it from the context artifact.

对一个含义过载的业务术语仅定义一次，并链接到能够证明其含义的代码或契约。
将领域解释标记为
```
needs confirmation
```
，直至领域负责人完成确认。
将长期有效的存储或边界决策移交给现有 ADR 工作流，并从上下文产物链接至该 ADR。

Anti-Patterns

反模式

Copying current tasks, schedules, full requirements, or implementation details into
```
CONTEXT.md
```
.
Creating empty context files or a second ADR system for completeness.
Treating unconfirmed domain interpretations as facts, or copying ADR bodies into maps and logs.

将当前任务、排期、完整需求或实现细节复制到
```
CONTEXT.md
```
中。
为了形式完整而创建空的上下文文件或第二套 ADR 系统。
将未确认的领域解释视为事实，或将 ADR 正文复制到映射和日志中。

Related Skills

Scheduling and Task Boundary

排期与任务边界

Keep tasks, status, blockers, and schedules in the project's existing tracker, such as GitHub Issues or Linear, as the single source of truth. Use local

.scratch/

only when no external tracker exists and the project explicitly adopts it. Do not put schedules in

CONTEXT.md

, ADRs, PROJECT_STATUS, or the history index database.

将任务、状态、阻塞项和排期保留在项目现有的任务跟踪器中，例如 GitHub Issues 或 Linear，并将其作为唯一事实来源。只有在不存在外部任务跟踪器且项目明确采用本地

.scratch/

时，才使用该目录。不要将排期放入

CONTEXT.md

、ADR、PROJECT_STATUS 或历史索引数据库中。