feat(skills): add context and decisions

.agents/skills/context-and-decisions/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: context-and-decisions
+description: >-
+  Govern stable domain context with a narrowly scoped CONTEXT.md when needed, and route hard-to-reverse decisions to ECC's existing architecture-decision-records skill. Use when domain terms require repeated explanation, one term has multiple meanings, unclear language causes module-boundary mistakes, or domain semantics must remain separate from architecture decisions.
+---
+
+# 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.
+
+## ADR Handoff: Reuse the Existing Capability
+
+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:
+
+1. Read and execute `architecture-decision-records`, preserving the repository's existing ADR location and format.
+2. If no convention exists, let that skill choose the minimum viable location; do not create a separate system here.
+3. Link to the ADR from `CONTEXT.md`, the project map, or the relevant Spec/Issue instead of copying the decision body.
+4. 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.
+
+## 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`.
+
+## 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.
+
+## How It Works
+
+1. Reuse the mapped context or glossary artifact when one exists; create `CONTEXT.md` only when no equivalent source of truth is available.
+2. Record precise domain definitions, relationships, confirmed interpretations, and explicitly unconfirmed ambiguities without mixing in implementation or task state.
+3. Route durable tradeoffs to `architecture-decision-records` and link the resulting ADR instead of copying its rationale into context documents.
+4. Keep schedules, blockers, and execution status in the existing 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.
+
+## 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.
+
+## Related Skills
+
+- `architecture-decision-records`: the sole ADR methodology for hard-to-reverse decisions.
+- `living-docs-governance`: lifecycle maintenance for the project map, status, and history.
+- `docs-governance`: cross-capability routing and closeout order.
+
+## 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.

.agents/skills/context-and-decisions/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Context and Decisions"
+  short_description: "Govern stable domain language and durable decisions"
+  brand_color: "#8B5CF6"
+  default_prompt: "Use $context-and-decisions to maintain stable domain context and capture hard-to-reverse decisions."
+policy:
+  allow_implicit_invocation: true

.agents/skills/context-and-decisions/templates/context.example.md

@@ -0,0 +1,21 @@
+# CONTEXT.md — Domain Language
+
+> Create only when needed. Do not include implementation, status, scheduling, or decisions.
+
+## Core Terms
+
+| Term | Precise definition | Evidence/source |
+|---|---|---|
+| `{term}` | `{what it means and how it differs from adjacent terms}` | `{business rule, contract, or code location}` |
+
+## Concept Relationships
+
+- `{Concept A}` and `{Concept B}`: `{one-to-many / state transition / containment / constraint}`.
+
+## Resolved Ambiguities
+
+- `{old expression}` now consistently means `{adopted interpretation}`; stop using `{deprecated expression}`.
+
+## Needs Confirmation
+
+- `{term or relationship}`: awaiting confirmation from `{owner/domain role}`; do not change the implementation based on it until confirmed.

.claude-plugin/marketplace.json

@@ -11,7 +11,7 @@
     {
       "name": "ecc",
       "source": "./",
-      "description": "Harness-native ECC operator layer - 68 agents, 293 skills, 94 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses",
+      "description": "Harness-native ECC operator layer - 68 agents, 294 skills, 94 legacy command shims, reusable hooks, rules, selective install profiles, and production-ready workflows for Claude Code, Codex, OpenCode, Cursor, and related agent harnesses",
       "version": "2.2.3",
       "author": {
         "name": "Affaan Mustafa",

.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "ecc",
   "version": "2.2.3",
-  "description": "Harness-native ECC plugin for engineering teams - 68 agents, 293 skills, 94 legacy command shims, reusable hooks, rules, MCP conventions, and operator workflows for Claude Code plus adjacent agent harnesses",
+  "description": "Harness-native ECC plugin for engineering teams - 68 agents, 294 skills, 94 legacy command shims, reusable hooks, rules, MCP conventions, and operator workflows for Claude Code plus adjacent agent harnesses",
   "author": {
     "name": "Affaan Mustafa",
     "url": "https://x.com/affaanmustafa"

.gemini/GEMINI.md

@@ -4,7 +4,7 @@ This file provides Gemini CLI with the baseline ECC workflow, review standards,
 
 ## Overview
 
-ECC is a cross-harness coding system with 68 specialized agents, 293 skills, and 94 commands.
+ECC is a cross-harness coding system with 68 specialized agents, 294 skills, and 94 commands.
 
 Gemini support is currently focused on a strong project-local instruction layer via `.gemini/GEMINI.md`, plus the shared MCP catalog and package-manager setup assets shipped by the installer.
 

AGENTS.md

@@ -1,6 +1,6 @@
 # ECC — Agent Instructions
 
-This is a **production-ready AI coding plugin** providing 68 specialized agents, 293 skills, 94 commands, and automated hook workflows for software development.
+This is a **production-ready AI coding plugin** providing 68 specialized agents, 294 skills, 94 commands, and automated hook workflows for software development.
 
 **Version:** 2.2.3
 
@@ -201,7 +201,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
 
 ```
 agents/          — 68 specialized subagents
-skills/          — 293 workflow skills and domain knowledge
+skills/          — 294 workflow skills and domain knowledge
 commands/        — 94 slash commands
 hooks/           — Trigger-based automations
 rules/           — Always-follow guidelines (common + per-language)

README.md

@@ -139,12 +139,12 @@ Instead of rebuilding that process in every prompt, you install it once and make
 
 ECC is MIT-licensed open source. It works best with Claude Code today, has a supported Codex sync path, and provides capability-limited adapters for Cursor, OpenCode, Gemini, Zed, GitHub Copilot, Antigravity, Qwen, and other harnesses. See the [support status matrix](#platform-support) before assuming feature parity.
 
-Access to 68 agents, 293 skills, and 94 legacy command shims, plus hooks, rules, memory, continuous learning, and AgentShield security scanning. The agents are specialized for planning, review, build repair, security, architecture, and domain work.
+Access to 68 agents, 294 skills, and 94 legacy command shims, plus hooks, rules, memory, continuous learning, and AgentShield security scanning. The agents are specialized for planning, review, build repair, security, architecture, and domain work.
 
 | Included         |       Count | What it gives you                                                                    |
 | ---------------- | ----------: | ------------------------------------------------------------------------------------ |
 | Agents           |   68 agents | Planning, review, build repair, security, architecture, and domain work              |
-| Skills           |  293 skills | TDD, research, security, docs, frontend, data, ML, operations, and more              |
+| Skills           |  294 skills | TDD, research, security, docs, frontend, data, ML, operations, and more              |
 | Commands         | 94 commands | Convenient entry points while ECC moves to a skills-first surface                    |
 | Hooks and memory |     Runtime | Enforcement, session summaries, continuous learning, instincts, and context controls |
 | Rules            |   Selective | Always-loaded standards you choose by language or project                            |

README.zh-CN.md

@@ -200,7 +200,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
 /plugin list ecc@ecc
 ```
 
-**完成！** 你现在可以使用 68 个代理、293 个技能和 94 个命令。
+**完成！** 你现在可以使用 68 个代理、294 个技能和 94 个命令。
 
 ### multi-* 命令需要额外配置
 

SOUL.md

@@ -1,7 +1,7 @@
 # Soul
 
 ## Core Identity
-ECC is a production-ready AI coding plugin with 68 specialized agents, 293 skills, 94 commands, and automated hook workflows for software development.
+ECC is a production-ready AI coding plugin with 68 specialized agents, 294 skills, 94 commands, and automated hook workflows for software development.
 
 ## Core Principles
 1. **Agent-First** — route work to the right specialist as early as possible.

agent.yaml

@@ -38,6 +38,7 @@ skills:
   - compose-multiplatform-patterns
   - configure-ecc
   - contract-first
+  - context-and-decisions
   - content-engine
   - content-hash-cache-pattern
   - context-budget

docs/zh-CN/AGENTS.md

@@ -1,6 +1,6 @@
 # ECC — 智能体指令
 
-这是一个**生产就绪的 AI 编码插件**，提供 68 个专业代理、293 项技能、94 条命令以及自动化钩子工作流，用于软件开发。
+这是一个**生产就绪的 AI 编码插件**，提供 68 个专业代理、294 项技能、94 条命令以及自动化钩子工作流，用于软件开发。
 
 **版本:** 2.2.3
 
@@ -147,7 +147,7 @@
 
 ```
 agents/          — 68 个专业子代理
-skills/          — 293 个工作流技能和领域知识
+skills/          — 294 个工作流技能和领域知识
 commands/        — 94 个斜杠命令
 hooks/           — 基于触发的自动化
 rules/           — 始终遵循的指导方针（通用 + 每种语言）

docs/zh-CN/README.md

@@ -264,7 +264,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
 /plugin list ecc@ecc
 ```
 
-**搞定！** 你现在可以使用 68 个智能体、293 项技能和 94 个命令了。
+**搞定！** 你现在可以使用 68 个智能体、294 项技能和 94 个命令了。
 
 ***
 
@@ -1178,7 +1178,7 @@ opencode
 |---------|---------------|----------|--------|
 | 智能体 | PASS: 68 个    | PASS: 12 个 | **Claude Code 领先** |
 | 命令 | PASS: 94 个    | PASS: 35 个 | **Claude Code 领先** |
-| 技能 | PASS: 293 项   | PASS: 37 项 | **Claude Code 领先** |
+| 技能 | PASS: 294 项   | PASS: 37 项 | **Claude Code 领先** |
 | 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多！** |
 | 规则 | PASS: 29 条    | PASS: 13 条指令 | **Claude Code 领先** |
 | MCP 服务器 | PASS: 14 个    | PASS: 完整 | **完全对等** |
@@ -1286,7 +1286,7 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
 |---------|-----------------------|------------|-----------|----------|
 | **智能体** | 68                    | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
 | **命令** | 94                    | 共享 | 基于指令 | 35 |
-| **技能** | 293                   | 共享 | 10 (原生格式) | 37 |
+| **技能** | 294                   | 共享 | 10 (原生格式) | 37 |
 | **钩子事件** | 8 种类型                 | 15 种类型 | SessionStart（1 种类型） | 11 种类型 |
 | **钩子脚本** | 20+ 个脚本               | 16 个脚本 (DRY 适配器) | 1 个 SessionStart 引导脚本 | 插件钩子 |
 | **规则** | 34 (通用 + 语言)          | 34 (YAML 前页) | 基于指令 | 13 条指令 |

manifests/install-components.json

@@ -374,6 +374,14 @@
         "supply-chain-domain"
       ]
     },
+    {
+      "id": "capability:documentation-context",
+      "family": "capability",
+      "description": "Optional durable domain-context and ADR handoff workflow.",
+      "modules": [
+        "documentation-context"
+      ]
+    },
     {
       "id": "capability:documents",
       "family": "capability",

manifests/install-modules.json

@@ -310,6 +310,36 @@
       "cost": "light",
       "stability": "stable"
     },
+    {
+      "id": "documentation-context",
+      "kind": "skills",
+      "description": "Optional durable domain-context and ADR handoff workflow.",
+      "paths": [
+        "skills/context-and-decisions"
+      ],
+      "targets": [
+        "claude",
+        "claude-project",
+        "cursor",
+        "antigravity",
+        "codex",
+        "opencode",
+        "codebuddy",
+        "joycode",
+        "qwen",
+        "zed",
+        "hermes",
+        "openclaw",
+        "kimi",
+        "adal"
+      ],
+      "dependencies": [
+        "workflow-quality"
+      ],
+      "defaultInstall": false,
+      "cost": "light",
+      "stability": "beta"
+    },
     {
       "id": "workflow-quality",
       "kind": "skills",

manifests/install-profiles.json

@@ -99,7 +99,8 @@
         "devops-infra",
         "machine-learning",
         "supply-chain-domain",
-        "document-processing"
+        "document-processing",
+        "documentation-context"
       ]
     }
   }

manifests/pi-core.json

@@ -58,6 +58,7 @@
       "compose-multiplatform-patterns",
       "content-hash-cache-pattern",
       "contract-first",
+      "context-and-decisions",
       "cost-aware-llm-pipeline",
       "council",
       "cpp-coding-standards",

package.json

@@ -191,6 +191,7 @@
     "skills/compose-multiplatform-patterns/",
     "skills/configure-ecc/",
     "skills/contract-first/",
+    "skills/context-and-decisions/",
     "skills/connections-optimizer/",
     "skills/content-engine/",
     "skills/content-hash-cache-pattern/",

pi/core/CURATION.md

@@ -1,6 +1,6 @@
 # Curation
 
-pi/core includes 123 of 293 skills and 24 of 94 commands from the root of ECC.
+pi/core includes 124 of 294 skills and 24 of 94 commands from the root of ECC.
 Everything excluded is listed here with its reason.
 
 ## Rules

pi/core/README.md

@@ -1,6 +1,6 @@
 # ecc-pi-core
 
-A curated, Pi-native profile of ECC: 123 portable
+A curated, Pi-native profile of ECC: 124 portable
 engineering skills and 24 pure prompt-workflow commands, with no extensions,
 no hooks, no runtime downloads, and no network or SaaS dependencies.
 

pi/core/skills/context-and-decisions/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: context-and-decisions
+description: >-
+  Govern stable domain context with a narrowly scoped CONTEXT.md when needed, and route hard-to-reverse decisions to ECC's existing architecture-decision-records skill. Use when domain terms require repeated explanation, one term has multiple meanings, unclear language causes module-boundary mistakes, or domain semantics must remain separate from architecture decisions.
+---
+
+# 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.
+
+## ADR Handoff: Reuse the Existing Capability
+
+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:
+
+1. Read and execute `architecture-decision-records`, preserving the repository's existing ADR location and format.
+2. If no convention exists, let that skill choose the minimum viable location; do not create a separate system here.
+3. Link to the ADR from `CONTEXT.md`, the project map, or the relevant Spec/Issue instead of copying the decision body.
+4. 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.
+
+## 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`.
+
+## 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.
+
+## How It Works
+
+1. Reuse the mapped context or glossary artifact when one exists; create `CONTEXT.md` only when no equivalent source of truth is available.
+2. Record precise domain definitions, relationships, confirmed interpretations, and explicitly unconfirmed ambiguities without mixing in implementation or task state.
+3. Route durable tradeoffs to `architecture-decision-records` and link the resulting ADR instead of copying its rationale into context documents.
+4. Keep schedules, blockers, and execution status in the existing 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.
+
+## 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.
+
+## Related Skills
+
+- `architecture-decision-records`: the sole ADR methodology for hard-to-reverse decisions.
+- `living-docs-governance`: lifecycle maintenance for the project map, status, and history.
+- `docs-governance`: cross-capability routing and closeout order.
+
+## 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.

pi/core/skills/context-and-decisions/templates/context.example.md

@@ -0,0 +1,21 @@
+# CONTEXT.md — Domain Language
+
+> Create only when needed. Do not include implementation, status, scheduling, or decisions.
+
+## Core Terms
+
+| Term | Precise definition | Evidence/source |
+|---|---|---|
+| `{term}` | `{what it means and how it differs from adjacent terms}` | `{business rule, contract, or code location}` |
+
+## Concept Relationships
+
+- `{Concept A}` and `{Concept B}`: `{one-to-many / state transition / containment / constraint}`.
+
+## Resolved Ambiguities
+
+- `{old expression}` now consistently means `{adopted interpretation}`; stop using `{deprecated expression}`.
+
+## Needs Confirmation
+
+- `{term or relationship}`: awaiting confirmation from `{owner/domain role}`; do not change the implementation based on it until confirmed.

skills/context-and-decisions/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: context-and-decisions
+description: >-
+  Govern stable domain context with a narrowly scoped CONTEXT.md when needed, and route hard-to-reverse decisions to ECC's existing architecture-decision-records skill. Use when domain terms require repeated explanation, one term has multiple meanings, unclear language causes module-boundary mistakes, or domain semantics must remain separate from architecture decisions.
+---
+
+# 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.
+
+## ADR Handoff: Reuse the Existing Capability
+
+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:
+
+1. Read and execute `architecture-decision-records`, preserving the repository's existing ADR location and format.
+2. If no convention exists, let that skill choose the minimum viable location; do not create a separate system here.
+3. Link to the ADR from `CONTEXT.md`, the project map, or the relevant Spec/Issue instead of copying the decision body.
+4. 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.
+
+## 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`.
+
+## 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.
+
+## How It Works
+
+1. Reuse the mapped context or glossary artifact when one exists; create `CONTEXT.md` only when no equivalent source of truth is available.
+2. Record precise domain definitions, relationships, confirmed interpretations, and explicitly unconfirmed ambiguities without mixing in implementation or task state.
+3. Route durable tradeoffs to `architecture-decision-records` and link the resulting ADR instead of copying its rationale into context documents.
+4. Keep schedules, blockers, and execution status in the existing 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.
+
+## 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.
+
+## Related Skills
+
+- `architecture-decision-records`: the sole ADR methodology for hard-to-reverse decisions.
+- `living-docs-governance`: lifecycle maintenance for the project map, status, and history.
+- `docs-governance`: cross-capability routing and closeout order.
+
+## 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.

skills/context-and-decisions/templates/context.example.md

@@ -0,0 +1,21 @@
+# CONTEXT.md — Domain Language
+
+> Create only when needed. Do not include implementation, status, scheduling, or decisions.
+
+## Core Terms
+
+| Term | Precise definition | Evidence/source |
+|---|---|---|
+| `{term}` | `{what it means and how it differs from adjacent terms}` | `{business rule, contract, or code location}` |
+
+## Concept Relationships
+
+- `{Concept A}` and `{Concept B}`: `{one-to-many / state transition / containment / constraint}`.
+
+## Resolved Ambiguities
+
+- `{old expression}` now consistently means `{adopted interpretation}`; stop using `{deprecated expression}`.
+
+## Needs Confirmation
+
+- `{term or relationship}`: awaiting confirmation from `{owner/domain role}`; do not change the implementation based on it until confirmed.