dld-kit 1.0.0-rc.1

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

@@ -0,0 +1,130 @@
+---
+name: dld-init
+description: Bootstrap DLD (Decision-Linked Development) in a repository. Creates dld.config.yaml, the decisions/ directory, and INDEX.md. Run once per project.
+compatibility: Requires Node.js 20+ and git.
+---
+
+# /dld-init — Bootstrap DLD
+
+You are initializing Decision-Linked Development (DLD) in this repository. This is an interactive setup process that runs once per project.
+
+## Interaction style
+
+Use the `AskUserQuestion` tool for all questions and prompts. This provides a structured input experience for the user rather than waiting for freeform replies.
+
+## Commands
+
+{{dld-setup}}
+
+This skill uses: `create-config`, `create-directories`, `create-empty-index`, `install-rule`.
+
+## Prerequisites
+
+- This must be a git repository
+- `dld.config.yaml` must NOT already exist at the repo root (if it does, tell the user DLD is already initialized and suggest the dld-status skill instead)
+
+Users who install dld-kit from npm can run `npx dld-kit init` in a terminal instead: it does steps 2–4 and 6 non-interactively and also installs the skills. This skill covers projects whose skills were installed another way.
+
+## Steps
+
+### 1. Ask about project structure
+
+Ask the user:
+
+> Is this a **flat** project (all decisions in one directory) or a **namespaced** project (decisions organized by component/domain, e.g., for a monorepo)?
+
+- **Flat** is the default and right for most projects
+- **Namespaced** is for monorepos or projects with distinct domains (billing, auth, etc.)
+
+If namespaced, ask for the initial namespace list. Suggest they can add more later.
+
+### 2. Create `dld.config.yaml`
+
+Run `create-config`:
+```bash
+{{dld}} create-config <mode> [namespace1 namespace2 ...]
+```
+
+Example flat:
+```bash
+{{dld}} create-config flat
+```
+
+Example namespaced:
+```bash
+{{dld}} create-config namespaced billing auth shared
+```
+
+### 3. Create directory structure
+
+```bash
+{{dld}} create-directories
+```
+
+This reads mode and namespaces from `dld.config.yaml` (created in step 2).
+
+### 4. Create initial INDEX.md
+
+```bash
+{{dld}} create-empty-index
+```
+
+This reads mode from `dld.config.yaml`.
+
+### 5. Offer to create a practices manifest
+
+Ask the user:
+
+> Would you like to create a **development practices manifest**? This is an optional document (`decisions/PRACTICES.md`) that captures your project's development conventions (testing approach, code style, error handling patterns, etc.). The AI agent reads this when making and implementing decisions.
+>
+> You can skip this now and add it later at any time.
+
+If they accept, help them fill it out by asking about:
+- Testing practices (TDD? coverage targets? integration test requirements?)
+- Code style preferences (error handling patterns, validation approach)
+- Architecture conventions (dependency injection, repository pattern, etc.)
+
+If the repository already has application code, scan it first and suggest conventions you observe (e.g., "I see you're using Result types for error handling and Zod for validation — should I include those?"). This saves the user from having to recall everything from scratch.
+
+Write `decisions/PRACTICES.md` with their answers in simple markdown format:
+```markdown
+# Development Practices
+
+## Testing
+- ...
+
+## Code Style
+- ...
+
+## Architecture
+- ...
+```
+
+For namespaced projects, this is the root-level shared practices. Mention they can create namespace-specific practices later at `decisions/records/<namespace>/PRACTICES.md`.
+
+### 6. Install the always-on rule
+
+The rule tells the agent to look up `@decision` annotations before changing annotated code, in every session. Install it for the harness you are running in:
+
+```bash
+{{dld}} install-rule --agent <harness>
+```
+
+`<harness>` is one of `claude` (Claude Code), `antigravity`, `codex`, `cursor`, `opencode` or `pi`; for another harness that reads `AGENTS.md`, such as Copilot CLI, use `codex`. If you are unsure which one you are, or the user says the team uses several agents, ask the user and pass them all, comma-separated (e.g. `--agent claude,codex`). The command decides where the rule goes (a rule file the harness loads, or a marked block in `AGENTS.md` or `CLAUDE.md`) and prints what it wrote; relay that to the user, including any warning.
+
+Do not write the rule into `CLAUDE.md` or `AGENTS.md` yourself.
+
+### 7. Suggest next steps
+
+Tell the user:
+
+> DLD is initialized. Here's what you can do next:
+
+If the repository already has application code:
+> - the dld-retrofit skill — generate initial decisions from your existing codebase
+> - Edit `decisions/PRACTICES.md` to refine your development practices (if created)
+
+If this is a new/empty project:
+> - the dld-decide skill — record your first decision
+> - the dld-plan skill — break down a feature into multiple decisions
+> - Edit `decisions/PRACTICES.md` to refine your development practices (if created)

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

@@ -0,0 +1,73 @@
+---
+name: dld-lookup
+description: Look up decisions by ID, tag, code path, or keyword. IMPORTANT — use this proactively whenever you encounter `@decision` annotations in code you are about to read or modify.
+compatibility: No external dependencies.
+---
+
+# /dld-lookup — Look Up Decisions
+
+You are looking up decision records. This skill is used in two ways:
+1. **Proactively by you (the AI agent)** — whenever you encounter `@decision(DL-XXX)` annotations in code you're reading or about to modify, look up the decision to understand the rationale before proceeding. This is not optional.
+2. **On request by the developer** — to query decisions by ID, tag, code path, or keyword.
+
+## Prerequisites
+
+Check that `dld.config.yaml` exists at the repo root. If not, tell the user to run `/dld-init` first and stop.
+
+Read `dld.config.yaml` to understand the project structure (flat vs namespaced, decisions directory). The decisions directory path can be resolved by reading the `decisions_dir` field from `dld.config.yaml`. Decision records (DL-*.md) live in the `records/` subdirectory under the decisions directory.
+
+## Query modes
+
+Parse the user's input to determine the query type:
+
+### By ID: `/dld-lookup DL-047`
+
+Find and read the decision file `DL-047.md`. Search the records subdirectory (`decisions/records/`, including namespace subdirectories) for the file.
+
+Display the full decision record.
+
+### By tag: `/dld-lookup tag:payment-gateway`
+
+Scan all decision files and find those with the matching tag in their YAML frontmatter `tags` field.
+
+Display a summary table, then offer to show full details for any specific decision:
+
+```
+Found 3 decisions tagged `payment-gateway`:
+
+| ID | Title | Status |
+|----|-------|--------|
+| DL-045 | Payment gateway retry strategy | accepted |
+| DL-046 | Idempotency key format | proposed |
+| DL-047 | Gateway timeout handling | proposed |
+
+Would you like to see the full details for any of these?
+```
+
+### By code path: `/dld-lookup path:src/billing/vat.ts`
+
+Scan all decision files and find those with a matching `path` in their `references` field. Match both exact paths and partial paths (e.g., `vat.ts` should match `src/billing/vat.ts`).
+
+Display results the same way as tag lookup.
+
+### By keyword: `/dld-lookup <search terms>`
+
+If the input doesn't match the `DL-NNN`, `tag:`, or `path:` patterns, treat it as a keyword search. Search across:
+- Decision titles
+- Decision body content (Context, Decision, Rationale, Consequences sections)
+- Tags
+
+Display results the same way as tag lookup.
+
+## Proactive usage (encountering `@decision` annotations)
+
+When you encounter `@decision(DL-XXX)` in code — whether you are reading, modifying, or reviewing it — you MUST look up the referenced decision before proceeding. This applies to all interactions with annotated code, not just when explicitly asked.
+
+After reading the decision:
+
+1. **Understand** the rationale behind the annotated code
+2. **Assess** whether your planned changes are compatible with the decision
+3. **If they conflict** — stop and inform the user. Explain the conflict and suggest recording a new decision via `/dld-decide` that supersedes the existing one. Do not silently modify code in a way that contradicts an active decision.
+4. **If they're compatible** — proceed with the modification
+
+This is the core DLD feedback loop — `@decision` annotations are mechanical triggers that ensure design rationale is consulted before code is changed.

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

@@ -0,0 +1,132 @@
+---
+name: dld-plan
+description: Break down a feature into multiple decisions interactively. Creates a set of decision records grouped by a shared tag.
+compatibility: Requires Node.js 20+ and git.
+---
+
+# /dld-plan — Plan a Feature as Multiple Decisions
+
+You are helping the developer break down a larger feature into discrete decisions. Each decision gets its own record, and they're grouped by a shared tag.
+
+## Interaction style
+
+Use the `AskUserQuestion` tool for all questions and prompts. This provides a structured input experience for the user rather than waiting for freeform replies.
+
+## Commands
+
+{{dld-setup}}
+
+This skill uses: `next-id`, `create-decision`, `update-status`, `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
+
+1. Read `dld.config.yaml` to understand the project structure
+2. Read `decisions/PRACTICES.md` if it exists — consider project conventions when breaking down the feature
+
+## Conversation flow
+
+### 1. Collect the feature description
+
+If the user provided context with the skill invocation, use it. Otherwise ask:
+
+> What feature are you planning? Describe what you want to build and why.
+
+### 2. Determine namespace (namespaced projects only)
+
+If the project is namespaced, determine which namespace(s) this feature belongs to early — infer from the description if possible, otherwise ask. They can span multiple namespaces if the feature crosses boundaries.
+
+Once determined, also read `decisions/records/<namespace>/PRACTICES.md` if it exists for namespace-specific conventions.
+
+### 3. Check for related existing decisions
+
+Before proposing the breakdown, scan existing decision files for:
+- Decisions that reference the same code areas
+- Decisions with overlapping tags or topics
+- Decisions that the new feature might supersede or amend
+
+Mention any related decisions to the developer so the breakdown accounts for them.
+
+### 4. Break it down
+
+Analyze the feature and propose a breakdown into discrete decisions. Each decision should be:
+- **Independent enough** to stand on its own as a rationale record
+- **Concrete enough** that it captures a specific choice, not just "build X"
+- **Ordered** by dependency where relevant (which decisions depend on others)
+
+Present the proposed breakdown:
+
+> I'd suggest breaking this into the following decisions:
+>
+> 1. **Choose payment gateway adapter pattern** — How to abstract the gateway interface
+> 2. **Define retry strategy for failed payments** — Backoff logic and max attempts
+> 3. **Idempotency key format** — How to prevent duplicate charges
+>
+> Does this look right? Want to add, remove, or adjust any?
+
+Iterate with the developer until the breakdown is agreed.
+
+### 5. Choose a grouping tag
+
+Propose a tag that groups these decisions:
+
+> I'll tag all of these with `payment-gateway` so they're grouped together. Sound good?
+
+The tag should be descriptive, kebab-case, and specific to this feature.
+
+### 6. Create decision records
+
+For each decision in the breakdown, run the same commands used by `/dld-decide`:
+
+First, get the next ID:
+```bash
+{{dld}} next-id
+```
+
+Then create the record, piping the body via `printf` with `\n` for newlines (do **not** use literal newlines in the body — use `\n` escape sequences):
+```bash
+printf "## Context\n\n...\n\n## Decision\n\n...\n\n## Rationale\n\n...\n\n## Consequences\n\n..." | {{dld}} create-decision \
+  --id "DL-NNN" \
+  --title "Short descriptive title" \
+  --namespace "billing" \
+  --tags "payment-gateway" \
+  --supersedes "DL-003" \
+  --amends "DL-005" \
+  --body-stdin
+```
+
+Repeat for each decision, incrementing the ID each time. Run `next-id` before each creation to ensure correct sequencing.
+
+If any decision supersedes an existing one, also update the old decision's status:
+```bash
+{{dld}} update-status DL-003 superseded
+```
+
+**Do not** update the status of amended decisions — they stay `accepted`.
+
+For each decision, compose a focused body. Keep it concise — the full feature context is captured across the group. Each individual decision should capture its own specific rationale.
+
+### 7. Regenerate INDEX.md
+
+After all decisions are created:
+```bash
+{{dld}} regenerate-index
+```
+
+### 8. Suggest next steps
+
+> Created **N** decisions for feature `<tag>`:
+>
+> | ID | Title | Status |
+> |----|-------|--------|
+> | DL-010 | Choose payment gateway adapter pattern | proposed |
+> | DL-011 | Define retry strategy for failed payments | proposed |
+> | DL-012 | Idempotency key format | proposed |
+>
+> Next steps:
+> - `/dld-adjust` — refine any decisions before implementing
+> - `/dld-implement` — implement all proposed decisions (or `/dld-implement DL-NNN` for a specific one)
+> - `/dld-lookup tag:<tag>` — review all decisions in this group

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

@@ -0,0 +1,170 @@
+---
+name: dld-reindex
+description: Resolve decision ID collisions between a local branch and the base branch (and open PRs) before rebasing. Renames colliding local decisions with git mv, rewrites cross-references and annotations, then squashes branch commits into a single rebase-clean reindex commit.
+compatibility: Requires Node.js 20+ and git. Open-PR scanning additionally needs the `gh` CLI authenticated against a GitHub remote — the skill falls back gracefully when unavailable.
+---
+
+# /dld-reindex — Resolve Decision ID Collisions
+
+You are helping the developer untangle decision ID collisions before they rebase. Two or more developers can draft `DL-NNN` decisions in parallel; once one of them lands on the base branch (or appears in an open PR), the others must rename their local copies to the next free ID. This skill handles that mechanically and produces a branch state that rebases cleanly.
+
+**This skill rewrites branch history.** That's not optional: if a colliding path (e.g. `decisions/records/DL-205.md`) was added by any commit on the branch, `git rebase` will hit an add/add conflict on that commit *before* it ever sees a later rename. The only fix is to ensure the colliding path never appears in the branch's history. The skill does this by squashing all branch commits since the merge-base into one reindex commit containing the renamed files.
+
+If the branch has already been pushed, finishing the reindex will require a `--force-with-lease` push. The skill asks for explicit consent before rewriting history.
+
+## Interaction style
+
+Use the `AskUserQuestion` tool when prompting for consent and at the finish step. Everything else is deterministic.
+
+**Do not redirect any command output to `/tmp` files.** The commands in this skill emit only what you need to act on; piping to `/tmp/*.txt`, `tee`-ing into scratch files, or stashing stderr separately is unnecessary and creates clutter outside the repo. If a command's output is too long to read in one go, narrow it (`| tail -N`, `| head -N`, or pass a more specific flag) rather than persisting it.
+
+## Commands
+
+{{dld-setup}}
+
+This skill uses: `resolve-base`, `plan-renames`, `rename-decision`, `find-stale-mentions`, `commit-reindex`, `regenerate-index`.
+
+## Prerequisites
+
+1. Check that `dld.config.yaml` exists at the repo root. If not, tell the user to run `/dld-init` first and stop.
+2. Verify the working tree is clean (`git status --porcelain` empty). If not, ask the user to commit or stash first, then stop.
+3. Fetch the latest base state:
+   ```bash
+   git fetch origin
+   ```
+
+## Step 1: Resolve the base ref
+
+```bash
+BASE=$({{dld}} resolve-base)
+```
+
+`resolve-base` prefers the branch's upstream when it tracks a *different* branch (the typical "feature → main" setup). It falls back to `origin/main` if the upstream is unset OR if the upstream tracks the same branch name as the current branch (i.e. it's just the remote copy of this same branch, not a useful collision base).
+
+The user may pass an explicit base when invoking the skill (e.g. `/dld-reindex origin/develop`) — honor it if present.
+
+## Step 2: Plan the renames
+
+```bash
+PLAN=$({{dld}} plan-renames --base "$BASE")
+echo "$PLAN"
+```
+
+Output is tab-separated, one rename per line:
+
+```
+<relative-path>\t<DL-OLD>\t<DL-NEW>
+```
+
+If the output is empty, exit with:
+
+> No ID collisions detected. Safe to rebase onto `$BASE`.
+
+`plan-renames` may print a stderr note like `[dld-reindex] open PRs not scanned: gh CLI not installed`. **Always surface this to the user** so they know the renamed IDs were chosen against base-branch state only and may still collide with an open PR.
+
+The underlying helpers (`find-collisions`, `list-taken-ids`) remain available for debugging, but the SKILL flow always goes through `plan-renames`.
+
+## Step 3: Get explicit consent for the history rewrite
+
+Show the user the rename plan and the implication. Use `AskUserQuestion`:
+
+> Resolving these collisions requires rewriting branch history. I will squash the N commits since `<merge-base>` into a single reindex commit. The original commit subjects will be preserved in the new commit body. If the branch has already been pushed, finishing will require `git push --force-with-lease`. How should I proceed?
+
+Options:
+- **Rewrite and force-push** — agent applies renames, squashes, commits, and runs `git push --force-with-lease`.
+- **Rewrite only** — agent applies renames, squashes, and commits. User pushes when ready.
+- **Cancel** — abort with no changes.
+
+If the user cancels, exit without touching anything.
+
+## Step 4: Apply renames
+
+For each line in the plan, call:
+
+```bash
+{{dld}} rename-decision --old DL-OLD --new DL-NEW --path <relative-path> --base "$BASE"
+```
+
+`rename-decision` does all of:
+
+- `git mv` the file from `DL-OLD.md` to `DL-NEW.md`.
+- Patches the `id:` frontmatter field in the renamed file.
+- Rewrites `DL-OLD` mentions inside the renamed file's body.
+- Rewrites `DL-OLD` mentions inside OTHER locally-added/modified decision files (frontmatter `supersedes` / `amends` / `references` and body). Scoped to the local change set vs the base ref.
+- Rewrites `` `@decision` ``(DL-OLD) annotations to `` `@decision` ``(DL-NEW) in non-decision files that are part of the local change set.
+
+The substitution is digit-aware: renaming `DL-100` will not accidentally rewrite `DL-1000`.
+
+**Note on plain-text DL-NNN mentions in code:** In non-decision files (source code, READMEs, etc.) `rename-decision`'s rewrite is **scoped to `` `@decision` ``(DL-NNN) annotations only**. Bare `DL-NNN` references in comments, log strings, or test fixtures are left untouched here to avoid false-positive matches against unrelated identifiers. Step 5 handles them.
+
+## Step 5: Review plain-text DL-OLD mentions
+
+After all renames are applied (but before the squash), find any remaining bare `DL-OLD` references in non-decision changed files:
+
+```bash
+echo "$PLAN" | {{dld}} find-stale-mentions --base "$BASE"
+```
+
+Output is tab-separated, one match per line: `<path>\t<line>\t<DL-OLD>\t<DL-NEW>\t<line-content>`. Empty output means nothing to review.
+
+For each match:
+
+1. Read the surrounding context in the file.
+2. Decide whether the reference makes sense as `DL-OLD` or should become `DL-NEW`. A code comment like `// Span-driven batching (DL-207) groups resolutions sharing the same turn context (DL-202)` after a `DL-207 → DL-213` rename almost certainly wants `DL-213` (it's prose alongside an annotation). A test fixture string that's checking historical data may need to stay as `DL-OLD`.
+3. If the line should change, use the `Edit` tool to update that specific occurrence — don't do a blanket find-and-replace.
+4. If the line should stay, leave it.
+
+Surface the list of matches to the user with your verdicts before you finish, so they can sanity-check the judgment calls.
+
+## Step 6: Squash and commit
+
+Pipe the rename plan into `commit-reindex`:
+
+```bash
+echo "$PLAN" | {{dld}} commit-reindex --base "$BASE"
+```
+
+This:
+
+1. Computes the merge-base with `$BASE`.
+2. Mixed-resets HEAD to the merge-base (working tree is preserved — it already holds the post-rename state from step 4).
+3. Restores `INDEX.md` in the working tree to its merge-base state so the working tree is consistent with what we're about to commit. **INDEX.md is intentionally excluded from the reindex commit** — including it would cause a content conflict during rebase whenever the base branch also modified INDEX.md (git's 3-way merge fails to align both sides' top-of-file inserts even when row content overlaps). INDEX.md gets regenerated post-rebase instead.
+4. Stages **only** an explicit path list derived from the original branch diff and the rename plan — the old paths (for deletions), the new paths (for additions), every other file the branch touched. Untracked unrelated paths (e.g. `.claude/worktrees`, scratch files, in-progress edits to unrelated files) are deliberately NOT swept in.
+5. Commits with a templated message that lists the renames in the subject and preserves the original branch commits' subjects in the body.
+
+**Do not use `git add -A` or `git commit -a` anywhere in this flow.** Use only `commit-reindex` to commit. Targeting paths explicitly is the whole point of this step.
+
+## Step 7: Push (if the user chose force-push)
+
+If step 3's answer was "Rewrite and force-push":
+
+```bash
+if git rev-parse --verify --quiet "@{upstream}" >/dev/null; then
+  git push --force-with-lease
+else
+  git push -u origin HEAD
+fi
+```
+
+`--force-with-lease` is mandatory over `--force` here — it refuses to push if the remote moved since the last fetch, which protects against overwriting concurrent collaborator pushes.
+
+## Step 8: Report
+
+Print:
+
+- The renames table.
+- The stderr note from step 2 if `gh` was skipped.
+- The number of commits squashed.
+- The next steps:
+
+> 1. `git rebase $BASE`
+> 2. `{{dld}} regenerate-index` (to repopulate INDEX.md with the renamed locals — the reindex commit intentionally leaves INDEX.md alone to keep the rebase conflict-free; INDEX.md is missing the renamed rows until you regenerate)
+> 3. Commit the INDEX.md update
+
+The skill never rebases or merges — that is always the user's call.
+
+## Out of scope
+
+- **Already-conflicted rebases.** If the user is mid-rebase with conflicts, tell them to `git rebase --abort` first and re-run this skill.
+- **Preserving per-commit granularity.** The squash trades original commit boundaries for a deterministic rewrite. A future `--preserve-history` flag could perform a cherry-pick walk that rewrites each commit individually, but the edge cases (commits modifying an already-renamed file, merge commits, partial reruns) make it materially more complex than the squash.
+- **Cross-namespace ID reconciliation** in namespaced projects. IDs are assumed globally unique across namespaces, matching `next-id`.