mirror of
https://github.com/affaan-m/ECC.git
synced 2026-10-18 05:57:40 +02:00
feat(skills): integrate optional domain context workflow from PR 3411
Preserve full contributor head; refresh catalogs and Pi projection. Verify disposable Claude/Codex installs and resource discovery, with no automatic hooks or governance files.
This commit is contained in:
haelyra
@@ -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.
|
||||
@@ -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
|
||||
@@ -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.
|
||||
@@ -11,7 +11,7 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"source": "./",
|
||||
"description": "Harness-native ECC operator layer - 71 agents, 307 skills, 97 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 - 71 agents, 308 skills, 97 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",
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "ecc",
|
||||
"version": "2.2.3",
|
||||
"description": "Harness-native ECC plugin for engineering teams - 71 agents, 307 skills, 97 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 - 71 agents, 308 skills, 97 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"
|
||||
|
||||
+1
-1
@@ -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 71 specialized agents, 307 skills, and 97 commands.
|
||||
ECC is a cross-harness coding system with 71 specialized agents, 308 skills, and 97 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.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ECC — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 71 specialized agents, 307 skills, 97 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 71 specialized agents, 308 skills, 97 commands, and automated hook workflows for software development.
|
||||
|
||||
**Version:** 2.2.3
|
||||
|
||||
@@ -202,7 +202,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
|
||||
|
||||
```
|
||||
agents/ — 71 specialized subagents
|
||||
skills/ — 307 workflow skills and domain knowledge
|
||||
skills/ — 308 workflow skills and domain knowledge
|
||||
commands/ — 97 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
|
||||
@@ -141,12 +141,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 native Codex and Qoder plugin paths, 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 71 agents, 307 skills, and 97 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 71 agents, 308 skills, and 97 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 | 71 agents | Planning, review, build repair, security, architecture, and domain work |
|
||||
| Skills | 307 skills | TDD, research, security, docs, frontend, data, ML, operations, and more |
|
||||
| Skills | 308 skills | TDD, research, security, docs, frontend, data, ML, operations, and more |
|
||||
| Commands | 97 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 |
|
||||
@@ -859,7 +859,7 @@ Stable graduation of the 2.0 line: control-pane substrate, worktree lifecycle se
|
||||
```text
|
||||
ECC/
|
||||
|-- agents/ # 71 specialized subagents for delegation
|
||||
|-- skills/ # 307 reusable workflows loaded on demand
|
||||
|-- skills/ # 308 reusable workflows loaded on demand
|
||||
|-- commands/ # 97 maintained slash-command shims
|
||||
|-- rules/ # opt-in common and language standards
|
||||
|-- hooks/ # runtime automation and enforcement
|
||||
|
||||
+1
-1
@@ -200,7 +200,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**完成！** 你现在可以使用 71 个代理、307 个技能和 97 个命令。
|
||||
**完成！** 你现在可以使用 71 个代理、308 个技能和 97 个命令。
|
||||
|
||||
### multi-* 命令需要额外配置
|
||||
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
# Soul
|
||||
|
||||
## Core Identity
|
||||
ECC is a production-ready AI coding plugin with 71 specialized agents, 307 skills, 97 commands, and automated hook workflows for software development.
|
||||
ECC is a production-ready AI coding plugin with 71 specialized agents, 308 skills, 97 commands, and automated hook workflows for software development.
|
||||
|
||||
## Core Principles
|
||||
1. **Agent-First** — route work to the right specialist as early as possible.
|
||||
|
||||
@@ -41,6 +41,7 @@ skills:
|
||||
- compose-multiplatform-patterns
|
||||
- configure-ecc
|
||||
- contract-first
|
||||
- context-and-decisions
|
||||
- content-engine
|
||||
- content-hash-cache-pattern
|
||||
- context-budget
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# ECC — 智能体指令
|
||||
|
||||
这是一个**生产就绪的 AI 编码插件**，提供 71 个专业代理、307 项技能、97 条命令以及自动化钩子工作流，用于软件开发。
|
||||
这是一个**生产就绪的 AI 编码插件**，提供 71 个专业代理、308 项技能、97 条命令以及自动化钩子工作流，用于软件开发。
|
||||
|
||||
**版本:** 2.2.3
|
||||
|
||||
@@ -147,7 +147,7 @@
|
||||
|
||||
```
|
||||
agents/ — 71 个专业子代理
|
||||
skills/ — 307 个工作流技能和领域知识
|
||||
skills/ — 308 个工作流技能和领域知识
|
||||
commands/ — 97 个斜杠命令
|
||||
hooks/ — 基于触发的自动化
|
||||
rules/ — 始终遵循的指导方针（通用 + 每种语言）
|
||||
|
||||
@@ -264,7 +264,7 @@ Copy-Item -Recurse rules/typescript "$HOME/.claude/rules/"
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**搞定！** 你现在可以使用 71 个智能体、307 项技能和 97 个命令了。
|
||||
**搞定！** 你现在可以使用 71 个智能体、308 项技能和 97 个命令了。
|
||||
|
||||
***
|
||||
|
||||
@@ -1178,7 +1178,7 @@ opencode
|
||||
|---------|---------------|----------|--------|
|
||||
| 智能体 | PASS: 71 个 | PASS: 12 个 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 97 个 | PASS: 35 个 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 307 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 308 项 | 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 编码工具的插件**。以
|
||||
|---------|-----------------------|------------|-----------|----------|
|
||||
| **智能体** | 71 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
|
||||
| **命令** | 97 | 共享 | 基于指令 | 35 |
|
||||
| **技能** | 307 | 共享 | 10 (原生格式) | 37 |
|
||||
| **技能** | 308 | 共享 | 10 (原生格式) | 37 |
|
||||
| **钩子事件** | 8 种类型 | 15 种类型 | SessionStart（1 种类型） | 11 种类型 |
|
||||
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | 1 个 SessionStart 引导脚本 | 插件钩子 |
|
||||
| **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"coverage": {
|
||||
"skills": 307,
|
||||
"skills": 308,
|
||||
"withTriggers": 33
|
||||
},
|
||||
"generatedAt": "2026-09-24T23:51:22.784Z",
|
||||
@@ -10,7 +10,7 @@
|
||||
"id": "hand-seeded",
|
||||
"source": "manual-curation-pending-regeneration"
|
||||
},
|
||||
"registryDigest": "89c0fbf05b8a7e811dbf788cf9a141199e13c961b69812c80b4cbdb019500c07",
|
||||
"registryDigest": "a04c37d5c89ef75787ecefd203c54b06385d9f614d04e3f5e5616ab253e24c96",
|
||||
"schemaVersion": 1,
|
||||
"triggers": {
|
||||
"skill:agent-runtime-gateway-smoke-test": [
|
||||
|
||||
@@ -382,6 +382,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",
|
||||
|
||||
@@ -349,6 +349,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",
|
||||
|
||||
@@ -101,6 +101,7 @@
|
||||
"machine-learning",
|
||||
"supply-chain-domain",
|
||||
"document-processing",
|
||||
"documentation-context",
|
||||
"hermes-hooks"
|
||||
]
|
||||
}
|
||||
|
||||
@@ -60,6 +60,7 @@
|
||||
"compose-multiplatform-patterns",
|
||||
"content-hash-cache-pattern",
|
||||
"contract-first",
|
||||
"context-and-decisions",
|
||||
"conventional-commit-review",
|
||||
"cost-aware-llm-pipeline",
|
||||
"council",
|
||||
@@ -342,7 +343,8 @@
|
||||
"token-card": "Requires a downloaded tokenchit CLI and reads provider session logs.",
|
||||
"agent-runtime-gateway-smoke-test": "requires authenticated network gateways and remote sandbox callbacks at runtime",
|
||||
"brownfield-retrospective": "depends on the ECC specialist agent roster and spec-miner dispatch workflow; not a compact portable Pi prompt",
|
||||
"deepseek-harness-setup": "configures an external DeepSeek provider and Claude-Code-specific credentials and hook integration"
|
||||
"deepseek-harness-setup": "configures an external DeepSeek provider and Claude-Code-specific credentials and hook integration",
|
||||
"story-lifecycle": "Requires ECC agent workflow handoffs and a local Node ledger; native Pi delivery has not been validated."
|
||||
}
|
||||
},
|
||||
"commands": {
|
||||
|
||||
@@ -205,6 +205,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/",
|
||||
|
||||
+2
-1
@@ -1,6 +1,6 @@
|
||||
# Curation
|
||||
|
||||
pi/core includes 128 of 306 skills and 24 of 97 commands from the root of ECC.
|
||||
pi/core includes 129 of 308 skills and 24 of 97 commands from the root of ECC.
|
||||
Everything excluded is listed here with its reason.
|
||||
|
||||
## Rules
|
||||
@@ -197,6 +197,7 @@ Exclude anything that:
|
||||
| `agent-runtime-gateway-smoke-test` | requires authenticated network gateways and remote sandbox callbacks at runtime |
|
||||
| `brownfield-retrospective` | depends on the ECC specialist agent roster and spec-miner dispatch workflow; not a compact portable Pi prompt |
|
||||
| `deepseek-harness-setup` | configures an external DeepSeek provider and Claude-Code-specific credentials and hook integration |
|
||||
| `story-lifecycle` | Requires ECC agent workflow handoffs and a local Node ledger; native Pi delivery has not been validated. |
|
||||
|
||||
## Excluded commands
|
||||
|
||||
|
||||
+1
-1
@@ -1,6 +1,6 @@
|
||||
# ecc-pi-core
|
||||
|
||||
A curated, Pi-native profile of ECC: 128 portable
|
||||
A curated, Pi-native profile of ECC: 129 portable
|
||||
engineering skills and 24 pure prompt-workflow commands, with no extensions,
|
||||
no hooks, no runtime downloads, and no network or SaaS dependencies.
|
||||
|
||||
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
Reference in New Issue
Block a user