prizmkit 1.0.0 → 1.0.1

package/bundled/skills/dev-pipeline-launcher/SKILL.md

@@ -0,0 +1,223 @@
+---
+name: "dev-pipeline-launcher"
+description: "Launch and manage the dev-pipeline from within a cbc session. Start pipeline in background, monitor logs, check status, stop pipeline. Invoke when user wants to start building features, run the pipeline, or check pipeline progress. (project)"
+---
+
+# Dev-Pipeline Launcher
+
+Launch the autonomous development pipeline from within a cbc conversation. The pipeline runs as a fully detached background process -- closing the cbc session does NOT stop the pipeline.
+
+### When to Use
+
+**Start pipeline** -- User says:
+- "run pipeline", "start pipeline", "start building", "launch dev-pipeline"
+- "run the features", "execute feature list", "start implementing"
+- "启动流水线", "开始实现", "运行流水线", "开始自动开发"
+- "实现接下来的步骤", "执行 feature list", "开始构建"
+- After app-planner completes: "go", "start", "build it", "开始吧"
+
+**Check status** -- User says:
+- "pipeline status", "check pipeline", "how's it going", "progress"
+- "流水线状态", "查看进度", "现在什么情况"
+
+**Stop pipeline** -- User says:
+- "stop pipeline", "kill pipeline", "halt", "pause"
+- "停止流水线", "暂停流水线"
+
+**Show logs** -- User says:
+- "show logs", "pipeline logs", "tail logs", "what's happening"
+- "查看日志", "流水线日志", "看看日志"
+
+**Do NOT use this skill when:**
+- User wants to plan features (use `app-planner` instead)
+- User wants to implement a single feature manually within current session (use `prizmkit-implement`)
+- User wants to define specs/plan (use `prizmkit-specify` / `prizmkit-plan`)
+
+### Prerequisites
+
+Before any action, validate:
+
+1. **dev-pipeline exists**: Confirm `dev-pipeline/launch-daemon.sh` is present and executable
+2. **For start**: `feature-list.json` must exist in project root (or user-specified path)
+3. **Dependencies**: `jq`, `python3`, `cbc` must be in PATH
+
+Quick check:
+```bash
+command -v jq && command -v python3 && command -v cbc && echo "All dependencies OK"
+```
+
+If `feature-list.json` is missing, inform user:
+> "No feature-list.json found. Run the `app-planner` skill first to generate one, or provide a path to your feature list."
+
+### Workflow
+
+Detect user intent from their message, then follow the corresponding workflow:
+
+---
+
+#### Intent A: Start Pipeline
+
+1. **Check prerequisites**:
+   ```bash
+   ls feature-list.json 2>/dev/null && echo "Found" || echo "Missing"
+   ```
+
+2. **Check not already running**:
+   ```bash
+   dev-pipeline/launch-daemon.sh status 2>/dev/null
+   ```
+   If running, inform user and ask: "Pipeline is already running. Want to restart it, check status, or view logs?"
+
+3. **Show feature summary** (so user knows what will be built):
+   ```bash
+   python3 -c "
+   import json
+   with open('feature-list.json') as f:
+       data = json.load(f)
+   features = data.get('features', [])
+   print(f'Total features: {len(features)}')
+   for f in features:
+       print(f\"  {f['id']}: {f.get('title', 'untitled')}\")
+   "
+   ```
+   If pipeline state already exists, use the status command instead:
+   ```bash
+   python3 dev-pipeline/scripts/update-feature-status.py \
+     --feature-list feature-list.json \
+     --state-dir dev-pipeline/state \
+     --action status 2>/dev/null
+   ```
+
+4. **Ask user to confirm**: "Ready to launch the pipeline? It will process N features in the background."
+
+5. **Launch**:
+   ```bash
+   dev-pipeline/launch-daemon.sh start feature-list.json
+   ```
+   If user specified environment overrides (e.g. timeout, retries, verbose):
+   ```bash
+   dev-pipeline/launch-daemon.sh start feature-list.json --env "SESSION_TIMEOUT=7200 MAX_RETRIES=5"
+   ```
+
+6. **Verify launch**:
+   ```bash
+   dev-pipeline/launch-daemon.sh status
+   ```
+
+7. **Start log monitoring** -- Use the Bash tool with `run_in_background: true`:
+   ```bash
+   tail -f dev-pipeline/state/pipeline-daemon.log
+   ```
+   This runs in background so you can continue interacting with the user.
+
+8. **Report to user**:
+   - Pipeline PID
+   - Log file location
+   - "You can ask me 'pipeline status' or 'show logs' at any time"
+   - "Closing this session will NOT stop the pipeline"
+
+---
+
+#### Intent B: Check Status
+
+1. **Check daemon status**:
+   ```bash
+   dev-pipeline/launch-daemon.sh status
+   ```
+
+2. **Show feature-level progress**:
+   ```bash
+   python3 dev-pipeline/scripts/update-feature-status.py \
+     --feature-list feature-list.json \
+     --state-dir dev-pipeline/state \
+     --action status
+   ```
+
+3. **Show recent log activity** (last 20 lines):
+   ```bash
+   tail -20 dev-pipeline/state/pipeline-daemon.log
+   ```
+
+4. **Summarize** to user: total features, completed, in-progress, failed, pending.
+
+---
+
+#### Intent C: Stop Pipeline
+
+1. **Stop the daemon**:
+   ```bash
+   dev-pipeline/launch-daemon.sh stop
+   ```
+
+2. **Verify stopped**:
+   ```bash
+   dev-pipeline/launch-daemon.sh status 2>/dev/null || true
+   ```
+
+3. **Inform user**: "Pipeline stopped. State is preserved -- you can resume later with 'start pipeline' and it will pick up where it left off."
+
+---
+
+#### Intent D: Show Logs
+
+1. **Check if running**:
+   ```bash
+   dev-pipeline/launch-daemon.sh status 2>/dev/null
+   ```
+
+2. **If running** -- Start live tail with Bash tool `run_in_background: true`:
+   ```bash
+   tail -f dev-pipeline/state/pipeline-daemon.log
+   ```
+
+3. **If not running** -- Show last 50 lines:
+   ```bash
+   tail -50 dev-pipeline/state/pipeline-daemon.log
+   ```
+
+4. **For per-feature session logs** (when user asks about a specific feature):
+   ```bash
+   # Find current/recent session
+   cat dev-pipeline/state/current-session.json 2>/dev/null
+   # Then tail that feature's session log
+   tail -100 dev-pipeline/state/features/<FEATURE_ID>/sessions/<SESSION_ID>/logs/session.log
+   ```
+
+---
+
+#### Intent E: Custom Parameters
+
+When user specifies custom settings, map to environment variables:
+
+| User says | Environment variable |
+|-----------|---------------------|
+| "timeout 2 hours" / "超时2小时" | `SESSION_TIMEOUT=7200` |
+| "max 5 retries" / "最多重试5次" | `MAX_RETRIES=5` |
+| "verbose mode" / "详细模式" | `VERBOSE=1` |
+| "heartbeat every 60s" | `HEARTBEAT_INTERVAL=60` |
+
+Pass via `--env`:
+```bash
+dev-pipeline/launch-daemon.sh start feature-list.json --env "SESSION_TIMEOUT=7200 MAX_RETRIES=5 VERBOSE=1"
+```
+
+### Error Handling
+
+| Error | Action |
+|-------|--------|
+| `feature-list.json` not found | Tell user to run `app-planner` skill first |
+| `jq` not installed | Suggest: `brew install jq` |
+| `cbc` not in PATH | Check CodeBuddy CLI installation |
+| Pipeline already running | Show status, ask if user wants to stop and restart |
+| PID file stale (process dead) | `launch-daemon.sh` auto-cleans, retry start |
+| Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 dev-pipeline/state/pipeline-daemon.log` |
+| All features blocked/failed | Show status, suggest resetting failed features: `dev-pipeline/run.sh run <F-XXX> --clean` |
+| Permission denied on script | Run `chmod +x dev-pipeline/launch-daemon.sh dev-pipeline/run.sh` |
+
+### Integration Notes
+
+- **After app-planner**: This is the natural next step. When user finishes planning and has `feature-list.json`, suggest launching the pipeline.
+- **Session independence**: The pipeline runs completely detached. User can close cbc, open a new session later, and use this skill to check progress or stop the pipeline.
+- **Single instance**: Only one pipeline can run at a time. The PID file prevents duplicates.
+- **State preservation**: Stopping and restarting the pipeline resumes from where it left off -- completed features are not re-run.
+- **HANDOFF**: After pipeline completes all features, suggest running `prizmkit-code-review` for overall review, or `prizmkit-summarize` to archive.

package/bundled/skills/prizm-kit/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: "prizm-kit"
+description: "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management. Use 'prizmkit.*' for help. (project)"
+---
+
+# PrizmKit — Full-Lifecycle Development Toolkit
+
+PrizmKit is a comprehensive, independent AI development toolkit that covers the complete development lifecycle from project inception to delivery and maintenance. It can take over any project and keep documentation in sync with code.
+
+## Quick Start
+
+**CodeBuddy:**
+```
+prizmkit.init          # Take over a project (scan, assess, generate docs)
+prizmkit.specify       # Create feature specification
+prizmkit.plan          # Generate implementation plan
+prizmkit.tasks         # Break down into executable tasks
+prizmkit.analyze       # Cross-document consistency check (recommended)
+prizmkit.implement     # Execute implementation
+prizmkit.commit        # Commit with auto doc update
+```
+
+**Claude Code:**
+```
+/prizmkit-init          # Take over a project (scan, assess, generate docs)
+/prizmkit-specify       # Create feature specification
+/prizmkit-plan          # Generate implementation plan
+/prizmkit-tasks         # Break down into executable tasks
+/prizmkit-analyze       # Cross-document consistency check (recommended)
+/prizmkit-implement     # Execute implementation
+/prizmkit-committer     # Commit with auto doc update
+```
+
+## When to Use the Full Workflow
+
+**Use full workflow (specify -> plan -> tasks -> implement):**
+- New features or user-facing capabilities
+- Multi-file coordinated changes
+- Architectural decisions
+- Data model or API changes
+
+**Use fast path (implement -> commit directly):**
+- Bug fixes with clear root cause
+- Single-file config or typo fixes
+- Simple refactors (rename, extract)
+- Documentation-only changes
+- Test additions for existing code
+
+For fast-path changes, you can directly use the implement command with inline task description, then the commit command.
+- CodeBuddy: `prizmkit.implement` → `prizmkit.commit`
+- Claude Code: `/prizmkit-implement` → `/prizmkit-committer`
+
+### Bug Fix Documentation Policy
+
+**Bug fixes MUST NOT create new documentation entries.** Bug fixes are refinements of incomplete existing features — they complete what was already planned, not introduce new functionality. Specifically:
+
+- Do NOT run `prizmkit.summarize` for bug fix commits (no new REGISTRY.md entries)
+- Do NOT create new spec/plan/tasks under `.prizmkit/specs/` for bug fixes
+- Do NOT update `.prizm-docs/` module docs for pure bug fixes (no interface/dependency change)
+- Bug fix commits use `fix(<scope>):` prefix in Conventional Commits, not `feat:`
+
+All documentation records are for: features, projects, code logic, and module indexes. Bug fixes do not alter the system's functional scope — they bring existing features to their intended state.
+
+## Architecture
+
+PrizmKit produces two complementary knowledge layers:
+
+```
+.prizm-docs/           → Project "what is" (static: structure, interfaces, rules, traps, decisions)
+.prizmkit/specs/       → Feature "what to do" (workflow: spec → plan → tasks → code)
+```
+
+## Skill Inventory (32 skills)
+
+### Foundation (3)
+- **prizm-kit** — Full-lifecycle dev toolkit entry point
+- **prizmkit-init** — Project takeover: scan → assess → generate docs → initialize
+- **prizmkit-prizm-docs** — Prizm documentation framework: `prizmkit.doc.init`, `prizmkit.doc.update`, `prizmkit.doc.status`, `prizmkit.doc.rebuild`, `prizmkit.doc.validate`, `prizmkit.doc.migrate`
+
+### Spec-Driven Workflow (10)
+- **prizmkit-specify** — Create structured feature specifications from natural language
+- **prizmkit-clarify** — Interactive requirement clarification
+- **prizmkit-plan** — Generate technical plan + data model + API contracts
+- **prizmkit-tasks** — Break plan into executable task list
+- **prizmkit-analyze** — Cross-document consistency analysis (spec ↔ plan ↔ tasks)
+- **prizmkit-implement** — Execute tasks following TDD approach
+- **prizmkit-code-review** — Review code against spec and plan
+- **prizmkit-summarize** — Archive completed features to REGISTRY.md
+- **prizmkit-committer** — Commit workflow with automatic Prizm doc update
+- **prizmkit-retrospective** — Post-feature learning: extract lessons → update Prizm docs
+
+### Quality Assurance (5)
+- **prizmkit-tech-debt-tracker** — [Tier 1] Technical debt identification and tracking via code pattern analysis
+- **prizmkit-bug-reproducer** — [Tier 1] Generate minimal reproduction scripts and test cases
+- **prizmkit-adr-manager** — [Tier 1] Architecture Decision Records management
+- **prizmkit-security-audit** — [Tier 2] AI-assisted security review checklist via static analysis
+- **prizmkit-dependency-health** — [Tier 2] Dependency review based on manifest files
+
+### Operations & Deployment (4)
+- **prizmkit-ci-cd-generator** — [Tier 2] Generate CI/CD pipeline config templates
+- **prizmkit-deployment-strategy** — [Tier 2] Deployment planning with rollback procedures
+- **prizmkit-db-migration** — [Tier 2] Database migration script generation
+- **prizmkit-monitoring-setup** — [Tier 2] Generate monitoring config templates
+
+### Debugging & Troubleshooting (3)
+- **prizmkit-error-triage** — [Tier 2] Error categorization and root cause analysis
+- **prizmkit-log-analyzer** — [Tier 2] Log pattern recognition via text analysis
+- **prizmkit-perf-profiler** — [Tier 2] Static analysis for performance issues
+
+### Documentation (2)
+- **prizmkit-onboarding-generator** — [Tier 2] Generate developer onboarding guides
+- **prizmkit-api-doc-generator** — [Tier 2] Extract API documentation from source code
+
+### Pipeline & Companion (5)
+- **prizmkit-bug-fix-workflow** — [Tier 1] End-to-end bug fix workflow: triage → reproduce → fix → verify → commit
+- **app-planner** — Interactive app planning that produces feature-list.json for dev-pipeline
+- **bug-planner** — Interactive bug planning that produces bug-fix-list.json for bugfix-pipeline
+- **dev-pipeline-launcher** — Launch and manage the dev-pipeline from within a CLI session
+- **bugfix-pipeline-launcher** — Launch and manage the bugfix pipeline from within a CLI session
+
+### Tier Definitions
+
+- **Tier 1**: AI can perform well independently — these tasks align with AI's core strengths (documentation, code pattern analysis, test generation)
+- **Tier 2**: Useful as guidance/checklist — AI provides static analysis and recommendations, but lacks access to real external tools (scanners, profilers, package registries, runtime environments)
+- **Core skills** (no tier label): The 12 foundational, documentation, spec-driven workflow, and commit skills that form PrizmKit's primary value
+
+## Installation
+
+**Option 1: npm CLI (recommended — works for both platforms)**
+```bash
+npx prizmkit init
+```
+Interactive installer auto-detects your platform and guides you through configuration.
+
+**Option 2: Claude Code Plugin**
+Install the `prizmkit` plugin via Claude Code's plugin system, then run `/prizmkit-init`.
+
+**Option 3: Manual Install (CodeBuddy)**
+```bash
+python3 ${SKILL_DIR}/scripts/install-prizmkit.py --target <project-skills-dir>
+```
+
+## Hook / Rules Configuration
+
+**CodeBuddy:** Uses native `type: prompt` hooks for automatic doc updates before commits.
+The hook is configured automatically by `prizmkit-init`. See `assets/hooks/prizm-commit-hook.json`.
+
+**Claude Code:** Uses `.claude/rules/` glob-scoped markdown files for automatic enforcement.
+Rules are created automatically by `prizmkit-init` (or `/prizmkit-init`). See:
+- `assets/claude-md-template.md` for the project memory template
+- The init skill creates `prizm-documentation.md` and `prizm-commit-workflow.md` rules

package/bundled/skills/prizm-kit/assets/claude-md-template.md

@@ -0,0 +1,38 @@
+## PrizmKit Documentation Framework
+
+This project uses PrizmKit with the Prizm documentation system for AI-optimized progressive context loading.
+
+### Progressive Loading Protocol
+- ON SESSION START: Always read `.prizm-docs/root.prizm` first (L0 — project map)
+- ON TASK: Read L1 (`.prizm-docs/<module>.prizm`) for relevant modules referenced in MODULE_INDEX
+- ON FILE EDIT: Read L2 (`.prizm-docs/<module>/<submodule>.prizm`) before modifying files. Pay attention to TRAPS and DECISIONS.
+- NEVER load all .prizm docs at once. Load only what is needed for the current task.
+
+### Auto-Update Protocol
+- BEFORE EVERY COMMIT: Update affected `.prizm-docs/` files
+- The `.claude/rules/` files will enforce this automatically
+- Use `/prizmkit-committer` command for the complete commit workflow
+
+### Doc Format Rules
+- All `.prizm` files use KEY: value format, not prose
+- Size limits: L0 = 4KB, L1 = 3KB, L2 = 5KB
+- Arrow notation (->) indicates load pointers to other .prizm docs
+- DECISIONS and CHANGELOG are append-only (never delete entries)
+
+### Creating New L2 Docs
+- When you first modify files in a sub-module that has no L2 doc:
+  1. Read the source files in that sub-module
+  2. Generate a new L2 `.prizm` file following Prizm specification
+  3. Add a pointer in the parent L1 doc's SUBDIRS section
+
+### Available Commands
+Run `/prizm-kit` to see all available PrizmKit commands.
+
+### Fast Path for Simple Changes
+Not every change needs the full spec -> plan -> tasks workflow. Use fast path for:
+- Bug fixes with clear root cause, config tweaks, typo fixes, simple refactors
+- Documentation-only changes, test additions for existing code
+- Directly use `/prizmkit-implement` with inline task description, then `/prizmkit-committer`
+
+Use the full workflow (/prizmkit-specify -> /prizmkit-plan -> /prizmkit-tasks -> /prizmkit-analyze -> /prizmkit-implement) for:
+- New features, multi-file coordinated changes, architectural decisions, data model or API changes

package/bundled/skills/prizm-kit/assets/codebuddy-md-template.md

@@ -0,0 +1,35 @@
+## PrizmKit Documentation Framework
+
+This project uses PrizmKit with the Prizm documentation system for AI-optimized progressive context loading.
+
+### Progressive Loading Protocol
+- ON SESSION START: Always read `.prizm-docs/root.prizm` first (L0 — project map)
+- ON TASK: Read L1 (`.prizm-docs/<module>.prizm`) for relevant modules referenced in MODULE_INDEX
+- ON FILE EDIT: Read L2 (`.prizm-docs/<module>/<submodule>.prizm`) before modifying files. Pay attention to TRAPS and DECISIONS.
+- NEVER load all .prizm docs at once. Load only what is needed for the current task.
+
+### Auto-Update Protocol
+- BEFORE EVERY COMMIT: Update affected `.prizm-docs/` files
+- The UserPromptSubmit hook will remind you automatically
+- Use `prizmkit-committer` skill for the complete commit workflow
+
+### Doc Format Rules
+- All `.prizm` files use KEY: value format, not prose
+- Size limits: L0 = 4KB, L1 = 3KB, L2 = 5KB
+- Arrow notation (->) indicates load pointers to other .prizm docs
+- DECISIONS and CHANGELOG are append-only (never delete entries)
+
+### Creating New L2 Docs
+- When you first modify files in a sub-module that has no L2 doc:
+  1. Read the source files in that sub-module
+  2. Generate a new L2 `.prizm` file following Prizm specification
+  3. Add a pointer in the parent L1 doc's SUBDIRS section
+
+### Fast Path for Simple Changes
+Not every change needs the full spec -> plan -> tasks workflow. Use fast path for:
+- Bug fixes with clear root cause, config tweaks, typo fixes, simple refactors
+- Documentation-only changes, test additions for existing code
+- Directly use `prizmkit.implement` with inline task description, then `prizmkit.commit`
+
+Use the full workflow (specify -> plan -> tasks -> analyze -> implement) for:
+- New features, multi-file coordinated changes, architectural decisions, data model or API changes

package/bundled/skills/prizm-kit/assets/hooks/prizm-commit-hook.json

@@ -0,0 +1,15 @@
+{
+  "hooks": {
+    "UserPromptSubmit": [
+      {
+        "hooks": [
+          {
+            "type": "prompt",
+            "prompt": "You are a commit-intent detector for PrizmKit. Analyze the user prompt and determine if the user intends to COMMIT, PUSH, FINISH, SHIP, MERGE, or create a PULL REQUEST.\n\nUser prompt: $ARGUMENTS\n\nIF commit intent detected, respond with:\n{\"ok\": true, \"reason\": \"PRIZMKIT_DOC_UPDATE_REQUIRED: Before committing, you MUST update .prizm-docs/ per Prizm auto-update protocol. Steps: 1) Run git diff --cached --name-status. 2) Map changed files to modules via root.prizm MODULE_INDEX. 3) Read and update affected .prizm files (only changed sections). 4) Append to changelog.prizm. 5) Stage .prizm files with git add .prizm-docs/. 6) Then proceed with commit using prizmkit-committer workflow. RULES: Never rewrite entire .prizm files. Never add prose. Only update affected sections.\"}\n\nIF no commit intent, respond with:\n{\"ok\": true}\n\nRespond with JSON only. No explanation.",
+            "timeout": 10
+          }
+        ]
+      }
+    ]
+  }
+}

package/bundled/skills/prizmkit-adr-manager/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: "prizmkit-adr-manager"
+tier: 1
+description: "[Tier 1] Manage Architecture Decision Records. Create, list, and supersede ADRs with full context. AI excels at documentation tasks. (project)"
+---
+
+# PrizmKit ADR Manager
+
+Manage Architecture Decision Records (ADRs) to document and track architectural decisions with full context, alternatives, and consequences.
+
+## Commands
+
+### prizmkit.adr.new \<title\>
+
+Create a new Architecture Decision Record.
+
+**STEPS:**
+
+1. Determine next ADR number from `docs/adr/` directory (scan existing files, increment highest number)
+2. Generate ADR from template (`${SKILL_DIR}/assets/adr-template.md`):
+   - **Title**: Provided by user
+   - **Date**: Current date
+   - **Status**: Proposed
+   - **Context**: Ask user what issue is motivating this decision
+   - **Decision**: Ask user what change is being proposed
+   - **Consequences**: Identify positive and negative consequences
+   - **Alternatives considered**: Ask user about alternatives and why they were rejected
+3. Write to `docs/adr/NNNN-title.md` (zero-padded number, kebab-case title)
+4. Also record in `.prizm-docs/` DECISIONS section of relevant module doc
+
+### prizmkit.adr.list
+
+Show all ADRs with their current status.
+
+**STEPS:**
+
+1. Scan `docs/adr/` directory for ADR files
+2. Parse each file for number, title, and status
+3. Display table:
+   - Number | Title | Status | Date
+   - Status values: Proposed, Accepted, Deprecated, Superseded
+4. Highlight any ADRs in Proposed status that may need review
+
+### prizmkit.adr.supersede \<number\> \<new-title\>
+
+Mark an existing ADR as superseded and create a replacement.
+
+**STEPS:**
+
+1. Read the existing ADR with the given number from `docs/adr/`
+2. Update its status to "Superseded by [ADR-NNNN]" (the new ADR number)
+3. Create a new ADR using the `prizmkit.adr.new` flow:
+   - Pre-populate context with reference to the superseded ADR
+   - Include "Supersedes [ADR-NNNN]" in the new ADR
+4. Write both updated files
+
+## Template
+
+The ADR template is located at `${SKILL_DIR}/assets/adr-template.md` and follows the standard ADR format with Context, Decision, Consequences, and Alternatives sections.
+
+## Path References
+
+All internal asset paths MUST use `${SKILL_DIR}` placeholder for cross-IDE compatibility.
+
+## Output
+
+- ADR files in `docs/adr/` directory
+- Updated DECISIONS section in relevant `.prizm-docs/` module doc

package/bundled/skills/prizmkit-adr-manager/assets/adr-template.md

@@ -0,0 +1,26 @@
+# [NUMBER]. [TITLE]
+
+**Date**: YYYY-MM-DD
+**Status**: Proposed | Accepted | Deprecated | Superseded by [ADR-NNNN]
+
+## Context
+
+[What is the issue that we're seeing that is motivating this decision or change?]
+
+## Decision
+
+[What is the change that we're proposing and/or doing?]
+
+## Consequences
+
+### Positive
+- [Consequence 1]
+
+### Negative
+- [Consequence 1]
+
+## Alternatives Considered
+
+### [Alternative 1]
+- **Description**: [What it is]
+- **Reason rejected**: [Why not chosen]