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.