dld-kit 1.0.0-rc.1

package/skills/dld-snapshot/SKILL.md

@@ -0,0 +1,284 @@
+---
+name: dld-snapshot
+description: Generate SNAPSHOT.md (detailed decision reference) and OVERVIEW.md (narrative synthesis with diagrams) from the decision log.
+compatibility: Requires Node.js 20+ and git.
+metadata:
+  dld-kit-version: "1.0.0-rc.1"
+---
+<!-- Generated by dld-kit from templates/skills/dld-snapshot/SKILL.md. Do not edit: updating the skills overwrites this file. -->
+
+# /dld-snapshot — Generate Spec Projection
+
+You are generating documents that project the current state of the decision log into readable formats. The two built-in documents are always generated:
+
+1. **`decisions/SNAPSHOT.md`** — Detailed per-decision reference. Every active decision with its rationale and code references.
+2. **`decisions/OVERVIEW.md`** — High-level narrative synthesis with Mermaid diagrams. The document you'd hand to someone who needs to understand the system.
+
+If the project's `dld.config.yaml` defines `snapshot_artifacts`, additional custom documents are generated as well (see Step 5).
+
+## Commands
+
+The commands below run the `dld` CLI bundled with the dld-common skill, and need Node.js 20+. `<skill-dir>` stands for the absolute path of this skill's directory. If `<skill-dir>/../dld-common/scripts/dld.mjs` does not exist, stop and tell the user to install the dld-common skill: `npx skills add jimutt/dld-kit --skill dld-common`.
+
+This skill uses: `detect-snapshot-changes`, `collect-active-decisions`, `update-snapshot-state`.
+
+## Prerequisites
+
+Check that `dld.config.yaml` exists at the repo root. If not, tell the user to run `/dld-init` first and stop.
+
+There must be at least one `accepted` decision. If all decisions are `proposed`, tell the user there's nothing to snapshot yet and suggest `/dld-implement`.
+
+Check for uncommitted changes to decision files. Run `git status --porcelain -- <decisions_dir>/records/` and inspect the output. If there are unstaged or staged-but-uncommitted decision files, commit them first with a message like `"Update decision records"` before proceeding. This ensures the change detection script can rely on git history. Tell the user you are committing pending decision changes.
+
+## Step 1: Determine update mode
+
+If the user's message includes `--full` (e.g., `/dld-snapshot --full`), skip change detection and use **full mode** for all documents.
+
+Otherwise, run:
+
+```bash
+node "<skill-dir>/../dld-common/scripts/dld.mjs" detect-snapshot-changes
+```
+
+This outputs:
+- `mode: full` — no prior snapshot state exists, or SNAPSHOT.md/OVERVIEW.md are missing. Proceed with full generation.
+- `mode: incremental` — prior state exists. The output also includes:
+  - `new_decisions:` — comma-separated list of new accepted decision IDs (e.g., `DL-072, DL-073`)
+  - `modified_decisions:` — comma-separated list of existing decisions changed since last snapshot (status changes, content edits)
+  - `commit_range:` — the git range since last snapshot (e.g., `abc1234..HEAD`)
+
+If mode is `incremental` but both `new_decisions` and `modified_decisions` are empty, tell the user nothing has changed since the last snapshot and stop.
+
+## Step 2: Collect active decisions
+
+```bash
+node "<skill-dir>/../dld-common/scripts/dld.mjs" collect-active-decisions
+```
+
+This outputs the full content of all `accepted` decisions, separated by `===DLD_DECISION_BOUNDARY===` markers. Parse the output to extract each decision's frontmatter and body. Use the project mode from `dld.config.yaml` (already checked in prerequisites) to determine the organization strategy.
+
+## Step 3: Generate or update SNAPSHOT.md
+
+### Full mode
+
+Write `decisions/SNAPSHOT.md` from scratch using the template and rules below.
+
+### Incremental mode
+
+Read the existing `decisions/SNAPSHOT.md` and apply targeted edits:
+
+1. **For each new decision:** Identify which group heading (`## Namespace` or `## Tag Group`) it belongs to. Insert the new `### DL-NNN: Title` section in the correct position (ascending ID order within the group). If the group heading doesn't exist yet, add a new `## Group` section.
+2. **For each modified decision:** Read its current status from the decision file.
+   - If now `superseded` or `deprecated`: remove its `### DL-NNN` section from the file. If the group becomes empty after removal, remove the group heading too.
+   - If still `accepted` but content changed: replace its `### DL-NNN` section with updated content.
+   - If it has a new `amends` relationship: add an `*Amended by: DL-YYY*` line to the target decision's section.
+3. **Update the header:** Adjust the "Active decisions" count, the "DL-001 through DL-XXX" range, and the date.
+
+Do NOT rewrite the entire file. Use targeted edits to insert, remove, or modify only the affected sections.
+
+### Template
+
+```markdown
+# System Snapshot
+
+> Auto-generated from the decision log on YYYY-MM-DD. Do not edit manually.
+> Use `/dld-snapshot` to regenerate. Source of truth: individual decision records.
+>
+> **Active decisions:** N (DL-001 through DL-XXX, excluding superseded/deprecated)
+
+---
+
+## <Namespace or Tag Group>
+
+### DL-NNN: <Title>
+*Supersedes: DL-XXX* ← only if applicable
+*Amends: DL-XXX* ← only if applicable
+*Amended by: DL-YYY* ← only if another decision amends this one
+
+<The Decision section from the record — what was decided. Copy verbatim or lightly condense.>
+
+**Rationale:** <1-3 sentence summary of the Rationale section. Condense, don't copy verbatim.>
+
+**Code:** `<path>` → `<symbol>`, `<path>`
+
+---
+
+### DL-NNN: <Title>
+...
+```
+
+### Organization rules
+
+**Namespaced projects:** Primary grouping by namespace. Within each namespace, decisions listed by ID ascending (oldest first — they build on each other).
+
+**Flat projects:** Group by tag. Decisions with multiple tags appear under their first/primary tag. Decisions with no tags go under a "General" section. Within each group, decisions listed by ID ascending.
+
+### Content rules
+
+- Only include `accepted` decisions
+- Skip `superseded`, `deprecated`, and `proposed` decisions entirely
+- When a decision supersedes another (check the `supersedes` field in the YAML frontmatter), include a `*Supersedes: DL-XXX*` note
+- When a decision amends another (check the `amends` field), include an `*Amends: DL-XXX*` note on the amending decision and an `*Amended by: DL-YYY*` note on the original decision
+- The **Decision** section content should be copied directly or lightly condensed — this is the authoritative statement
+- The **Rationale** should be condensed to 1-3 sentences — enough to understand *why*, not every detail
+- **Code** references should list paths and symbols from the frontmatter `references` field
+- If a decision has no Rationale section, omit the Rationale line
+- If a decision has no references, omit the Code line
+
+## Step 4: Generate or update OVERVIEW.md
+
+This is fundamentally different from SNAPSHOT.md. You are **synthesizing** across decisions to create a readable narrative that explains the system's current design. Think of it as the document you'd give a new team member or use to onboard an AI agent on the project.
+
+### Full mode
+
+Write `decisions/OVERVIEW.md` from scratch using the template and guidelines below.
+
+### Incremental mode
+
+Read the existing `decisions/OVERVIEW.md`. Identify which domain sections are affected by the new and modified decisions — look at their namespaces, tags, and the topics they cover. Then:
+
+1. **Update only the affected sections.** Rewrite each affected section to integrate new decisions or remove references to superseded/deprecated ones. Leave unaffected sections untouched.
+2. **Add new sections** if new decisions introduce a domain area not covered by existing sections.
+3. **Update diagrams** only if the changeset affects the relationships or components they depict.
+4. **Update the header** (decision count, date) and **Key Technical Choices** if any new decisions are cross-cutting.
+
+**Maintaining appropriate abstraction:** The overview should remain a high-level narrative, not grow into a detailed specification. As you update sections, consider whether the overall document still reads as an overview. If adding new decisions makes a section too detailed or the document too long, condense older stable content to make room — summarize established decisions more aggressively to keep focus on what matters for understanding the system. If the document's section structure no longer properly organizes the content (e.g., a new cross-cutting concern spans multiple existing sections), restructure as needed — this may mean a larger rewrite of the document, which is appropriate when the system's shape has meaningfully changed.
+
+### Template
+
+```markdown
+# System Overview
+
+> Auto-generated narrative synthesis from N active decisions. Last updated YYYY-MM-DD.
+> This document is derived from individual decision records — do not edit manually.
+> Use `/dld-snapshot` to regenerate.
+
+## Architecture Overview
+
+<If there are enough architectural decisions to warrant it, include a high-level Mermaid diagram showing key components and their relationships. Base this on the code references and decision content.>
+
+```mermaid
+graph TD
+    A[Component A] --> B[Component B]
+    B --> C[Component C]
+```
+
+## <Namespace or Domain Area>
+
+<Narrative prose synthesizing the decisions in this area. Write in present tense.
+Explain what the system does and why, weaving together multiple decisions into
+a coherent story. Reference decision IDs parenthetically, e.g., (DL-012).>
+
+<If the decisions in this area describe a flow or process, include a Mermaid diagram:>
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant API
+    participant PaymentGateway
+    ...
+```
+
+<Continue with other areas...>
+
+## Decision Relationships
+
+<Only include this section if there are supersession chains, amendment relationships, or closely related decision groups.
+If no decisions supersede or amend others and there are no meaningful relationship clusters, omit this section entirely.>
+
+```mermaid
+graph LR
+    DL-003 -->|superseded by| DL-012
+    DL-012 -.->|amends| DL-005
+    DL-012 -.->|related| DL-014
+```
+
+## Key Technical Choices
+
+<Bullet-point summary of the most impactful cross-cutting decisions that don't
+belong to a single area. E.g., "PostgreSQL for primary data store (DL-001)",
+"All API input validated with Zod schemas (DL-008)".>
+```
+
+### Narrative guidelines
+
+- **Write prose, not lists.** The snapshot already provides the structured listing. The overview should read like a design document.
+- **Synthesize, don't enumerate.** Don't just list decisions — explain how they fit together. "The billing system uses banker's rounding for EU VAT calculations (DL-012), replacing the earlier truncation approach that caused reconciliation failures."
+- **Use present tense.** Describe what the system *does*, not what was decided.
+- **Reference decision IDs parenthetically.** Every claim should be traceable: "(DL-012)" after the relevant statement.
+- **Include Mermaid diagrams where they add clarity.** Good candidates:
+  - Architecture/component diagrams when decisions span multiple components
+  - Sequence diagrams when decisions describe flows or protocols
+  - Relationship diagrams when there are supersession chains or amendment relationships
+  - Don't force diagrams if the decisions are simple or unrelated
+- **Keep it proportional.** A project with 5 decisions needs a short overview. A project with 50 needs more structure. Scale the document to the content.
+- **Group by namespace (namespaced projects) or by domain theme (flat projects).** For flat projects, identify natural domain groupings from tags and decision content.
+
+### Diagram guidelines
+
+When creating Mermaid diagrams:
+- Use `graph TD` or `graph LR` for architecture/component/relationship diagrams
+- Use `sequenceDiagram` for flow/protocol diagrams
+- Use `flowchart` for process/workflow diagrams
+- Keep diagrams focused — show the relationships that decisions actually govern, not a complete system map
+- Label edges with the nature of the relationship
+- Reference relevant decision IDs in node labels or notes where helpful
+- **Always quote node labels** with `["..."]` to avoid parse errors from special characters
+- **Escape `@` as `#64;`** inside node labels and edge labels — raw `@` breaks Mermaid parsing
+- **Use `<br/>` for line breaks** inside quoted labels — do not use `\n` or literal newlines
+- **Avoid special characters** (`(`, `)`, `[`, `]`, `{`, `}`, `|`, `#`, `&`) in unquoted labels — use quoted labels or HTML entities instead
+
+## Step 5: Generate custom artifacts
+
+Read the `snapshot_artifacts` key from `dld.config.yaml`. If the key is absent or the list is empty, skip this step entirely.
+
+For each entry in `snapshot_artifacts`:
+
+1. **Validate the `title`:**
+   - Must end in `.md`. If not, warn the user and skip this artifact.
+   - Must not collide (case-insensitive) with reserved filenames: `SNAPSHOT.md`, `OVERVIEW.md`, `INDEX.md`. If it collides, warn the user and skip this artifact.
+
+2. **Generate `decisions/<title>`** using the collected decisions (from Step 2) as context and the `prompt` field as the generation instruction. The file must begin with this standard header:
+
+   ```markdown
+   # <Title without .md extension>
+
+   > Auto-generated from the decision log on YYYY-MM-DD. Do not edit manually.
+   > Use `/dld-snapshot` to regenerate.
+   ```
+
+   Followed by the content generated according to the prompt.
+
+Keep track of which custom artifacts were successfully generated — you will need the list for Step 6 and Step 7.
+
+## Step 6: Update snapshot state
+
+Pass any successfully generated custom artifact filenames as arguments:
+
+```bash
+node "<skill-dir>/../dld-common/scripts/dld.mjs" update-snapshot-state [ARTIFACT_NAME...]
+```
+
+For example, if custom artifacts `ONBOARDING.md` and `API-CONTRACTS.md` were generated:
+
+```bash
+node "<skill-dir>/../dld-common/scripts/dld.mjs" update-snapshot-state ONBOARDING.md API-CONTRACTS.md
+```
+
+If no custom artifacts were generated, run without arguments:
+
+```bash
+node "<skill-dir>/../dld-common/scripts/dld.mjs" update-snapshot-state
+```
+
+## Step 7: Suggest next steps
+
+> Snapshot generated:
+> - `decisions/SNAPSHOT.md` — detailed reference (N active decisions)
+> - `decisions/OVERVIEW.md` — narrative synthesis with diagrams
+> - `decisions/<ARTIFACT>.md` — <one line per custom artifact generated, if any>
+>
+> Next steps:
+> - Review the generated documents for accuracy
+> - `/dld-decide` — record new decisions
+> - `/dld-audit` — check for drift between decisions and code

package/skills/dld-status/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: dld-status
+description: Quick overview of the decision log state — counts by status, recent decisions, and run tracking info.
+compatibility: No external dependencies.
+metadata:
+  dld-kit-version: "1.0.0-rc.1"
+---
+<!-- Generated by dld-kit from templates/skills/dld-status/SKILL.md. Do not edit: updating the skills overwrites this file. -->
+
+# /dld-status — Decision Log Overview
+
+You are generating a quick overview of the decision log state for the developer.
+
+## Files read
+
+This skill runs no commands. It reads decision files and state files directly:
+- `dld.config.yaml` — project configuration (decisions directory, mode)
+- `decisions/records/DL-*.md` — all decision records (scan YAML frontmatter for status, tags, timestamp, namespace)
+- `decisions/.dld-state.yaml` — run tracking state for audit and snapshot (may not exist)
+
+## Prerequisites
+
+Check that `dld.config.yaml` exists at the repo root. If not, tell the user to run `/dld-init` first and stop.
+
+## Read project context
+
+1. Read `dld.config.yaml` to understand the project structure (flat vs namespaced, decisions directory)
+2. Read all decision files in the records subdirectory (`decisions/records/`) to gather statistics
+
+## Generate the overview
+
+### 1. Count decisions by status
+
+Scan all `DL-*.md` files in the records subdirectory (`decisions/records/`, including namespace subdirectories). Read the `status` field from each file's YAML frontmatter. Count:
+- `proposed`
+- `accepted`
+- `deprecated`
+- `superseded`
+
+Present as:
+```
+## Decision Log Status
+
+| Status | Count |
+|--------|-------|
+| proposed | 3 |
+| accepted | 12 |
+| deprecated | 2 |
+| superseded | 1 |
+| **Total** | **18** |
+```
+
+### 2. Recent decisions
+
+Show the 5 most recent decisions (by timestamp), with ID, title, status:
+
+```
+## Recent Decisions
+
+| ID | Title | Status | Date |
+|----|-------|--------|------|
+| DL-018 | ... | proposed | 2026-03-07 |
+| DL-017 | ... | accepted | 2026-03-06 |
+| ...
+```
+
+### 3. Decisions by grouping
+
+**Namespaced projects:** Show decision counts per namespace.
+
+```
+## By Namespace
+
+| Namespace | Total | Proposed | Accepted |
+|-----------|-------|----------|----------|
+| billing | 8 | 1 | 7 |
+| auth | 5 | 2 | 3 |
+| shared | 5 | 0 | 5 |
+```
+
+**All projects:** If there are tags in use, show the most active tags (those with the most decisions):
+
+```
+## Active Tags
+
+| Tag | Decisions |
+|-----|-----------|
+| payment-gateway | 4 |
+| auth-refactor | 3 |
+```
+
+### 4. Run tracking info
+
+Read `decisions/.dld-state.yaml` if it exists. Report:
+- Last audit run time and commit hash
+- Last snapshot run time
+
+If the file doesn't exist, note that no audits or snapshots have been run yet.
+
+```
+## Run History
+
+- **Last audit:** 2026-03-06 at commit `a1b2c3d` (1 day ago)
+- **Last snapshot:** 2026-03-05 (2 days ago, covers through DL-015)
+```
+
+Or:
+```
+## Run History
+
+No audits or snapshots have been run yet. Use `/dld-audit` to check for drift.
+```
+
+### 5. Proposed decisions needing action
+
+If there are any `proposed` decisions, list them as a call to action:
+
+```
+## Pending Implementation
+
+These decisions are proposed but not yet implemented:
+- **DL-016**: Rate limiting strategy
+- **DL-017**: Cache invalidation approach
+- **DL-018**: Error response format
+
+Use `/dld-implement DL-NNN` to implement them.
+```

package/templates/rules/dld-workflow.md

@@ -0,0 +1,22 @@
+# DLD (Decision-Linked Development)
+
+This project uses Decision-Linked Development. Decision records (DL-*.md) live in the `records/` subdirectory of the decisions directory set in `dld.config.yaml` (`decisions/` by default). High-level docs (INDEX.md, OVERVIEW.md, SNAPSHOT.md) live in the decisions directory.
+
+## Rules
+
+- When you encounter `@decision(DL-XXX)` annotations in code, read the referenced decision with the dld-lookup skill BEFORE modifying the annotated code.
+- ALWAYS look up and verify related decisions before modifying annotated code. Do not skip this step.
+- NEVER modify code in a way that contradicts an existing decision without first confirming with the user. If the change requires breaking a previous decision, a new decision must be recorded (with the dld-decide skill) that explicitly supersedes the old one. If it only partially modifies a previous decision, record it as an amendment instead.
+
+## Skills
+
+- dld-decide: record a new decision
+- dld-plan: break down a feature into multiple grouped decisions
+- dld-implement: implement proposed decisions
+- dld-lookup: query decisions by ID, tag, or code path
+- dld-adjust: adjust or update existing decisions
+- dld-audit: scan for drift between decisions and code
+- dld-snapshot: regenerate SNAPSHOT.md and OVERVIEW.md from the decision log
+- dld-status: a quick overview of the decision log state
+- dld-retrofit: generate decisions from an existing codebase
+- dld-reindex: resolve decision-ID collisions with the base branch (and open PRs) before rebasing

package/templates/skills/dld-adjust/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: dld-adjust
+description: Adjust or update existing decision records. Handles permission gating for accepted decisions and correctly interprets adjustment requests.
+compatibility: Requires Node.js 20+ and git.
+---
+
+# /dld-adjust — Adjust a Decision
+
+You are helping the developer adjust one or more existing decision records. Your job is to apply their requested changes accurately and minimally.
+
+## Interaction style
+
+Use the `AskUserQuestion` tool for all questions and prompts. This provides a structured input experience for the user.
+
+## Commands
+
+{{dld-setup}}
+
+This skill uses: `regenerate-index`.
+
+## Prerequisites
+
+Check that `dld.config.yaml` exists at the repo root. If not, tell the user to run `/dld-init` first and stop.
+
+## Read project context
+
+This skill is typically invoked mid-session after `/dld-plan`, `/dld-decide`, or during `/dld-implement`, so the project context and decision content are likely already in your conversation context. Only read these if you don't already have the information:
+
+1. `dld.config.yaml` — project structure (flat vs namespaced, decisions directory)
+2. The target decision file(s) — decision records (`DL-*.md`) live in the `records/` subdirectory under the decisions directory
+
+## Step 1: Identify the decision(s)
+
+The user may specify decision IDs explicitly (e.g., `/dld-adjust DL-005`), but often they won't — this skill is typically used right after `/dld-plan`, `/dld-decide`, or during `/dld-implement`, so the decisions are already part of the current conversation context.
+
+- **Explicit IDs provided** — use those directly.
+- **No IDs provided** — infer which decision(s) the user is referring to from the conversation context. If decisions were recently created or discussed in this session, assume those are the target. If it's still ambiguous, ask using `AskUserQuestion`.
+
+Find and read each decision file. If a decision ID is not found, report the error and continue with any remaining valid IDs.
+
+## Step 2: Determine if confirmation is needed
+
+For each decision, check whether editing requires user confirmation:
+
+### Proposed decisions (`status: proposed`)
+
+Edit freely. No confirmation needed — proposed decisions are mutable by convention.
+
+### Accepted decisions (`status: accepted`)
+
+Check if the decision file has been committed and pushed to the remote:
+
+```bash
+# Get the last commit hash for the decision file
+LAST_COMMIT=$(git log --format=%H -1 -- <path-to-decision-file>)
+
+# Check if that commit exists on any remote branch
+git branch -r --contains "$LAST_COMMIT" 2>/dev/null
+```
+
+- **Not yet pushed** (commit not on any remote branch, file is uncommitted, or file is untracked) — edit freely. It is still local work-in-progress.
+- **Pushed to remote** — this decision has been published. Use `AskUserQuestion` to present options:
+  1. **Edit anyway** — modify the accepted decision directly (breaks immutability convention)
+  2. **Supersede instead** — record a new decision via `/dld-decide` that supersedes this one
+  3. **Cancel** — do nothing
+
+If the user chooses to supersede, direct them to `/dld-decide` and stop. If they cancel, stop. Only proceed with editing if they explicitly choose to edit anyway.
+
+### Deprecated or superseded decisions
+
+These are historical records. Ask for confirmation before editing — modifying historical decisions is unusual.
+
+## Step 3: Collect the adjustment request
+
+If the user provided the adjustment alongside the skill invocation (e.g., `/dld-adjust DL-005 remove the mention of Java records`), use that directly.
+
+Otherwise, ask what changes they want to make.
+
+Read the current decision content so you understand the full context of what you are working with.
+
+## Step 4: Apply the changes
+
+### CRITICAL — How to interpret adjustment requests
+
+AI agents consistently misinterpret adjustment requests. Follow these rules exactly:
+
+**"Remove X" means DELETE the content about X.**
+Do NOT replace it with "We decided not to use X" or "We chose against X" or any other negative phrasing. Simply remove the sentences, bullet points, or paragraphs that mention X. The goal is a clean decision record that reads as if X was never discussed.
+
+**"Change X to Y" means REPLACE the content.**
+Find where X is described and replace it with Y. Do not add explanatory text about the change.
+
+**"Add X" means INSERT new content.**
+Add the new content in the appropriate section. Do not add meta-commentary about it being an addition.
+
+**General principle:** The decision record should always read as a clean, coherent document. Never add editorial notes like "Updated on...", "Previously we...", "This was changed from...", or "We decided against...". The record captures the current state of the decision, not a changelog of edits.
+
+**Examples of WRONG vs RIGHT:**
+
+User says: *"Remove the mention of Java records from DL-005"*
+
+- WRONG: Replacing "We will use Java records for DTOs" with "We decided not to use Java records for DTOs"
+- RIGHT: Deleting the sentence "We will use Java records for DTOs" entirely (and any related sentences about Java records)
+
+User says: *"Change the retry count from 3 to 5"*
+
+- WRONG: Adding "Originally 3 retries, changed to 5 retries because..."
+- RIGHT: Replacing "3 retries" with "5 retries" wherever it appears in the decision
+
+User says: *"Remove the part about caching"*
+
+- WRONG: "We considered caching but decided it is not relevant to this decision"
+- RIGHT: Delete all sentences and paragraphs about caching. Adjust surrounding text so the document flows naturally.
+
+### Applying edits
+
+1. Read the full decision file
+2. Apply the requested changes to the markdown body (and frontmatter fields like title or tags if affected)
+3. Write the updated file
+4. Show the user a brief summary of what changed
+
+If multiple decisions are being adjusted, process them one at a time.
+
+## Step 5: Regenerate INDEX.md
+
+If any decision titles or metadata changed:
+
+```bash
+{{dld}} regenerate-index
+```
+
+## Step 6: Suggest next steps
+
+> Adjusted **DL-NNN**: [brief description of what changed]
+>
+> Next steps:
+> - `/dld-lookup DL-NNN` — review the updated decision
+> - `/dld-implement DL-NNN` — implement if the decision is proposed
+> - `/dld-snapshot` — regenerate overview docs to reflect the update