diff --git a/.agents/skills/grill-with-docs/SKILL.md b/.agents/skills/grill-with-docs/SKILL.md
index 6dad6ad..5ea0aa9 100644
--- a/.agents/skills/grill-with-docs/SKILL.md
+++ b/.agents/skills/grill-with-docs/SKILL.md
@@ -73,7 +73,7 @@ When the user states how something works, check whether the code agrees. If you
 
 When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
 
-Don't couple `CONTEXT.md` to implementation details. Only include terms that are meaningful to domain experts.
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
 
 ### Offer ADRs sparingly
 
diff --git a/.agents/skills/handoff/SKILL.md b/.agents/skills/handoff/SKILL.md
new file mode 100644
index 0000000..28bfb3a
--- /dev/null
+++ b/.agents/skills/handoff/SKILL.md
@@ -0,0 +1,13 @@
+---
+name: handoff
+description: Compact the current conversation into a handoff document for another agent to pick up.
+argument-hint: "What will the next session be used for?"
+---
+
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save it to a path produced by `mktemp -t handoff-XXXXXX.md` (read the file before you write to it).
+
+Suggest the skills to be used, if any, by the next session.
+
+Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
+
+If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.
diff --git a/.agents/skills/prototype/LOGIC.md b/.agents/skills/prototype/LOGIC.md
new file mode 100644
index 0000000..526ecb1
--- /dev/null
+++ b/.agents/skills/prototype/LOGIC.md
@@ -0,0 +1,79 @@
+# Logic Prototype
+
+A tiny interactive terminal app that lets the user drive a state model by hand. Use this when the question is about **business logic, state transitions, or data shape** — the kind of thing that looks reasonable on paper but only feels wrong once you push it through real cases.
+
+## When this is the right shape
+
+- "I'm not sure if this state machine handles the edge case where X then Y."
+- "Does this data model actually let me represent the case where..."
+- "I want to feel out what the API should look like before writing it."
+- Anything where the user wants to **press buttons and watch state change**.
+
+If the question is "what should this look like" — wrong branch. Use [UI.md](UI.md).
+
+## Process
+
+### 1. State the question
+
+Before writing code, write down what state model and what question you're prototyping. One paragraph, in the prototype's README or a comment at the top of the file. A logic prototype that answers the wrong question is pure waste — make the question explicit so it can be checked later, whether the user is watching now or returning to it AFK.
+
+### 2. Pick the language
+
+Use whatever the host project uses. If the project has no obvious runtime (e.g. a docs repo), ask.
+
+Match the project's existing conventions for tooling — don't add a new package manager or runtime just for the prototype.
+
+### 3. Isolate the logic in a portable module
+
+Put the actual logic — the bit that's answering the question — behind a small, pure interface that could be lifted out and dropped into the real codebase later. The TUI around it is throwaway; the logic module shouldn't be.
+
+The right shape depends on the question:
+
+- **A pure reducer** — `(state, action) => state`. Good when actions are discrete events and state is a single value.
+- **A state machine** — explicit states and transitions. Good when "which actions are even legal right now" is part of the question.
+- **A small set of pure functions** over a plain data type. Good when there's no implicit current state — just transformations.
+- **A class or module with a clear method surface** when the logic genuinely owns ongoing internal state.
+
+Pick whichever shape best fits the question being asked, *not* whichever is easiest to wire to a TUI. Keep it pure: no I/O, no terminal code, no `console.log` for control flow. The TUI imports it and calls into it; nothing flows the other direction.
+
+This is what makes the prototype useful past its own lifetime. When the question's been answered, the validated reducer / machine / function set can be lifted into the real module — the TUI shell gets deleted.
+
+### 4. Build the smallest TUI that exposes the state
+
+Build it as a **lightweight TUI** — on every tick, clear the screen (`console.clear()` / `print("\033[2J\033[H")` / equivalent) and re-render the whole frame. The user should always see one stable view, not an ever-growing scrollback.
+
+Each frame has two parts, in this order:
+
+1. **Current state**, pretty-printed and diff-friendly (one field per line, or formatted JSON). Use **bold** for field names or section headers and **dim** for less important context (timestamps, IDs, derived values). Native ANSI escape codes are fine — `\x1b[1m` bold, `\x1b[2m` dim, `\x1b[0m` reset. No need to pull in a styling library unless one is already in the project.
+2. **Keyboard shortcuts**, listed at the bottom: `[a] add user  [d] delete user  [t] tick clock  [q] quit`. Bold the key, dim the description, or vice-versa — whatever reads cleanly.
+
+Behaviour:
+
+1. **Initialise state** — a single in-memory object/struct. Render the first frame on start.
+2. **Read one keystroke (or one line)** at a time, dispatch to a handler that mutates state.
+3. **Re-render** the full frame after every action — don't append, replace.
+4. **Loop until quit.**
+
+The whole frame should fit on one screen.
+
+### 5. Make it runnable in one command
+
+Add a script to the project's existing task runner (`package.json` scripts, `Makefile`, `justfile`, `pyproject.toml`). The user should run `pnpm run <prototype-name>` or equivalent — never need to remember a path.
+
+If the host project has no task runner, just put the command at the top of the prototype's README.
+
+### 6. Hand it over
+
+Give the user the run command. They'll drive it themselves; the interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" — those are the bugs in the _idea_, which is the whole point. If they want new actions added, add them. Prototypes evolve.
+
+### 7. Capture the answer
+
+When the prototype has done its job, the answer to the question is the only thing worth keeping. If the user is around, ask what it taught them. If not, leave a `NOTES.md` next to the prototype so the answer can be filled in (or filled in by you, if you've watched the session) before the prototype gets deleted.
+
+## Anti-patterns
+
+- **Don't add tests.** A prototype that needs tests is no longer a prototype.
+- **Don't wire it to the real database.** Use an in-memory store unless the question is specifically about persistence.
+- **Don't generalise.** No "what if we wanted to support X later." The prototype answers one question.
+- **Don't blur the logic and the TUI together.** If the reducer / state machine references `console.log`, prompts, or terminal escape codes, it's no longer portable. Keep the TUI as a thin shell over a pure module.
+- **Don't ship the TUI shell into production.** The shell is optimised for being driven by hand from a terminal. The logic module behind it is the bit worth keeping.
diff --git a/.agents/skills/prototype/SKILL.md b/.agents/skills/prototype/SKILL.md
new file mode 100644
index 0000000..64f3e61
--- /dev/null
+++ b/.agents/skills/prototype/SKILL.md
@@ -0,0 +1,30 @@
+---
+name: prototype
+description: Build a throwaway prototype to flesh out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
+---
+
+# Prototype
+
+A prototype is **throwaway code that answers a question**. The question decides the shape.
+
+## Pick a branch
+
+Identify which question is being answered — from the user's prompt, the surrounding code, or by asking if the user is around:
+
+- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper.
+- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
+
+The two branches produce very different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
+
+## Rules that apply to both
+
+1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
+2. **One command to run.** Whatever the project's existing task runner supports — `pnpm <name>`, `python <path>`, `bun <path>`, etc. The user must be able to start it without thinking.
+3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is _checking_, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
+4. **Skip the polish.** No tests, no error handling beyond what makes the prototype _runnable_, no abstractions. The point is to learn something fast and then delete it.
+5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
+6. **Delete or absorb when done.** When the prototype has answered its question, either delete it or fold the validated decision into the real code — don't leave it rotting in the repo.
+
+## When done
+
+The _answer_ is the only thing worth keeping from a prototype. Capture it somewhere durable (commit message, ADR, issue, or a `NOTES.md` next to the prototype) along with the question it was answering. If the user is around, that capture is a quick conversation; if not, leave the placeholder so they (or you, on the next pass) can fill in the verdict before deleting the prototype.
diff --git a/.agents/skills/prototype/UI.md b/.agents/skills/prototype/UI.md
new file mode 100644
index 0000000..f3b6e64
--- /dev/null
+++ b/.agents/skills/prototype/UI.md
@@ -0,0 +1,112 @@
+# UI Prototype
+
+Generate **several radically different UI variations** on a single route, switchable from a floating bottom bar. The user flips between variants in the browser, picks one (or steals bits from each), then throws the rest away.
+
+If the question is about logic/state rather than what something looks like — wrong branch. Use [LOGIC.md](LOGIC.md).
+
+## When this is the right shape
+
+- "What should this page look like?"
+- "I want to see a few options for this dashboard before committing."
+- "Try a different layout for the settings screen."
+- Any time the user would otherwise spend a day picking between three vague mockups in their head.
+
+## Two sub-shapes — strongly prefer sub-shape A
+
+A UI prototype is much easier to judge when it's **butting up against the rest of the app** — real header, real sidebar, real data, real density. A throwaway route on its own is a vacuum: every variant looks fine in isolation. Default to sub-shape A whenever there's a plausible existing page to host the variants. Only reach for sub-shape B if the prototype genuinely has no nearby home.
+
+### Sub-shape A — adjustment to an existing page (preferred)
+
+The route already exists. Variants are rendered **on the same route**, gated by a `?variant=` URL search param. The existing data fetching, params, and auth all stay — only the rendering swaps. This is the default; pick it unless there's a specific reason not to.
+
+If the prototype is for something that doesn't yet have a page but *would naturally live inside one* (a new section of the dashboard, a new card on the settings screen, a new step in an existing flow) — that's still sub-shape A. Mount the variants inside the host page.
+
+### Sub-shape B — a new page (last resort)
+
+Only use this when the thing being prototyped genuinely has no existing page to live inside — e.g. an entirely new top-level surface, or a flow that can't be embedded anywhere sensible.
+
+Create a **throwaway route** following whatever routing convention the project already uses — don't invent a new top-level structure. Name it so it's obviously a prototype (e.g. include the word `prototype` in the path or filename). Same `?variant=` pattern.
+
+Before committing to sub-shape B, sanity-check: is there really no existing page this could be embedded in? An empty route hides design problems that a populated one would expose.
+
+In both sub-shapes the floating bottom bar is identical.
+
+## Process
+
+### 1. State the question and pick N
+
+Default to **3 variants**. More than 5 stops being radically different and starts being noise — cap there.
+
+Write down the plan in one line, in the prototype's location or a top-of-file comment:
+
+> "Three variants of the settings page, switchable via `?variant=`, on the existing `/settings` route."
+
+This works whether the user is here to push back or not.
+
+### 2. Generate radically different variants
+
+Draft each variant. Hold each one to:
+
+- The page's purpose and the data it has access to.
+- The project's component library / styling system (TailwindCSS, shadcn, MUI, plain CSS, whatever).
+- A clear exported component name, e.g. `VariantA`, `VariantB`, `VariantC`.
+
+Variants must be **structurally different** — different layout, different information hierarchy, different primary affordance, not just different colours. Three slightly-tweaked card grids isn't a UI prototype, it's wallpaper. If two drafts come out too similar, redo one with explicit "do not use a card grid" guidance.
+
+### 3. Wire them together
+
+Create a single switcher component on the route:
+
+```tsx
+// pseudo-code — adapt to the project's framework
+const variant = searchParams.get('variant') ?? 'A';
+return (
+  <>
+    {variant === 'A' && <VariantA {...data} />}
+    {variant === 'B' && <VariantB {...data} />}
+    {variant === 'C' && <VariantC {...data} />}
+    <PrototypeSwitcher variants={['A','B','C']} current={variant} />
+  </>
+);
+```
+
+For sub-shape A (existing page): keep all the existing data fetching above the switcher; only the rendered subtree changes per variant.
+
+For sub-shape B (new page): the throwaway route under `/prototype/<name>` mounts the same switcher.
+
+### 4. Build the floating switcher
+
+A small fixed-position bar at the bottom-centre of the screen with three pieces:
+
+- **Left arrow** — cycles to the previous variant (wraps around).
+- **Variant label** — shows the current variant key and, if the variant exports a name, that name too. e.g. `B — Sidebar layout`.
+- **Right arrow** — cycles forward (wraps around).
+
+Behaviour:
+
+- Clicking an arrow updates the URL search param (use the framework's router — `router.replace` on Next, `navigate` on React Router, etc) so the variant is shareable and reload-stable.
+- Keyboard: `←` and `→` arrow keys also cycle. Don't intercept arrow keys when an `<input>`, `<textarea>`, or `[contenteditable]` is focused.
+- Visually distinct from the page (e.g. high-contrast pill, subtle shadow) so it's obviously not part of the design being evaluated.
+- Hidden in production builds — gate on `process.env.NODE_ENV !== 'production'` or an equivalent check, so a stray prototype merge can't ship the bar to users.
+
+Put the switcher in a single shared component so both sub-shapes can reuse it. Locate it wherever shared UI lives in the project.
+
+### 5. Hand it over
+
+Surface the URL (and the `?variant=` keys). The user will flip through whenever they get to it. The interesting feedback is usually **"I want the header from B with the sidebar from C"** — that's the actual design they want.
+
+### 6. Capture the answer and clean up
+
+Once a variant has won, write down which one and why (commit message, ADR, issue, or a `NOTES.md` next to the prototype if running AFK and the user hasn't responded yet). Then:
+
+- **Sub-shape A** — delete the losing variants and the switcher; fold the winner into the existing page.
+- **Sub-shape B** — promote the winning variant to a real route, delete the throwaway route and the switcher.
+
+Don't leave variant components or the switcher lying around. They rot fast and confuse the next reader.
+
+## Anti-patterns
+
+- **Variants that differ only in colour or copy.** That's a tweak, not a prototype. Real variants disagree about structure.
+- **Sharing too much code between variants.** A shared `<Header>` is fine; a shared `<Layout>` defeats the point. Each variant should be free to throw out the layout.
+- **Wiring variants to real mutations.** Read-only prototypes are fine. If a variant needs to mutate, point it at a stub — the question is "what should this look like", not "does the backend work".
+- **Promoting the prototype directly to production.** The variant code was written under prototype constraints (no tests, minimal error handling). Rewrite it properly when you fold it in.
diff --git a/.agents/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md b/.agents/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md
index 1993c58..f54da95 100644
--- a/.agents/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md
+++ b/.agents/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md
@@ -6,7 +6,7 @@ Issues and PRDs for this repo live as GitLab issues. Use the [`glab`](https://gi
 
 - **Create an issue**: `glab issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions. Pass `--description -` to open an editor.
 - **Read an issue**: `glab issue view <number> --comments`. Use `-F json` for machine-readable output.
-- **List issues**: `glab issue list --state opened -F json` with appropriate `--label` filters. Note that GitLab uses `opened` (not `open`) for the state value.
+- **List issues**: `glab issue list -F json` with appropriate `--label` filters.
 - **Comment on an issue**: `glab issue note <number> --message "..."`. GitLab calls comments "notes".
 - **Apply / remove labels**: `glab issue update <number> --label "..."` / `--unlabel "..."`. Multiple labels can be comma-separated or by repeating the flag.
 - **Close**: `glab issue close <number>`. `glab issue close` does not accept a closing comment, so post the explanation first with `glab issue note <number> --message "..."`, then close.
diff --git a/.agents/skills/to-issues/SKILL.md b/.agents/skills/to-issues/SKILL.md
index 5a40716..9f6efbf 100644
--- a/.agents/skills/to-issues/SKILL.md
+++ b/.agents/skills/to-issues/SKILL.md
@@ -51,7 +51,7 @@ Iterate until the user approves the breakdown.
 
 ### 5. Publish the issues to the issue tracker
 
-For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. Apply the `needs-triage` triage label so each issue enters the normal triage flow.
+For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise.
 
 Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
 
@@ -64,6 +64,8 @@ A reference to the parent issue on the issue tracker (if the source was an exist
 
 A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
 
+Avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+
 ## Acceptance criteria
 
 - [ ] Criterion 1
diff --git a/.agents/skills/to-prd/SKILL.md b/.agents/skills/to-prd/SKILL.md
index 7bdc82a..47a01d4 100644
--- a/.agents/skills/to-prd/SKILL.md
+++ b/.agents/skills/to-prd/SKILL.md
@@ -17,7 +17,7 @@ A deep module (as opposed to a shallow module) is one which encapsulates a lot o
 
 Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
 
-3. Write the PRD using the template below, then publish it to the project issue tracker. Apply the `needs-triage` triage label so it enters the normal triage flow.
+3. Write the PRD using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.
 
 <prd-template>
 
@@ -55,6 +55,8 @@ A list of implementation decisions that were made. This can include:
 
 Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
 
+Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
+
 ## Testing Decisions
 
 A list of testing decisions that were made. Include:
diff --git a/.claude/skills/handoff b/.claude/skills/handoff
new file mode 120000
index 0000000..a34a6b2
--- /dev/null
+++ b/.claude/skills/handoff
@@ -0,0 +1 @@
+../../.agents/skills/handoff
\ No newline at end of file
diff --git a/.claude/skills/prototype b/.claude/skills/prototype
new file mode 120000
index 0000000..bc911dd
--- /dev/null
+++ b/.claude/skills/prototype
@@ -0,0 +1 @@
+../../.agents/skills/prototype
\ No newline at end of file
diff --git a/apps/claude-code/pr-review/.claude-plugin/marketplace.json b/apps/claude-code/pr-review/.claude-plugin/marketplace.json
index 53d4d3f..cb21f64 100644
--- a/apps/claude-code/pr-review/.claude-plugin/marketplace.json
+++ b/apps/claude-code/pr-review/.claude-plugin/marketplace.json
@@ -21,7 +21,7 @@
       "name": "pr-review",
       "source": "./",
       "tags": ["code-quality", "azure-devops"],
-      "version": "1.2.10"
+      "version": "1.2.11"
     }
   ]
 }
diff --git a/apps/claude-code/pr-review/.claude-plugin/plugin.json b/apps/claude-code/pr-review/.claude-plugin/plugin.json
index 989cb7b..a5733bd 100644
--- a/apps/claude-code/pr-review/.claude-plugin/plugin.json
+++ b/apps/claude-code/pr-review/.claude-plugin/plugin.json
@@ -1,6 +1,6 @@
 {
   "name": "pr-review",
-  "version": "1.2.10",
+  "version": "1.2.11",
   "description": "Review Azure DevOps pull requests with multi-agent analysis and post threaded comments back to the PR.",
   "author": {
     "name": "Unic AG",
diff --git a/apps/claude-code/pr-review/.gitignore b/apps/claude-code/pr-review/.gitignore
index db859c9..78f10aa 100644
--- a/apps/claude-code/pr-review/.gitignore
+++ b/apps/claude-code/pr-review/.gitignore
@@ -6,7 +6,7 @@ pnpm-debug.log*
 
 # Ralph
 .ralph/
-.agents/scratchpad/
+agents/scratchpad/
 
 # Visual Studio Code
 .vscode/*
diff --git a/apps/claude-code/pr-review/CHANGELOG.md b/apps/claude-code/pr-review/CHANGELOG.md
index 8188eff..ba6e3a5 100644
--- a/apps/claude-code/pr-review/CHANGELOG.md
+++ b/apps/claude-code/pr-review/CHANGELOG.md
@@ -11,6 +11,20 @@
 ### Fixed
 - (none)
 
+## [1.2.11] — 2026-05-19
+
+### Breaking
+- (none)
+
+### Added
+- (none)
+
+### Changed
+- (none)
+
+### Fixed
+- Renamed `agents/` directory (was `.agents/`) so Claude Code's agent auto-discovery can find plugin agents. Added `name:` frontmatter field to all five agent files to match the working convention used by `pr-review-toolkit`.
+
 ## [1.2.10] — 2026-05-14
 
 ### Breaking
diff --git a/apps/claude-code/pr-review/CLAUDE.md b/apps/claude-code/pr-review/CLAUDE.md
index 794f9c6..0554a83 100644
--- a/apps/claude-code/pr-review/CLAUDE.md
+++ b/apps/claude-code/pr-review/CLAUDE.md
@@ -19,7 +19,7 @@ A Claude Code plugin (`pr-review`) that adds a `/pr-review:review-pr` command. W
   marketplace.json     # Marketplace listing metadata
 commands/
   review-pr.md        # The slash command definition — thin orchestrator
-.agents/
+agents/
   ado-fetcher.md          # ADO Fetcher — all Azure DevOps REST API fetches
   re-review-coordinator.md # Re-review Coordinator — thread classification + incremental diff
   ado-writer.md           # ADO Writer — posts inline threads and summary comment to ADO
@@ -27,7 +27,7 @@ commands/
   doc-context-synthesizer.md   # Doc Context Synthesizer — produces business-context narrative
 ```
 
-`commands/review-pr.md` is a thin orchestrator (≤ 200 lines per PRD acceptance criterion). It delegates ADO API calls and coordination logic to the focused agents in `.agents/`. Pure helpers used by both the orchestrator and the agents live under `scripts/` (`ado-fetcher.mjs`, `ado-writer.mjs`, `pre-pr.mjs`, `mode-detection.mjs`, `confluence-client.mjs`, `re-review/*.mjs`) with tests under `tests/`. There are no build steps, no transpilation, no dependencies to install.
+`commands/review-pr.md` is a thin orchestrator (≤ 200 lines per PRD acceptance criterion). It delegates ADO API calls and coordination logic to the focused agents in `agents/`. Pure helpers used by both the orchestrator and the agents live under `scripts/` (`ado-fetcher.mjs`, `ado-writer.mjs`, `pre-pr.mjs`, `mode-detection.mjs`, `confluence-client.mjs`, `re-review/*.mjs`) with tests under `tests/`. There are no build steps, no transpilation, no dependencies to install.
 
 ## Plugin metadata
 
@@ -41,7 +41,7 @@ When bumping the version, update it in **both** files:
 - YAML frontmatter declares `allowed-tools` — add any new tools the command needs there
 - Auto-generated files are skipped during file-content reading by the `shouldSkipFile` helper in `scripts/pre-pr.mjs` (serialization YAMLs, `*.g.cs`, generated types output, `swagger.md`)
 - All comments posted to ADO **must** end with the exact signature: `---\n🤖 *Reviewed by Claude Code* — Iteration N` (where N = LATEST_ITERATION_ID)
-- ADO REST calls (`pullRequestThreads`, thread replies, iteration fetches) are handled by the focused agents in `.agents/`, not inline in the orchestrator command
+- ADO REST calls (`pullRequestThreads`, thread replies, iteration fetches) are handled by the focused agents in `agents/`, not inline in the orchestrator command
 - ADO Fetcher (`ado-fetcher.md`) owns all read operations; ADO Writer (`ado-writer.md`) owns all write operations; Re-review Coordinator (`re-review-coordinator.md`) owns thread classification and incremental diff logic
 - Inline threads use ADO REST `pullRequestThreads` via `az devops invoke`; file paths must match ADO format (leading `/`, forward slashes)
 - Always use the latest iteration of the PR. `iterationId=1` is never used. Re-reviews additionally compute `PRIOR_ITERATION_ID` from the prior review's signature — see spec 02.
diff --git a/apps/claude-code/pr-review/.agents/ado-fetcher.md b/apps/claude-code/pr-review/agents/ado-fetcher.md
similarity index 99%
rename from apps/claude-code/pr-review/.agents/ado-fetcher.md
rename to apps/claude-code/pr-review/agents/ado-fetcher.md
index d8321b5..291344c 100644
--- a/apps/claude-code/pr-review/.agents/ado-fetcher.md
+++ b/apps/claude-code/pr-review/agents/ado-fetcher.md
@@ -1,4 +1,5 @@
 ---
+name: ado-fetcher
 allowed-tools: ['Bash']
 description: 'Fetch all Azure DevOps read data required for a PR review: PR metadata, latest iteration, changed files, raw diff, and linked work-item IDs. Read-only — no write operations.'
 ---
diff --git a/apps/claude-code/pr-review/.agents/ado-writer.md b/apps/claude-code/pr-review/agents/ado-writer.md
similarity index 99%
rename from apps/claude-code/pr-review/.agents/ado-writer.md
rename to apps/claude-code/pr-review/agents/ado-writer.md
index b727ca3..d454c53 100644
--- a/apps/claude-code/pr-review/.agents/ado-writer.md
+++ b/apps/claude-code/pr-review/agents/ado-writer.md
@@ -1,4 +1,5 @@
 ---
+name: ado-writer
 allowed-tools: ['Bash']
 description: 'Post all Azure DevOps write-back operations for a PR review: inline comment threads per finding, Review Summary or delta reply, and completion marker. Write-only — no read operations.'
 ---
diff --git a/apps/claude-code/pr-review/.agents/doc-context-orchestrator.md b/apps/claude-code/pr-review/agents/doc-context-orchestrator.md
similarity index 99%
rename from apps/claude-code/pr-review/.agents/doc-context-orchestrator.md
rename to apps/claude-code/pr-review/agents/doc-context-orchestrator.md
index b91ae36..8aca6f9 100644
--- a/apps/claude-code/pr-review/.agents/doc-context-orchestrator.md
+++ b/apps/claude-code/pr-review/agents/doc-context-orchestrator.md
@@ -1,4 +1,5 @@
 ---
+name: doc-context-orchestrator
 allowed-tools: ['Agent', 'Bash']
 description: 'Orchestrate Doc Context gathering: fetch work item details, run Confluence credential check once, spawn Work Item Summarizer and Confluence Fetcher agents in parallel, and delegate synthesis to the Doc Context Synthesizer.'
 ---
diff --git a/apps/claude-code/pr-review/.agents/doc-context-synthesizer.md b/apps/claude-code/pr-review/agents/doc-context-synthesizer.md
similarity index 98%
rename from apps/claude-code/pr-review/.agents/doc-context-synthesizer.md
rename to apps/claude-code/pr-review/agents/doc-context-synthesizer.md
index f0b2bb8..5fea527 100644
--- a/apps/claude-code/pr-review/.agents/doc-context-synthesizer.md
+++ b/apps/claude-code/pr-review/agents/doc-context-synthesizer.md
@@ -1,4 +1,5 @@
 ---
+name: doc-context-synthesizer
 allowed-tools: []
 description: 'Synthesise work item summaries and Confluence page summaries into a single flat Doc Context narrative for injection into PR review agent prompts.'
 ---
diff --git a/apps/claude-code/pr-review/.agents/re-review-coordinator.md b/apps/claude-code/pr-review/agents/re-review-coordinator.md
similarity index 99%
rename from apps/claude-code/pr-review/.agents/re-review-coordinator.md
rename to apps/claude-code/pr-review/agents/re-review-coordinator.md
index 947fe4b..8b3d8d7 100644
--- a/apps/claude-code/pr-review/.agents/re-review-coordinator.md
+++ b/apps/claude-code/pr-review/agents/re-review-coordinator.md
@@ -1,4 +1,5 @@
 ---
+name: re-review-coordinator
 allowed-tools: ['Bash']
 description: 'Own the full re-review state machine: prior-thread detection, partial-run check, thread classification, finding matching, and reply posting to classified threads. Returns classification counts, fresh findings, and an earlyExit flag.'
 ---
diff --git a/apps/claude-code/pr-review/docs/adr/0013-orchestrator-split-for-review-pr.md b/apps/claude-code/pr-review/docs/adr/0013-orchestrator-split-for-review-pr.md
index b50287e..0120b7d 100644
--- a/apps/claude-code/pr-review/docs/adr/0013-orchestrator-split-for-review-pr.md
+++ b/apps/claude-code/pr-review/docs/adr/0013-orchestrator-split-for-review-pr.md
@@ -22,7 +22,7 @@ Refactor `review-pr.md` into a **thin orchestrator** of ~200 lines that:
 2. Detects the operating mode: **pre-PR**, **first-review**, or **re-review**.
 3. Delegates immediately to a focused agent per mode.
 
-Three focused agents live in the plugin's `.agents/` directory (not in `pr-review-toolkit`, which is a read-only dependency):
+Three focused agents live in the plugin's `agents/` directory (not in `pr-review-toolkit`, which is a read-only dependency):
 
 - **`pr-review:ado-fetcher`** — fetches PR metadata, iterations, changed files, and raw diff from ADO. Used by first-review and re-review modes.
 - **`pr-review:re-review-coordinator`** — owns prior thread detection, partial-run check, thread classification, finding matching, and reply posting to classified threads. Used only in re-review mode.
diff --git a/apps/claude-code/pr-review/package.json b/apps/claude-code/pr-review/package.json
index 58e45e1..45841e7 100644
--- a/apps/claude-code/pr-review/package.json
+++ b/apps/claude-code/pr-review/package.json
@@ -10,7 +10,7 @@
     "pnpm": ">=10"
   },
   "scripts": {
-    "test": "node --test tests/parse-signature.test.mjs tests/classify-thread.test.mjs tests/match-finding.test.mjs tests/detect-prior-review.test.mjs tests/confluence-client.test.mjs tests/ado-fetcher.test.mjs tests/ado-writer.test.mjs tests/pre-pr.test.mjs tests/parse-diff-hunks.test.mjs tests/mode-detection.test.mjs tests/notices.test.mjs tests/classify-http-error.test.mjs tests/fetch-work-items.test.mjs tests/fetch-iterations.test.mjs tests/parse-write-response.test.mjs tests/detect-default-branch.test.mjs",
+    "test": "node --test tests/parse-signature.test.mjs tests/classify-thread.test.mjs tests/match-finding.test.mjs tests/detect-prior-review.test.mjs tests/confluence-client.test.mjs tests/ado-fetcher.test.mjs tests/ado-writer.test.mjs tests/pre-pr.test.mjs tests/parse-diff-hunks.test.mjs tests/mode-detection.test.mjs tests/notices.test.mjs tests/classify-http-error.test.mjs tests/fetch-work-items.test.mjs tests/fetch-iterations.test.mjs tests/parse-write-response.test.mjs tests/detect-default-branch.test.mjs tests/plugin-structure.test.mjs",
     "bump": "unic-bump",
     "sync-version": "unic-sync-version",
     "tag": "unic-tag",
diff --git a/apps/claude-code/pr-review/tests/ado-fetcher.test.mjs b/apps/claude-code/pr-review/tests/ado-fetcher.test.mjs
index aeeb769..986f303 100644
--- a/apps/claude-code/pr-review/tests/ado-fetcher.test.mjs
+++ b/apps/claude-code/pr-review/tests/ado-fetcher.test.mjs
@@ -5,7 +5,7 @@ import { readFileSync } from 'node:fs'
 import { describe, it } from 'node:test'
 
 /** Reads the ado-fetcher agent markdown for content assertions */
-const agentContent = readFileSync(new URL('../.agents/ado-fetcher.md', import.meta.url), 'utf8')
+const agentContent = readFileSync(new URL('../agents/ado-fetcher.md', import.meta.url), 'utf8')
 
 describe('ado-fetcher agent content', () => {
 	it('contains no ADO write HTTP methods (POST/PATCH/DELETE)', () => {
diff --git a/apps/claude-code/pr-review/tests/ado-writer.test.mjs b/apps/claude-code/pr-review/tests/ado-writer.test.mjs
index 8154091..b4217dd 100644
--- a/apps/claude-code/pr-review/tests/ado-writer.test.mjs
+++ b/apps/claude-code/pr-review/tests/ado-writer.test.mjs
@@ -6,7 +6,7 @@ import { describe, it } from 'node:test'
 import { parseAdoWriterResult } from '../scripts/ado-writer.mjs'
 
 /** Reads the ado-writer agent markdown for content assertions */
-const agentContent = readFileSync(new URL('../.agents/ado-writer.md', import.meta.url), 'utf8')
+const agentContent = readFileSync(new URL('../agents/ado-writer.md', import.meta.url), 'utf8')
 
 describe('ado-writer agent content', () => {
 	it('declares allowed-tools in frontmatter', () => {
diff --git a/apps/claude-code/pr-review/tests/notices.test.mjs b/apps/claude-code/pr-review/tests/notices.test.mjs
index 805ff77..299878c 100644
--- a/apps/claude-code/pr-review/tests/notices.test.mjs
+++ b/apps/claude-code/pr-review/tests/notices.test.mjs
@@ -131,7 +131,7 @@ describe('formatTrailer', () => {
 describe('mergeNotices', () => {
 	it('mergeNotices tolerates null and undefined sources', () => {
 		const n = createNotice('info', 'doc-context', 'test')
-		// @ts-ignore — intentional test of runtime tolerance for null/undefined
+		// @ts-expect-error — intentional test of runtime tolerance for null/undefined
 		const result = mergeNotices(null, [n], undefined)
 		assert.equal(result.length, 1)
 		assert.equal(result[0].kind, 'doc-context')
diff --git a/apps/claude-code/pr-review/tests/plugin-structure.test.mjs b/apps/claude-code/pr-review/tests/plugin-structure.test.mjs
new file mode 100644
index 0000000..e08f605
--- /dev/null
+++ b/apps/claude-code/pr-review/tests/plugin-structure.test.mjs
@@ -0,0 +1,54 @@
+// @ts-check
+
+import assert from 'node:assert/strict'
+import { existsSync, readdirSync, readFileSync } from 'node:fs'
+import { join, resolve } from 'node:path'
+import { describe, it } from 'node:test'
+import { fileURLToPath } from 'node:url'
+
+const PLUGIN_ROOT = resolve(fileURLToPath(import.meta.url), '..', '..')
+const AGENTS_DIR = join(PLUGIN_ROOT, 'agents')
+const HIDDEN_AGENTS_DIR = join(PLUGIN_ROOT, '.agents')
+
+const EXPECTED_AGENTS = [
+	'ado-fetcher',
+	'ado-writer',
+	're-review-coordinator',
+	'doc-context-orchestrator',
+	'doc-context-synthesizer',
+]
+
+describe('plugin structure', () => {
+	it('agents/ directory exists', () => {
+		assert.ok(existsSync(AGENTS_DIR), `expected agents/ directory at ${AGENTS_DIR}`)
+	})
+
+	it('.agents/ hidden directory does not exist', () => {
+		assert.ok(
+			!existsSync(HIDDEN_AGENTS_DIR),
+			`.agents/ must be renamed to agents/ — found stale dir at ${HIDDEN_AGENTS_DIR}`
+		)
+	})
+
+	it('all expected agent files are present in agents/', () => {
+		const files = readdirSync(AGENTS_DIR)
+			.filter((f) => f.endsWith('.md'))
+			.map((f) => f.replace(/\.md$/, ''))
+		for (const agent of EXPECTED_AGENTS) {
+			assert.ok(files.includes(agent), `missing agent file: agents/${agent}.md`)
+		}
+	})
+
+	it('each agent file has a name: field in frontmatter matching its filename stem', () => {
+		for (const agent of EXPECTED_AGENTS) {
+			const content = readFileSync(join(AGENTS_DIR, `${agent}.md`), 'utf8')
+			const match = content.match(/^---\n([\s\S]*?)\n---/)
+			assert.ok(match, `${agent}.md: missing YAML frontmatter`)
+			const frontmatter = match[1]
+			assert.ok(
+				new RegExp(`^name: ${agent}$`, 'm').test(frontmatter),
+				`${agent}.md: frontmatter missing exact line "name: ${agent}"`
+			)
+		}
+	})
+})
diff --git a/docs/issues/pr-review-agents-not-discovered/01-rename-agents-dir-and-fix-frontmatter.md b/docs/issues/pr-review-agents-not-discovered/01-rename-agents-dir-and-fix-frontmatter.md
new file mode 100644
index 0000000..a35c0e1
--- /dev/null
+++ b/docs/issues/pr-review-agents-not-discovered/01-rename-agents-dir-and-fix-frontmatter.md
@@ -0,0 +1,66 @@
+---
+title: 'pr-review: rename .agents/ → agents/ and add name: field to agent frontmatter'
+created: 2026-05-19
+---
+
+**Status:** resolved
+**Category:** bug
+**Plugin:** `apps/claude-code/pr-review`
+**Depends on:** —
+
+## Problem Statement
+
+`pr-review:ado-fetcher` (and all other `pr-review` plugin agents) fail at runtime with:
+
+```
+Error: Agent type 'pr-review:ado-fetcher' not found.
+```
+
+**Root cause:** Claude Code's agent discovery scans an `agents/` directory inside each plugin. The `pr-review` plugin stores its agent files in `.agents/` (dot-prefixed, hidden on Unix), which is never scanned. The `pr-review-toolkit` plugin — which works correctly — uses `agents/` (no dot).
+
+**Secondary issue:** The `pr-review-toolkit` agent files declare a `name:` field in their YAML frontmatter (e.g. `name: code-reviewer`). The `pr-review` agent files only have `allowed-tools` and `description`. Whether the missing `name:` field is independently load-bearing is uncertain; it is added here defensively to match the working convention.
+
+**Evidence:**
+
+- Working: `~/.claude/plugins/cache/claude-plugins-official/pr-review-toolkit/unknown/agents/code-reviewer.md`
+- Broken: `~/.claude/plugins/cache/unic-agent-plugins/pr-review/1.2.10/.agents/ado-fetcher.md`
+
+## Affected files
+
+| File                                                                           | Change                                                                                      |
+| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
+| `apps/claude-code/pr-review/.agents/` (directory)                              | Rename to `agents/`                                                                         |
+| `apps/claude-code/pr-review/.agents/ado-fetcher.md`                            | Add `name: ado-fetcher` to frontmatter                                                      |
+| `apps/claude-code/pr-review/.agents/ado-writer.md`                             | Add `name: ado-writer` to frontmatter                                                       |
+| `apps/claude-code/pr-review/.agents/re-review-coordinator.md`                  | Add `name: re-review-coordinator` to frontmatter                                            |
+| `apps/claude-code/pr-review/.agents/doc-context-orchestrator.md`               | Add `name: doc-context-orchestrator` to frontmatter                                         |
+| `apps/claude-code/pr-review/.agents/doc-context-synthesizer.md`                | Add `name: doc-context-synthesizer` to frontmatter                                          |
+| `apps/claude-code/pr-review/CLAUDE.md`                                         | Update repository layout section: `.agents/` → `agents/`                                    |
+| `apps/claude-code/pr-review/docs/adr/0013-orchestrator-split-for-review-pr.md` | Amend in place: fix `.agents/` → `agents/` in the "Three focused agents live in…" paragraph |
+| `CHANGELOG.md`                                                                 | Add patch entry                                                                             |
+| `.claude-plugin/plugin.json` + `marketplace.json`                              | Bump patch version                                                                          |
+
+Do **not** update historical plan files (`docs/plans/`) — those are already-executed specs and are left as written.
+
+## Implementation steps
+
+1. Rename the directory: `git mv apps/claude-code/pr-review/.agents apps/claude-code/pr-review/agents`
+2. Add `name: <slug>` as the first frontmatter key in each of the five agent files (use the filename stem as the value, e.g. `name: ado-fetcher`).
+3. Update the repository layout table in `CLAUDE.md`: change `.agents/` → `agents/` in the directory tree and in any prose that names the directory.
+4. Amend ADR 0013 in place: change the one occurrence of `the plugin's \`.agents/\` directory`to`the plugin's \`agents/\` directory`. No status or consequence lines need changing.
+5. Add a `CHANGELOG.md` entry and bump the patch version in `plugin.json` + `marketplace.json`.
+
+## Verification
+
+After implementing, verify the fix end-to-end:
+
+1. **Cache invalidation check** — it is unknown whether the directory-source marketplace re-reads from the repo live or serves from the `~/.claude/plugins/cache/` snapshot. After renaming, check whether `~/.claude/plugins/cache/unic-agent-plugins/pr-review/<version>/.agents/` still exists. If it does, manually remove it (or delete and re-add the `pr-review@unic` entry in `enabledPlugins`) to force a fresh cache read.
+2. **Agent discovery** — restart Claude Code and confirm `pr-review:ado-fetcher` appears in the available agent list (the list shown in the error message is a reliable source of truth).
+3. **End-to-end smoke test** — run `/pr-review:review-pr` against a real ADO PR URL and confirm the ADO Fetcher agent launches without the "not found" error.
+
+## Acceptance criteria
+
+- `pr-review:ado-fetcher`, `pr-review:ado-writer`, `pr-review:re-review-coordinator`, `pr-review:doc-context-orchestrator`, and `pr-review:doc-context-synthesizer` all appear in Claude Code's available agent list after the rename.
+- Running `/pr-review:review-pr <ADO-PR-URL>` reaches at least Step 5 (ADO Fetcher launch) without an "Agent type not found" error.
+- No references to `.agents/` remain in `CLAUDE.md` or `docs/adr/0013-*`.
+- ADR 0013 retains its original status and all consequence lines; only the directory name is corrected.
diff --git a/docs/issues/unic-archon-dlc/01-plugin-scaffold-and-tracer-install.md b/docs/issues/unic-archon-dlc/01-plugin-scaffold-and-tracer-install.md
new file mode 100644
index 0000000..2c2a3b4
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/01-plugin-scaffold-and-tracer-install.md
@@ -0,0 +1,45 @@
+# Plugin scaffold and tracer install hook
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+Scaffold the `unic-archon-dlc` plugin at `apps/claude-code/unic-archon-dlc/` with a working install hook that runs end-to-end from `claude /plugin install` and proves the wiring. This is the tracer slice: minimal but complete path through manifest → install hook → on-disk artifacts.
+
+In scope:
+
+- Plugin directory under `apps/claude-code/unic-archon-dlc/` following the same shape as `auto-format`, `pr-review`, `unic-confluence`.
+- Manifests: `.claude-plugin/plugin.json` and `.claude-plugin/marketplace.json`. Plugin name is `unic-archon-dlc`. Marketplace entry follows the monorepo convention (no hand edits; subsequent slices use `pnpm --filter ... bump`).
+- `.archon/workflows/` and `.archon/commands/` directories shipped inside the plugin (empty placeholders accepted — populated by later slices).
+- Install hook as an idempotent Node.js script (`.mjs`, ESM, zero external runtime deps) triggered by the Claude Code plugin install mechanism.
+- **Setup explorer** module: reads `git remote`, `CLAUDE.md`, `CONTEXT.md`, `CONTEXT-MAP.md`, `docs/adr/`, existing `.archon/` and returns a structured snapshot of what is already configured. Missing files are reported as absent, not errored.
+- **Archon binary check**: install hook verifies `archon` is on `PATH`. If missing, exits with a clear error referencing the README dependency note. Also reads `archon --version` and warns if the version is on the known-incompatible list (start with an empty list shipped as a JSON constant — populated as drift is observed).
+- **Mandatory question tier only** in this slice: issue tracker (auto-detected from `git remote`; falls back to a prompt), PR strategy (deduced from tracker), branching strategy (Gitflow default, GitHub Flow alternative).
+- Already-configured values are shown back to the user and skippable — re-running the hook never overwrites without consent.
+- **Outputs:**
+  - `.archon/unic-dlc.config.json` (machine-readable) populated with the mandatory tier only.
+  - `docs/agents/issue-tracker.md` (human-readable) describing the chosen tracker, its CLI, and the create/update conventions.
+- Config loader/validator module: `loadConfig(path)` returns a typed config object or a structured error. Mandatory fields validated; unknown keys ignored.
+- Tests (`node:test`, `.mjs`) for config loader (valid parse, missing mandatory fields, unknown keys) and setup explorer (mock project directory snapshot, absent-vs-errored handling).
+
+Out of scope for this slice: label tiers (state/type/priority), e2e command prompt, multi-context detection, remaining `docs/agents/*` files, `CLAUDE.md` block, any workflow YAML or command file contents.
+
+## Acceptance criteria
+
+- [ ] `apps/claude-code/unic-archon-dlc/` exists with valid `.claude-plugin/plugin.json` and `.claude-plugin/marketplace.json` (`pnpm check` and `pnpm typecheck` pass at repo root).
+- [ ] Running the install hook against a fresh project writes `.archon/unic-dlc.config.json` with at minimum `{ tracker, pr_strategy, branching }` populated.
+- [ ] Running the install hook against a fresh project writes `docs/agents/issue-tracker.md` describing the chosen tracker.
+- [ ] Re-running the install hook is idempotent: no overwrites, already-configured values shown and skipped.
+- [ ] Missing `archon` binary produces a clear, actionable error and a non-zero exit.
+- [ ] Setup explorer returns a structured snapshot for a mock project directory; missing files are reported as absent rather than throwing.
+- [ ] `node:test` suite covers config loader (3 cases) and setup explorer (1 case) and passes on macOS, Windows, and Linux paths (use `node:path`).
+- [ ] No external runtime deps added to the plugin (`auto-format`-style bar).
+
+## Blocked by
+
+None — can start immediately.
diff --git a/docs/issues/unic-archon-dlc/02-full-install-hook-and-agent-docs.md b/docs/issues/unic-archon-dlc/02-full-install-hook-and-agent-docs.md
new file mode 100644
index 0000000..dbdb4dd
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/02-full-install-hook-and-agent-docs.md
@@ -0,0 +1,47 @@
+# Full install hook with all config tiers and agent docs
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+Expand the install hook from the tracer slice to cover every configuration tier and write the full `docs/agents/` set. The hook remains idempotent and additive: re-running it fills in only what is missing.
+
+In scope:
+
+- **Skippable tier:** e2e test command. If the user defers, the config records `e2e_command: null` and the hook can fill it in on a later run.
+- **Defaulted tier (no prompt unless `--reconfigure`):** model profile (`balanced`), TDD mode (`on`), Nyquist validation (`on`), slopsquatting gate (`on`).
+- **Label configuration tier (canonical → tracker string mapping):**
+  - **State labels:** `needs-triage` → `needs-info` → `needs-specs` → `ready-for-agent` / `ready-for-human` → `resolved` → `closed` (or `rejected`). Canonical role names match `docs/agents/triage-labels.md` from this repo.
+  - **Type labels:** `feature`, `bug`, `spike`, `tech-debt`, `docs`.
+  - **Priority labels:** `p0`, `p1`, `p2`, `p3`.
+  - Each canonical name is mapped to the actual string used in the project's tracker.
+- **Multi-context detection:** if `CONTEXT-MAP.md` exists at repo root, the hook records `repo_layout: "multi-context"` and discovers per-context `CONTEXT.md` paths; otherwise `"single-context"` with the root `CONTEXT.md` path.
+- **`docs/agents/` outputs** (write or update — never clobber unrelated content):
+  - `issue-tracker.md` — already written in slice 1; expand with backend-specific create/update conventions.
+  - `labels.md` — three-tier taxonomy with canonical-to-string mappings for the chosen tracker.
+  - `branching.md` — chosen strategy, default branch names, PR target conventions.
+  - `domain.md` — single-context vs multi-context layout, CONTEXT.md and ADR locations.
+  - `workflow.md` — maps each of the six workflow phases to its artifact outputs and `docs/workflow/` paths.
+- **`CLAUDE.md` update:** append (or update in place) an `## Agent skills` block listing each `docs/agents/*.md` file with a one-line hook. If the block already exists, refresh its contents idempotently.
+- Reasonable defaults applied automatically when the tracker is local markdown (canonical strings == tracker strings).
+
+Out of scope: workflow YAML or command file contents (later slices).
+
+## Acceptance criteria
+
+- [ ] Fresh install writes all five `docs/agents/*.md` files plus the `## Agent skills` block in `CLAUDE.md`.
+- [ ] `.archon/unic-dlc.config.json` includes all label tiers, e2e command (or `null`), defaulted fields, and `repo_layout`.
+- [ ] Multi-context repo (with `CONTEXT-MAP.md`) is detected and recorded; single-context repo records the root `CONTEXT.md` path.
+- [ ] Re-running the hook after the tracer install adds only missing fields; existing fields are preserved unless `--reconfigure` is passed.
+- [ ] If `CLAUDE.md` already has an `## Agent skills` block, it is refreshed without duplicating sections or destroying neighbouring content.
+- [ ] Each `docs/agents/*.md` matches the canonical-to-tracker mapping in `.archon/unic-dlc.config.json` (no drift between machine and human readable).
+- [ ] Tests cover the canonical-to-tracker mapping for at least the local-markdown and GitHub backends.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/01-plugin-scaffold-and-tracer-install.md`
diff --git a/docs/issues/unic-archon-dlc/03-triage-workflow-and-tracker-adapter.md b/docs/issues/unic-archon-dlc/03-triage-workflow-and-tracker-adapter.md
new file mode 100644
index 0000000..25fa363
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/03-triage-workflow-and-tracker-adapter.md
@@ -0,0 +1,40 @@
+# Triage workflow and tracker adapter
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+The simplest of the six workflows — `triage` — paired with the tracker adapter module that every later workflow will depend on. Builds the foundation for issue I/O across all backends.
+
+In scope:
+
+- **Tracker adapter module:** translates canonical label names to tracker-specific strings and produces create/update CLI command strings for each configured backend. Backends covered in v1: GitHub Issues, Azure DevOps, Jira, local markdown (per the `docs/agents/issue-tracker.md` convention in this repo: file under `docs/issues/<slug>/`, `Status:` line records triage state, comments append to a `## Comments` heading). Deep module — all tracker-specific knowledge encapsulated.
+- **`/unic-dlc-triage` command** (note the `unic-dlc-` prefix — avoids collision with existing `/triage` skills) plus `.archon/workflows/triage.yaml`.
+- **Workflow behaviour:** reads current issue states from the configured tracker, reconciles them against `docs/workflow/ROADMAP.md` (creates it if absent), and produces `HANDOFF.md` capturing:
+  - Current phase (which workflow last ran, when, on which feature slug)
+  - Open issues grouped by triage state
+  - Blockers (issues whose `blocked_by` references are still open)
+  - Recent decisions (latest ADR file IDs)
+- **Standalone invocation:** runnable at any point in the lifecycle without prerequisites.
+- **Reused as final node of `cleanup`:** the same workflow file is referenced from the cleanup DAG in slice 13. Both invocations produce the same `HANDOFF.md`.
+- Tests covering the tracker adapter: for each backend, canonical label input produces the expected CLI command string. Tests also assert that absent state files are treated as "no data" rather than errors.
+
+Out of scope: any auto-promotion of issues across states (PRD explicitly excludes this).
+
+## Acceptance criteria
+
+- [ ] `/unic-dlc-triage` runs end-to-end against a project with the local-markdown tracker and produces a valid `HANDOFF.md`.
+- [ ] Tracker adapter handles all four backends. Each emits a syntactically valid CLI command (or the local-markdown file write) for a canonical-label input.
+- [ ] `docs/workflow/ROADMAP.md` is created on first run and updated on subsequent runs; updates do not clobber human-edited sections (use marker-delimited regions for the auto-generated parts).
+- [ ] `HANDOFF.md` includes all four sections: phase, open issues by state, blockers, recent decisions.
+- [ ] `node:test` covers the tracker adapter (one case per backend) and the HANDOFF generator (golden-file-style assertion on a mock project state).
+- [ ] Command file uses the `unic-dlc-` prefix consistently.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/02-full-install-hook-and-agent-docs.md`
diff --git a/docs/issues/unic-archon-dlc/04-explore-parallel-research-and-synthesize.md b/docs/issues/unic-archon-dlc/04-explore-parallel-research-and-synthesize.md
new file mode 100644
index 0000000..ecff2cc
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/04-explore-parallel-research-and-synthesize.md
@@ -0,0 +1,39 @@
+# Explore workflow — parallel research and synthesize
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+First half of the `explore` workflow: four parallel research agents converging on a `synthesize` node that produces a coherent brief, written to `docs/workflow/<slug>/findings.md`.
+
+In scope:
+
+- `.archon/workflows/explore.yaml` (will be extended in slice 05 with the prototype phase).
+- `/unic-dlc-explore` command file.
+- **Four parallel research nodes** running simultaneously, each scoped to a single concern:
+  - `research-stack` — current and emerging stack relevant to the feature
+  - `research-features` — comparable existing features in the codebase and prior art
+  - `research-architecture` — how the change fits the existing architecture and ADRs
+  - `research-pitfalls` — known traps, deprecations, security/privacy considerations
+- **`synthesize` node** combining the four research outputs with the user's stated intent into a coherent brief. Pulls in CONTEXT.md and (if multi-context) CONTEXT-MAP.md so the brief uses the project glossary.
+- **`docs/workflow/<slug>/findings.md`** is committed to the repo. The slug is taken from the user-supplied feature name; the hook creates the directory if absent.
+- **Optional input from `explore` is honoured by `plan`:** `plan` works without findings, but consumes them when present (the contract is "findings.md may or may not exist" — slice 06's `specs` node handles both cases).
+
+Out of scope (covered in slice 05): prototype node, VALIDATED/INVALIDATED/PARTIAL verdicts, spike-branch gate, spike ticket creation.
+
+## Acceptance criteria
+
+- [ ] `/unic-dlc-explore <slug>` runs all four research nodes in parallel (verifiable from the Archon execution log or YAML structure).
+- [ ] `synthesize` produces `docs/workflow/<slug>/findings.md` containing sections for each research dimension plus the integrated brief.
+- [ ] `findings.md` references CONTEXT.md vocabulary and at least one existing ADR by ID when one is relevant.
+- [ ] Running `explore` without an existing `docs/workflow/<slug>/` directory creates it; running with an existing directory does not destroy prior contents.
+- [ ] Command file uses the `unic-dlc-` prefix.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/02-full-install-hook-and-agent-docs.md`
diff --git a/docs/issues/unic-archon-dlc/05-explore-prototype-and-spike-gate.md b/docs/issues/unic-archon-dlc/05-explore-prototype-and-spike-gate.md
new file mode 100644
index 0000000..38a6123
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/05-explore-prototype-and-spike-gate.md
@@ -0,0 +1,36 @@
+# Explore workflow — prototype, spike verdicts, and spike-branch gate
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+Second half of the `explore` workflow: a prototype node that runs structured experiments, an optional human gate for preserving valuable spike code, and a spike ticket in the configured tracker.
+
+In scope:
+
+- **`prototype` node** appended to `.archon/workflows/explore.yaml`. Reads `findings.md` and produces one or more experiments, each emitting a structured verdict — exactly one of:
+  - `VALIDATED` — approach works as expected, evidence captured.
+  - `INVALIDATED` — approach failed, reason captured.
+  - `PARTIAL` — partially works, gaps documented.
+  - Verdicts and per-experiment notes are written into a `## Spike verdicts` section of `findings.md` (single source of truth — no separate spike file).
+- **Optional interactive gate** after `prototype`: asks the user whether the spike produced code worth preserving on a branch. If yes, the workflow creates a `spike/<slug>` branch with the prototype code committed; if no, the worktree is left clean.
+- **Spike ticket creation** via the tracker adapter (slice 03): a ticket of type `spike`, labelled with the configured priority default, linking to `docs/workflow/<slug>/findings.md`. The ticket records VALIDATED/INVALIDATED/PARTIAL summary in its body so the tracker view is informative.
+
+Out of scope: feeding spike code into `plan` automatically — `plan` reads `findings.md` only, not the branch.
+
+## Acceptance criteria
+
+- [ ] `prototype` node runs after `synthesize` and writes a `## Spike verdicts` section to `findings.md` with at least one experiment carrying exactly one verdict from {VALIDATED, INVALIDATED, PARTIAL}.
+- [ ] Spike-branch gate is interactive: answering "yes" creates a `spike/<slug>` branch with a commit; answering "no" leaves no branch behind.
+- [ ] A spike ticket is created in the configured tracker via the tracker adapter, with type label `spike`, body linking to `findings.md`, and a one-line verdict summary.
+- [ ] Re-running `/unic-dlc-explore <slug>` on an existing slug does not duplicate the spike ticket; the existing ticket is updated.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/03-triage-workflow-and-tracker-adapter.md`
+- `docs/issues/unic-archon-dlc/04-explore-parallel-research-and-synthesize.md`
diff --git a/docs/issues/unic-archon-dlc/06-plan-specs-and-to-prd.md b/docs/issues/unic-archon-dlc/06-plan-specs-and-to-prd.md
new file mode 100644
index 0000000..4e072d6
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/06-plan-specs-and-to-prd.md
@@ -0,0 +1,40 @@
+# Plan workflow — specs, to-prd, and first PR gate
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+First half of the `plan` workflow: a grill-with-docs interview, live ADR writes for non-obvious decisions, a structured PRD output, and the first human approval gate.
+
+In scope:
+
+- `.archon/workflows/plan.yaml` (extended by slice 07).
+- `/unic-dlc-plan` command file.
+- **`specs` node — grill-with-docs style:**
+  - Loads `CONTEXT.md`, `CONTEXT-MAP.md` (if present), all existing ADRs from `docs/adr/`, and `docs/workflow/<slug>/findings.md` if present.
+  - Conducts an adversarial interview, **one question at a time**, challenging terminology against the domain glossary.
+  - Proposes ADR entries for non-obvious decisions as they crystallise — not for every answer. Written live into `docs/adr/NNNN-<slug>.md` at the moment the decision is made.
+  - Configurable assumptions-first mode via `workflow.discuss_mode: assumptions` in `.archon/unic-dlc.config.json` (defaults to `interview`). Assumptions mode is for experienced developers in established codebases — surfaces a set of assumptions for the user to correct rather than asking from scratch.
+- **`to-prd` node:** synthesises the interview transcript and live-written ADRs into `docs/workflow/<slug>/PRD.md` with the agreed structure: Problem Statement, Solution, User Stories, Implementation Decisions, Testing Decisions, Out of Scope, Further Notes.
+- **First human PR gate (`interactive: true`):** opens a PR against the working branch with `PRD.md` and any new ADRs staged for review. Workflow pauses until the gate is approved.
+
+Out of scope (slice 07 and 08): `to-issues`, `nyquist-map`, `plan-checker`, `yaml-gen`, second PR gate.
+
+## Acceptance criteria
+
+- [ ] `specs` loads CONTEXT.md and existing ADRs before the first interview question.
+- [ ] Interview asks one question at a time (no multi-question batches) and rephrases when the user pushes back on terminology.
+- [ ] At least one ADR is written into `docs/adr/` during a representative session that contains a non-obvious decision; sessions with only obvious answers produce zero ADRs.
+- [ ] `to-prd` writes `docs/workflow/<slug>/PRD.md` with all seven structural sections present.
+- [ ] `workflow.discuss_mode: assumptions` flips the interview into assumptions mode; the default mode runs full interviews.
+- [ ] First human PR gate blocks the workflow until approved; rejected approvals return control to `specs` for another iteration.
+- [ ] Command file uses the `unic-dlc-` prefix.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/02-full-install-hook-and-agent-docs.md`
diff --git a/docs/issues/unic-archon-dlc/07-plan-to-issues-and-nyquist.md b/docs/issues/unic-archon-dlc/07-plan-to-issues-and-nyquist.md
new file mode 100644
index 0000000..5ce98e1
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/07-plan-to-issues-and-nyquist.md
@@ -0,0 +1,38 @@
+# Plan workflow — to-issues, nyquist-map, and validation gate
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+Decomposes the approved PRD into vertically-sliced issues with explicit dependencies and a test command for each issue, then asks the user to validate the breakdown before publication.
+
+In scope:
+
+- **`to-issues` node** extending `plan.yaml`:
+  - Reads `docs/workflow/<slug>/PRD.md` and emits `docs/workflow/<slug>/issues.json` with a list of issues; each issue carries `title`, `type` (canonical type label), `priority` (canonical priority label), `blocked_by: []` (array of issue IDs in this same file), `acceptance_criteria: []`, and `summary`.
+  - Slices are vertical tracer bullets — each slice cuts through every integration layer end-to-end, not horizontally by layer.
+  - Before writing the issues to the tracker, presents the breakdown to the user (numbered list with type/priority/blocked-by/summary) and asks the user to validate, split, merge, or relabel. Iterates until approved.
+  - After approval, publishes each issue to the configured tracker via the tracker adapter, in dependency order so blocker IDs are real.
+- **`nyquist-map` node:** for each issue, attaches a `test_command` field (the exact shell command that proves the issue's acceptance criteria). For issues whose test command does not yet exist, attaches a `test_command_planned` flag so `plan-checker` (slice 08) can flag them.
+- This slice publishes the issues to the tracker so the user can see them — but does **not** generate the build YAML (slice 08) and does **not** invoke the `plan-checker` loop (slice 08). It is acceptable for a user to stop here.
+
+Out of scope: `plan-checker` loop, `yaml-gen`, second PR gate (all in slice 08).
+
+## Acceptance criteria
+
+- [ ] `to-issues` reads PRD.md and writes `issues.json` whose structure matches the field set above.
+- [ ] Issues are vertical slices — each entry's acceptance criteria can be demonstrated independently (verified by a representative example in tests).
+- [ ] Validation gate is interactive and supports split/merge/relabel before publication.
+- [ ] After approval, each issue exists in the configured tracker with correct type and priority labels (verified for the local-markdown backend at minimum).
+- [ ] `nyquist-map` attaches a `test_command` (or `test_command_planned: true`) to every issue.
+- [ ] Tracker publication is dependency-ordered: every `blocked_by` reference points to an issue that already exists in the tracker.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/03-triage-workflow-and-tracker-adapter.md`
+- `docs/issues/unic-archon-dlc/06-plan-specs-and-to-prd.md`
diff --git a/docs/issues/unic-archon-dlc/08-plan-checker-and-yaml-gen.md b/docs/issues/unic-archon-dlc/08-plan-checker-and-yaml-gen.md
new file mode 100644
index 0000000..24bc330
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/08-plan-checker-and-yaml-gen.md
@@ -0,0 +1,41 @@
+# Plan workflow — plan-checker loop, yaml-gen, and second PR gate
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+Closes out the `plan` workflow with a validating loop that hardens the issue plan, a runtime YAML generator that turns the dependency tree into a build DAG, and the second human PR gate.
+
+In scope:
+
+- **`plan-checker` loop node:**
+  - Max 3 iterations before escalation to a human gate.
+  - **Stall detection:** if the issue count does not decrease between consecutive iterations, escalate immediately to the human gate rather than burning the remaining retries.
+  - Validates four dimensions:
+    - **Consistency** — no orphaned `blocked_by` references, all PRD acceptance criteria are covered by at least one issue.
+    - **Completeness** — every mandatory field is present on every issue.
+    - **Decision coverage** — every trackable decision in `CONTEXT.md` (and any decisions captured during `specs`) appears in at least one issue.
+    - **Nyquist compliance** — every issue maps to a concrete test command (no lingering `test_command_planned: true` unless explicitly accepted at the gate).
+- **`yaml-gen` bash node:** reads `issues.json`, builds the dependency DAG, detects parallel groups (issues with no shared `blocked_by`), and writes `.archon/workflows/build-<slug>.yaml`. Both `code-red` and `code-green` for independent issues are emitted as parallel-capable nodes. Linear chains produce serial nodes; circular dependencies are detected, reported, and abort the generation. Output YAML must be valid Archon syntax.
+- **Dependency tree builder + YAML generator module:** pure data transformation, separately unit-tested. Test cases: linear chain → serial; independents → parallel; circular → reported; output round-trips through Archon's YAML parser.
+- **Second human PR gate (`interactive: true`):** opens a PR containing `issues.json`, the generated `build-<slug>.yaml`, and the `plan-checker` report. Workflow pauses until approved. Rejected approvals return control to `plan-checker` for another validation pass (not a full re-decomposition).
+
+Out of scope: executing the generated build YAML (slice 09).
+
+## Acceptance criteria
+
+- [ ] `plan-checker` runs at most 3 iterations and escalates on stall (issue count stays equal between consecutive iterations).
+- [ ] `plan-checker` reports failures across all four validation dimensions in a single structured report.
+- [ ] `yaml-gen` produces a syntactically valid Archon YAML; circular dependencies abort with a clear error.
+- [ ] Independent issues appear as parallel nodes; chained issues appear as serial nodes; both `code-red` and `code-green` carry parallel grouping when applicable.
+- [ ] Dependency tree builder unit tests cover linear, parallel-fan, diamond, and circular cases.
+- [ ] Second human PR gate stages `issues.json` + `build-<slug>.yaml` + `plan-checker` report in a PR and blocks until approved.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/07-plan-to-issues-and-nyquist.md`
diff --git a/docs/issues/unic-archon-dlc/09-build-tdd-core-and-slopcheck.md b/docs/issues/unic-archon-dlc/09-build-tdd-core-and-slopcheck.md
new file mode 100644
index 0000000..77abe16
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/09-build-tdd-core-and-slopcheck.md
@@ -0,0 +1,43 @@
+# Build workflow — TDD core and slopcheck
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+The TDD execution core of `build`: the generated `build-<slug>.yaml` is executed by Archon, enforcing `code-red` before `code-green` per issue, with both phases parallelisable across independent issues. A `slopcheck` gate sits in front of any package install to guard against AI-hallucinated dependencies.
+
+In scope:
+
+- **`/unic-dlc-build <slug>` command** that executes the runtime-generated `.archon/workflows/build-<slug>.yaml` produced in slice 08.
+- **Per-issue TDD discipline enforced by the DAG:**
+  - `code-red` writes failing acceptance tests for the issue.
+  - `code-green` writes the minimum implementation to pass those tests.
+  - `depends_on` edges in the generated YAML force red → green within an issue.
+- **Cross-issue parallelism:** both `code-red` and `code-green` may run in parallel across issues whose `blocked_by` is empty (or whose blockers are already complete). The `yaml-gen` output from slice 08 must already encode this; this slice verifies the runtime honours it.
+- **`slopcheck` bash node** placed before any `package install` step:
+  - Detects newly introduced package names by diffing manifest files (`package.json`, `pyproject.toml`, `Cargo.toml`, etc. depending on the project — start with the JS/TS ecosystem and document how to extend).
+  - For each new package, checks registry existence (npm registry HEAD request for JS; equivalent for the other ecosystems already in scope).
+  - Packages that fail the registry check are flagged `[ASSUMED]`.
+  - For each `[ASSUMED]` package, creates a `checkpoint:human-verify` task inline so the user explicitly approves before installation continues.
+  - If the optional `slopcheck` Python tool (GSD's slopsquatting gate) is on `PATH`, defer to it for the registry check; otherwise use the fallback registry HEAD checks.
+  - If neither path is available, default to marking every new package `[ASSUMED]` — stricter, not silently permissive.
+
+Out of scope: verification, goals-check, report, `/unic-dlc-review` (slices 10 and 11).
+
+## Acceptance criteria
+
+- [ ] Executing `/unic-dlc-build <slug>` runs the runtime-generated YAML and produces commits in the order: failing test → passing implementation, per issue.
+- [ ] Independent issues are observed to run `code-red` (and `code-green`) in parallel for at least one representative `issues.json` test case.
+- [ ] `slopcheck` runs before any package install and creates a `checkpoint:human-verify` task for every `[ASSUMED]` package.
+- [ ] Approving the checkpoint allows the install to proceed; rejecting it aborts the install for that package and surfaces a clear message.
+- [ ] When neither the Python `slopcheck` tool nor the fallback registry check is available, every new package is treated as `[ASSUMED]`.
+- [ ] Command file uses the `unic-dlc-` prefix.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/08-plan-checker-and-yaml-gen.md`
diff --git a/docs/issues/unic-archon-dlc/10-build-verification-goals-check-and-report.md b/docs/issues/unic-archon-dlc/10-build-verification-goals-check-and-report.md
new file mode 100644
index 0000000..d2f8203
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/10-build-verification-goals-check-and-report.md
@@ -0,0 +1,42 @@
+# Build workflow — verification, goals-check, report, and PR gate
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+Quality and consolidation phase of `build`: a verification node that catches low-quality implementations, a goals-check coverage matrix that ties code back to the PRD, a consolidated report, and the human PR gate that follows.
+
+In scope:
+
+- **`verification` node:**
+  - Runs the full test suite for the slug's touched packages.
+  - Checks coverage thresholds (from `.archon/unic-dlc.config.json`).
+  - Detects stub patterns: `TODO` / `FIXME` / empty function bodies that only `return` or `pass` / hardcoded sentinel values returned where logic was expected.
+  - Audits wiring across layers: component → API → DB; form → handler. Mismatches are reported with file:line references so the report is actionable.
+- **`goals-check` node:** reads `docs/workflow/<slug>/PRD.md` and produces a **coverage matrix** mapping each acceptance criterion (from every user story / issue) to implementation evidence (file paths, test names, or "MISSING"). The matrix is the artifact reviewers look at before merging.
+- **`report` node:** writes `docs/workflow/<slug>/report.md` consolidating:
+  - What was built (high-level summary of merged issues)
+  - Goals-check matrix (verbatim from the previous node)
+  - Test outcomes (pass/fail counts, coverage numbers)
+  - Decisions made during implementation (links to any new ADRs)
+  - Tech debt flagged for cleanup (consumed by slice 13)
+- **Human PR gate (`interactive: true`)** after `report`: opens a PR with the implementation plus `report.md`. Workflow pauses until approved. Rejected approvals return control to `verification` for another pass.
+
+Out of scope: the `/unic-dlc-review` command itself (slice 11) — this slice's PR gate is the human review; slice 11 adds the automated AFK review.
+
+## Acceptance criteria
+
+- [ ] `verification` fails when coverage is below threshold, when stub patterns are present, or when a wiring mismatch is detected.
+- [ ] `goals-check` produces a coverage matrix where each row maps an acceptance criterion to evidence or "MISSING"; matrices with any "MISSING" rows fail the node.
+- [ ] `report.md` contains all five sections and is committed to `docs/workflow/<slug>/`.
+- [ ] Human PR gate blocks until approved; rejection returns control to `verification`.
+- [ ] Tests cover the stub-pattern detector with at least three positive and three negative cases.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/09-build-tdd-core-and-slopcheck.md`
diff --git a/docs/issues/unic-archon-dlc/11-build-self-contained-review-command.md b/docs/issues/unic-archon-dlc/11-build-self-contained-review-command.md
new file mode 100644
index 0000000..3688660
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/11-build-self-contained-review-command.md
@@ -0,0 +1,42 @@
+# Build workflow — self-contained /unic-dlc-review command
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+A self-contained `/unic-dlc-review` command that performs a multi-aspect PR review as an AFK Archon node. It is independent of any external review plugin so users can run the full DLC without installing `pr-review-toolkit`.
+
+In scope:
+
+- **`/unic-dlc-review` command + workflow node** invoked after the human PR gate from slice 10 (the human gate approves the PR; the review runs automatically on the diff).
+- **Four review aspects, each emitting a structured finding list:**
+  1. **Code quality** — readability, naming, function length, project-convention adherence (reads `CLAUDE.md`/`AGENTS.md`).
+  2. **Test coverage adequacy** — exercises through public interfaces, asserts on outputs not internals, no mocks of internal collaborators.
+  3. **Silent failure patterns** — swallowed exceptions, empty `catch` blocks, fallbacks that hide bugs.
+  4. **Type design quality** — encapsulation, invariants expressed in types, illegal-state-unrepresentable patterns.
+- **Inspiration references** documented in the command file:
+  - This monorepo's `apps/claude-code/pr-review/` (patterns, not runtime dependency).
+  - Matt Pocock's `review` skill (https://github.com/mattpocock/skills/blob/main/skills/in-progress/review/SKILL.md).
+  - Note in the command file that this is a base review intended to evolve; later slices may deepen each aspect.
+- **Output:** a structured review comment posted via the tracker adapter against the PR opened by slice 10. Findings are grouped by aspect with file:line references.
+- **No runtime dependency** on `pr-review-toolkit` or any other plugin — verified by running the review in a project where `pr-review-toolkit` is not installed.
+
+Out of scope: integrating the review with the `qa` workflow's gates (slice 12 reads but does not depend on the review output).
+
+## Acceptance criteria
+
+- [ ] `/unic-dlc-review` runs to completion on a project that does not have `pr-review-toolkit` installed.
+- [ ] The review posts a single structured comment grouped by the four aspects, each with at least one finding or an explicit "no findings" line.
+- [ ] Findings include file:line references where applicable.
+- [ ] Command file uses the `unic-dlc-` prefix and includes the inspiration references in its prologue.
+- [ ] Re-running the review on the same PR updates the prior comment rather than appending a duplicate.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/03-triage-workflow-and-tracker-adapter.md`
+- `docs/issues/unic-archon-dlc/10-build-verification-goals-check-and-report.md`
diff --git a/docs/issues/unic-archon-dlc/12-qa-workflow.md b/docs/issues/unic-archon-dlc/12-qa-workflow.md
new file mode 100644
index 0000000..2cb506e
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/12-qa-workflow.md
@@ -0,0 +1,37 @@
+# QA workflow — e2e, coverage gate, UAT, merge
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+A `qa` workflow that runs the e2e suite first, fails fast on insufficient coverage, presents an informed UAT checklist, and merges the PR via the tracker's CLI after sign-off.
+
+In scope:
+
+- `/unic-dlc-qa <slug>` command and `.archon/workflows/qa.yaml`.
+- **E2e suite runs first.** Uses the `e2e_command` configured during install (slice 02). If unset, the workflow halts with a clear message asking the user to run install with `--reconfigure` and set the command.
+- **`coverage-gate` bash node** enforces the coverage thresholds configured in `.archon/unic-dlc.config.json`. Fails fast — the human UAT gate never opens unless automated coverage already passes.
+- **`uat-gate` interactive node:** presents e2e results alongside the UAT checklist extracted from the PRD's acceptance criteria. Approval continues to merge; rejection returns control to whoever owns the failing checklist item.
+- **Merge step via tracker adapter:** after `uat-gate` approves, the workflow merges the PR using the configured tracker's CLI (no manual terminal commands required). Branch deletion follows the configured branching strategy (Gitflow vs GitHub Flow).
+- All workflow YAML uses canonical label names; the adapter translates at write time.
+
+Out of scope: post-merge cleanup (slice 13).
+
+## Acceptance criteria
+
+- [ ] `/unic-dlc-qa <slug>` runs the configured `e2e_command` before any human gate opens.
+- [ ] If `e2e_command` is unset, the workflow halts with a clear, actionable message and a non-zero exit.
+- [ ] `coverage-gate` blocks `uat-gate` when coverage is below threshold.
+- [ ] `uat-gate` shows the PRD's acceptance criteria as a checklist alongside the e2e summary.
+- [ ] After `uat-gate` approves, the PR is merged via the tracker adapter; branch handling matches the configured branching strategy.
+- [ ] Command file uses the `unic-dlc-` prefix.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/03-triage-workflow-and-tracker-adapter.md`
+- `docs/issues/unic-archon-dlc/10-build-verification-goals-check-and-report.md`
diff --git a/docs/issues/unic-archon-dlc/13-cleanup-workflow.md b/docs/issues/unic-archon-dlc/13-cleanup-workflow.md
new file mode 100644
index 0000000..3f375a5
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/13-cleanup-workflow.md
@@ -0,0 +1,40 @@
+# Cleanup workflow — arch-review, ADR consolidation, triage
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+Post-merge cleanup that catches drift, locks in architectural decisions, and refreshes project state. Ends by reusing the triage workflow from slice 03.
+
+In scope:
+
+- `/unic-dlc-cleanup <slug>` command and `.archon/workflows/cleanup.yaml`.
+- **`arch-review` node:**
+  - Reads both `docs/workflow/<slug>/PRD.md` (intent) and `docs/workflow/<slug>/report.md` (technical outcome) alongside the changed code.
+  - Catches **technical drift** (modules that became too shallow, tight coupling, leaky abstractions) and **intent drift** (delivered behaviour diverges from the PRD).
+  - Proposes **deepening opportunities** for modules that grew thin during implementation.
+  - Writes `docs/workflow/<slug>/arch-review.md`.
+- **`adr-consolidation` interactive node:**
+  - Reviews decisions logged during `build` (the "Decisions made during implementation" section of `report.md`) plus any ADR drafts proposed during `arch-review`.
+  - **Per-ADR approval gate**: each proposed ADR is presented individually for accept / reject / edit. Only accepted ADRs are written to `docs/adr/`.
+- **Final node reuses slice 03's `triage` workflow** — the same `.archon/workflows/triage.yaml` is referenced via Archon's workflow-include mechanism. Both invocations (standalone vs as cleanup's final node) produce the same `HANDOFF.md` and the same `ROADMAP.md` update.
+
+Out of scope: changes to `triage` itself (any new behaviour belongs in slice 03's file).
+
+## Acceptance criteria
+
+- [ ] `/unic-dlc-cleanup <slug>` writes `docs/workflow/<slug>/arch-review.md` covering technical drift, intent drift, and at least one deepening opportunity (or "none identified").
+- [ ] `adr-consolidation` presents each proposed ADR individually; reject/accept choices are recorded; only accepted ADRs land in `docs/adr/`.
+- [ ] Cleanup's final node reuses `.archon/workflows/triage.yaml` (no duplicate triage logic); `HANDOFF.md` is produced exactly once per cleanup run.
+- [ ] The reused triage node updates `docs/workflow/ROADMAP.md` when invoked as cleanup's final node (no duplicate ROADMAP logic in cleanup itself).
+- [ ] Command file uses the `unic-dlc-` prefix.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/12-qa-workflow.md`
+- `docs/issues/unic-archon-dlc/03-triage-workflow-and-tracker-adapter.md`
diff --git a/docs/issues/unic-archon-dlc/14-readme-and-documentation.md b/docs/issues/unic-archon-dlc/14-readme-and-documentation.md
new file mode 100644
index 0000000..32d4eb7
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/14-readme-and-documentation.md
@@ -0,0 +1,46 @@
+# README and complete documentation
+
+**Status:** ready-for-agent
+**Category:** docs
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+The plugin README — the only user-facing entry point for adopters. Final slice because it documents the shipped behaviour, not the intended behaviour.
+
+In scope (`apps/claude-code/unic-archon-dlc/README.md`):
+
+1. **Mermaid flowchart** showing all six workflows (`explore`, `plan`, `build`, `qa`, `cleanup`, `triage`), every node, and human gate markers (✓ on interactive nodes).
+2. **Node reference table** — one row per node:
+   - Workflow · Node · Type (`prompt` / `loop` / `bash` / `interactive`) · Human gate (✓ / —)
+3. **Quick-start** — install + first run in three steps. Example commands use the `unic-dlc-` prefix.
+4. **Configuration reference** — every key in `.archon/unic-dlc.config.json` with default and valid values: `tracker`, `pr_strategy`, `branching`, `e2e_command`, `model_profile`, `tdd_mode`, `nyquist_validation`, `slopsquatting_gate`, label tier mappings, `repo_layout`, `workflow.discuss_mode`, coverage thresholds.
+5. **`docs/workflow/` layout diagram** — visual of what gets created where and who owns each artifact. State the three-layer separation explicitly: transient (`$ARTIFACTS_DIR`) vs persistent (`docs/workflow/<slug>/`) vs tracker.
+6. **Dependency map:** Archon version requirement, no required peer plugins, optional `slopcheck` Python tool.
+7. **Distribution note:** Archon has no marketplace; this plugin fills the gap by riding the Claude Code plugin marketplace and scaffolding workflows into the target project.
+
+Also in scope:
+
+- The plugin's `CHANGELOG.md` carries a dated `0.1.0` entry summarising the lifecycle (CI's `verify:changelog` will fail without it).
+- The marketplace listing description matches the README's one-line summary.
+
+Out of scope: per-workflow deep-dive docs (those live in `.archon/commands/*.md` shipped by each workflow slice).
+
+## Acceptance criteria
+
+- [ ] README renders correctly (Mermaid block parses; tables render).
+- [ ] Mermaid flowchart shows all 6 workflows, every node from slices 03–13, and human gates marked with ✓.
+- [ ] Node reference table includes every node in the shipped workflows.
+- [ ] Quick-start gets a developer from zero to a successful `/unic-dlc-triage` run in three steps.
+- [ ] Every key written by the install hook (slices 01 and 02) appears in the configuration reference with default and valid values.
+- [ ] `docs/workflow/` layout diagram names the three persistence layers explicitly.
+- [ ] `CHANGELOG.md` has a dated `0.1.0` entry and `pnpm --filter unic-archon-dlc verify:changelog` passes.
+
+## Blocked by
+
+- `docs/issues/unic-archon-dlc/05-explore-prototype-and-spike-gate.md`
+- `docs/issues/unic-archon-dlc/11-build-self-contained-review-command.md`
+- `docs/issues/unic-archon-dlc/13-cleanup-workflow.md`
diff --git a/docs/issues/unic-archon-dlc/15-fix-interactive-loop-fresh-context.md b/docs/issues/unic-archon-dlc/15-fix-interactive-loop-fresh-context.md
new file mode 100644
index 0000000..ec426fd
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/15-fix-interactive-loop-fresh-context.md
@@ -0,0 +1,31 @@
+# Fix interactive loop nodes: add fresh_context to prevent session expiry crashes
+
+**Status:** ready-for-agent
+**Category:** bug
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+All interactive loop nodes in the six workflows (`explore.yaml`, `plan.yaml`, `cleanup.yaml`) crash on iteration 2+ when a human responds to a gate. The root cause is a known Archon bug (coleam00/Archon#1208): the DAG executor tries to resume an expired Claude SDK session from the previous iteration instead of starting a fresh one. The fix is to add `fresh_context: true` to every node that is both `interactive: true` and uses a `loop:` block, so each iteration gets a clean session.
+
+Affected nodes across the six workflows:
+
+- `explore.yaml` → `code-preserve-gate`
+- `plan.yaml` → `specs` (grill loop), `prd-gate`, `plan-gate`, `stall-gate`
+- `cleanup.yaml` → `adr-consolidation`
+- `qa.yaml` → `uat-gate`
+
+No lib modules, tests, or install hook are touched — this is a YAML-only patch.
+
+## Acceptance criteria
+
+- [ ] Every `interactive: true` loop node in all six workflow YAMLs has `fresh_context: true` set.
+- [ ] No non-interactive loop node (e.g. `plan-checker`) receives `fresh_context: true` — only interactive gates get it.
+- [ ] `pnpm check` passes at repo root after the change.
+
+## Blocked by
+
+None — can start immediately.
diff --git a/docs/issues/unic-archon-dlc/16-qa-verify-pr-base.md b/docs/issues/unic-archon-dlc/16-qa-verify-pr-base.md
new file mode 100644
index 0000000..5903439
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/16-qa-verify-pr-base.md
@@ -0,0 +1,35 @@
+# QA workflow: add verify-pr-base guard after merge-pr
+
+**Status:** ready-for-agent
+**Category:** feature
+
+## Parent
+
+`docs/issues/unic-archon-dlc/PRD.md`
+
+## What to build
+
+`qa.yaml` currently calls `merge-pr` (which runs the configured tracker's merge CLI command) but does not verify the PR targets the correct base branch first. If the PR was opened against the wrong target — e.g. `main` instead of `develop` on a Gitflow project — the merge silently ships to the wrong branch.
+
+Add a `verify-pr-base` bash node that runs before `merge-pr`:
+
+1. Reads the configured branching strategy from `.archon/unic-dlc.config.json`.
+2. Derives the expected base branch (`develop` for Gitflow, `main` for GitHub Flow).
+3. For GitHub tracker: calls `gh pr view --json baseRefName` and compares.
+4. For ADO tracker: calls `az repos pr show` and compares `targetRefName`.
+5. For Jira / local: logs a warning and continues (no CLI to query PR base).
+6. If the base is wrong: logs a clear error with the expected vs actual branch names and exits non-zero, preventing `merge-pr` from running.
+
+This is a YAML-only addition of one `bash` node with an inline shell snippet — no lib modules or tests are added.
+
+## Acceptance criteria
+
+- [ ] `qa.yaml` has a `verify-pr-base` bash node with `depends_on: [uat-gate]`.
+- [ ] `merge-pr` has `depends_on: [verify-pr-base]`.
+- [ ] For GitHub and ADO trackers, the node exits non-zero with a clear message if the PR base does not match the expected branch.
+- [ ] For Jira and local trackers, the node logs a warning and exits zero (no-op).
+- [ ] `pnpm check` passes at repo root after the change.
+
+## Blocked by
+
+None — can start immediately.
diff --git a/docs/issues/unic-archon-dlc/PRD.md b/docs/issues/unic-archon-dlc/PRD.md
new file mode 100644
index 0000000..42156cf
--- /dev/null
+++ b/docs/issues/unic-archon-dlc/PRD.md
@@ -0,0 +1,255 @@
+# PRD: unic-archon-dlc
+
+**Status:** ready-for-agent
+**Plugin:** `apps/claude-code/unic-archon-dlc`
+**Category:** plugin
+
+A Claude Code plugin that ships a complete, Archon-powered AI development lifecycle as an installable DLC pack — taking heavy inspiration from Matt Pocock's skills workflow and GSD, and translating their best patterns into Archon's YAML DAG runtime.
+
+---
+
+## Problem Statement
+
+Development teams using AI coding agents lack a structured, repeatable lifecycle that takes a feature from raw idea all the way to shipped code with human approval gates at every critical decision point. Existing approaches either own the entire process rigidly (GSD, BMAD) or are fully manual sequences of composable skills (Matt Pocock's skills repo). Neither fits teams that want Archon's DAG execution engine — with its parallel nodes, loop primitives, and interactive gates — while preserving deliberate human checkpoints and a clean separation between transient workflow state and persistent project artifacts.
+
+---
+
+## Solution
+
+`unic-archon-dlc` is a Claude Code plugin that installs into any project and scaffolds six Archon workflows covering the full development lifecycle: **explore**, **plan**, **build**, **qa**, **cleanup**, and **triage**. Each workflow is a YAML DAG file consumable by the Archon runtime. Human approval gates (`interactive: true` nodes) are placed at every phase boundary where human judgement adds irreplaceable value. Persistent project artifacts (PRDs, findings, spike verdicts, reports, ADRs) live in the project repo under `docs/workflow/`. Transient workflow state uses Archon's native `$ARTIFACTS_DIR`. Issue tracking is fully configurable at install time — GitHub Issues, Azure DevOps, Jira, or local markdown — and the plugin writes both machine-readable config (`.archon/unic-dlc.config.json`) and human-readable agent docs (`docs/agents/`) that any agent working in the repo can consume.
+
+---
+
+## User Stories
+
+### Setup
+
+1. As a developer onboarding to `unic-archon-dlc`, I want an idempotent install hook that explores the project before asking questions, so that I'm not asked about things that are already configured.
+2. As a developer, I want the install hook to auto-detect the issue tracker from `git remote`, so that the most common case requires no manual input.
+3. As a developer, I want to skip the e2e test command during install and configure it later, so that I can set up the plugin on day one before the test suite exists.
+4. As a developer, I want to re-run the install hook at any time to fill in missing config, so that setup is accumulative rather than all-or-nothing.
+5. As a developer, I want the install hook to detect whether the repo is single-context or multi-context (via `CONTEXT-MAP.md`), so that the `specs` node reads domain docs from the right location.
+6. As a developer, I want configurable triage state labels mapped to my tracker's actual strings, so that the workflows apply labels that already exist in my project.
+7. As a developer, I want configurable issue type labels (feature, bug, spike, tech-debt, docs) and priority labels (p0–p3) mapped to my tracker's strings, so that created issues are consistent with my team's conventions.
+8. As a developer, I want to choose between Gitflow and GitHub Flow at install time, with Gitflow as the default, so that the branch strategy matches my team's convention without extra config.
+9. As a developer, I want the install hook to write a human-readable `docs/agents/` directory, so that any AI agent working in the repo understands the workflow context automatically.
+10. As a developer, I want an `## Agent skills` block added to `CLAUDE.md` pointing to the `docs/agents/` files, so that the config is discoverable from the project's main AI instruction file.
+
+### Explore Workflow
+
+11. As a developer starting on an unfamiliar integration, I want four parallel research agents (stack, features, architecture, pitfalls) to run simultaneously, so that I get broad coverage without waiting for sequential passes.
+12. As a developer, I want a synthesize node that combines parallel research findings with my stated intent into a coherent brief, so that the prototype and the grilling session are informed by everything discovered.
+13. As a developer, I want a prototype node that produces a spike with a structured VALIDATED / INVALIDATED / PARTIAL verdict per experiment, so that technical feasibility is documented before any planning begins.
+14. As a developer, I want an optional interactive gate that asks whether the prototype produced code worth preserving on a branch, so that valuable spike work is not lost.
+15. As a developer, I want `explore` to produce a `findings.md` committed to `docs/workflow/<slug>/`, so that the findings survive session boundaries and are available to the `plan` workflow.
+16. As a developer, I want `explore` to create a spike ticket in the configured issue tracker, so that the exploration work is visible and traceable.
+
+### Plan Workflow
+
+17. As a developer, I want the `specs` node to load `CONTEXT.md`, `CONTEXT-MAP.md`, and existing ADRs before interviewing me, so that the grilling session is informed by the project's domain model and past decisions.
+18. As a developer, I want the `specs` node to conduct an adversarial grill-with-docs interview — one question at a time — that challenges terminology against the domain model and proposes ADR entries for non-obvious decisions as they crystallise, so that the PRD captures everything I know without my having to write it from scratch.
+19. As a developer, I want ADRs proposed during the `specs` session to be written live into `docs/adr/`, so that decisions are recorded at the moment they are made.
+20. As a developer, I want a `to-prd` node that synthesises the grilling session into a structured PRD (problem, solution, user stories, implementation decisions, acceptance criteria), so that there is a single source of truth for the feature.
+21. As a developer, I want a first human PR gate after `to-prd`, so that I can review and approve the PRD before issue decomposition begins.
+22. As a developer, I want a `to-issues` node that decomposes the PRD into vertically-sliced, independently-grabbable issues with `blocked_by` dependency notes, so that the dependency tree is explicit and parallelisation opportunities are visible.
+23. As a developer, I want a `to-issues` node that prompts me to validate the issue breakdown before publishing, so that I can correct misclassifications before they reach the tracker.
+24. As a developer, I want a `nyquist-map` node that maps every issue to a specific test command before any code is written, so that the test infrastructure is planned as first-class work.
+25. As a developer, I want a `plan-checker` loop node that validates the issue breakdown for consistency, completeness (all mandatory fields), decision coverage (every CONTEXT.md decision appears in at least one issue), and Nyquist compliance, so that the second PR gate approves a validated plan, not raw output.
+26. As a developer, I want the `plan-checker` to detect stalls — when the issue count doesn't decrease between consecutive iterations — and escalate to a human gate rather than exhausting all retries on a stuck loop, so that I'm not surprised by a 3-iteration burn with no improvement.
+27. As a developer, I want a `yaml-gen` bash node that reads the `issues.json` dependency tree and generates a runtime `.archon/workflows/build-<slug>.yaml` with correct parallel and serial groupings, so that the `build` workflow respects actual dependencies without a static pre-defined DAG.
+28. As a developer, I want a second human PR gate after `plan-checker` passes, so that I approve a complete, validated, dependency-mapped issue plan before any code is written.
+
+### Build Workflow
+
+29. As a developer, I want the generated `build-<slug>.yaml` to run `code-red` (write failing acceptance tests) before `code-green` (write implementation), so that the TDD red-green-refactor discipline is enforced by the DAG, not by convention.
+30. As a developer, I want parallel `code-red` and `code-green` nodes for issues that have no `blocked_by` dependencies, so that independent issues are implemented concurrently and the overall build is faster.
+31. As a developer, I want a `slopcheck` bash node that checks any newly introduced package names for AI-hallucinated dependencies before they are installed, so that supply-chain risk is caught before `code-green` runs.
+32. As a developer, I want a `slopcheck` node that creates `checkpoint:human-verify` tasks inline for `[ASSUMED]` packages, so that I explicitly approve any package whose registry existence was not verified.
+33. As a developer, I want a `verification` node that runs the test suite, checks coverage thresholds, detects stub patterns (TODO/FIXME, empty returns, hardcoded values), and audits wiring (component→API, API→DB, form→handler), so that low-quality implementations are caught before the human review gate.
+34. As a developer, I want a `goals-check` node that reads the original PRD and produces a coverage matrix mapping each acceptance criterion to implementation evidence, and fails the node if any acceptance criterion has no implementation evidence, so that I can confirm the feature delivers what was intended before raising a PR.
+35. As a developer, I want a `report` node that produces `docs/workflow/<slug>/report.md` consolidating: what was built, goals-check matrix, test outcomes, decisions made during implementation, and tech debt flagged, so that the PR gate reviewer has a structured summary rather than raw diffs.
+36. As a developer, I want a human PR gate after `report`, so that I review the report and approve before the automated PR review runs.
+37. As a developer, I want a self-contained `review` command that performs a multi-aspect PR review (code quality, test coverage, silent failure patterns, type design) as an AFK Archon node, so that the review runs without requiring the `pr-review-toolkit` plugin to be installed.
+
+### QA Workflow
+
+38. As a developer, I want a `qa` workflow that runs the e2e suite first, so that the human UAT gate only opens for runs where automated tests already pass.
+39. As a developer, I want a `coverage-gate` bash node that enforces coverage thresholds and fails fast if they are not met, so that the human never reviews a build with insufficient test coverage.
+40. As a developer, I want a `uat-gate` interactive node that presents the e2e results alongside the UAT checklist from the PRD, so that human sign-off is informed by automated evidence.
+41. As a developer, I want the `qa` workflow to merge the PR via the configured tracker's CLI after `uat-gate` approves, so that the merge step is deterministic and does not require manual terminal commands.
+
+### Cleanup Workflow
+
+42. As a developer, after a feature is merged, I want an `arch-review` node that reads both `PRD.md` and `report.md` alongside the codebase, so that the review catches both technical drift and intent drift.
+43. As a developer, I want `arch-review` to identify modules that became too shallow or tightly coupled during implementation and propose deepening opportunities, so that software entropy is addressed before the next sprint.
+44. As a developer, I want an `adr-consolidation` interactive node that proposes new or updated ADRs based on decisions logged during `build`, with a per-ADR approval gate, so that only validated decisions become permanent architectural records.
+45. As a developer, I want the cleanup workflow to end with a `triage` node that reconciles all issue states in the configured tracker and updates `docs/workflow/ROADMAP.md`, so that the project state is accurate after the feature ships.
+
+### Triage Workflow
+
+46. As a developer, I want a standalone `triage` workflow callable at any point in the lifecycle, so that I can get a status snapshot without running a full cleanup cycle.
+47. As a developer, I want `triage` to produce a `HANDOFF.md` document capturing current phase, open issues, blockers, and recent decisions, so that AFK sessions can resume cleanly in a fresh context window.
+
+### Documentation
+
+48. As a developer reading the plugin README, I want a Mermaid architecture diagram showing all six workflows, their nodes, and human gate positions, so that I understand the full lifecycle at a glance without reading YAML.
+49. As a developer, I want a node reference table in the README listing every workflow, every node, its type (prompt / loop / bash / interactive), and whether it is a human gate, so that I can quickly find any node and understand its role.
+50. As a developer, I want a quick-start section in the README covering install + first run in three steps, so that onboarding is fast.
+51. As a developer, I want a configuration reference in the README documenting every key in `.archon/unic-dlc.config.json` with defaults and valid values, so that I can customise without reading source YAML.
+52. As a developer, I want a `docs/workflow/` layout section in the README explaining what gets created where and who owns each artifact, so that the separation between transient Archon state and committed project artifacts is clear.
+
+---
+
+## Implementation Decisions
+
+### Plugin structure
+
+- Plugin lives at `apps/claude-code/unic-archon-dlc/` in this monorepo, following the existing plugin convention (`auto-format`, `pr-review`, `unic-confluence`).
+- Plugin manifest at `.claude-plugin/plugin.json` and `.claude-plugin/marketplace.json`.
+- Archon workflow YAML files ship under `.archon/workflows/` inside the plugin directory and are scaffolded into the target project by the install hook.
+- Archon command markdown files ship under `.archon/commands/` inside the plugin directory and are scaffolded similarly.
+
+### Archon hard dependency
+
+- Archon is a hard runtime dependency. The README and install hook make this explicit. Target projects must have Archon installed before running any workflow.
+- The install hook verifies `archon` is available on `PATH` and surfaces a clear error if not.
+
+### Distribution model
+
+- Archon itself has no marketplace, registry, hub, or community gallery for sharing workflows. Distribution is filesystem-based: workflows are YAML files under `.archon/workflows/` committed to each project. Archon ships starter templates under `.archon/workflows/defaults/` bundled with the runtime, but there is no central channel for publishing or discovering third-party workflows.
+- `unic-archon-dlc` fills this gap by riding the **Claude Code plugin marketplace** as its distribution channel. The plugin's `.claude-plugin/marketplace.json` is what makes the six bundled workflows installable; the plugin's install hook then scaffolds them into the target project's `.archon/workflows/` and `.archon/commands/` directories. Archon contributes the _runtime_; this plugin contributes the _delivery_.
+- Because Archon's YAML schema can evolve independently of the workflows shipped here, the install hook verifies the installed Archon binary version and warns on known schema-incompatible versions — version drift is the plugin's responsibility, not Archon's.
+
+### State separation (three layers)
+
+- **Transient workflow state** (current node, loop iteration, last node output) → `$ARTIFACTS_DIR` (Archon native, not committed).
+- **Persistent project artifacts** (PRD, findings, spike verdicts, arch-review, report, ROADMAP) → `docs/workflow/<feature-slug>/` (committed to repo).
+- **Issue/ticket tracking** → configured tracker (GitHub Issues, ADO, Jira, or local markdown).
+
+### Persistent artifact layout
+
+```
+docs/workflow/
+├── ROADMAP.md                        # project-level phase tracker
+└── <feature-slug>/
+    ├── findings.md                   # output of explore/synthesize
+    ├── PRD.md                        # output of plan/to-prd
+    ├── issues.json                   # dependency tree from plan/to-issues
+    ├── report.md                     # output of build/report
+    └── arch-review.md                # output of cleanup/arch-review
+```
+
+### Dynamic parallelisation
+
+- `to-issues` outputs `docs/workflow/<slug>/issues.json` with a `blocked_by` dependency array per issue.
+- A `yaml-gen` bash node reads this file and generates `.archon/workflows/build-<slug>.yaml` at runtime, producing a DAG with correct `depends_on` edges and grouping independent issues as parallel nodes.
+- This avoids static DAG limitations — the execution graph is derived from the actual dependency tree, not pre-defined.
+
+### Install hook design
+
+- The install hook is an idempotent Node.js script (`.mjs`, ESM, no external deps) triggered by Claude Code's plugin install mechanism.
+- It explores the project first (reads `git remote`, `CLAUDE.md`, `CONTEXT.md`, `CONTEXT-MAP.md`, `docs/adr/`, existing `.archon/`) before asking any questions.
+- Questions are presented one at a time with short explainers. Already-configured values are shown and skippable.
+- Mandatory first tier (asked on every fresh install): issue tracker → PR strategy (auto-deduced from tracker) → branching strategy (Gitflow default).
+- Skippable: e2e test command (can be set later).
+- Defaulted: model profile (`balanced`), TDD mode (`on`), Nyquist validation (`on`), slopsquatting gate (`on`).
+- Dual output: `.archon/unic-dlc.config.json` (machine-readable) + `docs/agents/` files (human/agent-readable).
+
+### Configuration files written to `docs/agents/`
+
+Five files are written or updated by the install hook:
+
+- `issue-tracker.md` — tracker backend, CLI commands, create/update conventions
+- `labels.md` — three-tier label taxonomy: state (needs-triage → closed), type (feature/bug/spike/tech-debt/docs), priority (p0–p3), all mapped to actual tracker strings
+- `branching.md` — chosen strategy (Gitflow / GitHub Flow), default branch names, PR target conventions
+- `domain.md` — single-context vs multi-context layout, where CONTEXT.md and ADRs live
+- `workflow.md` — maps each workflow phase to its artifact outputs and the `docs/workflow/` paths
+
+### `specs` node — grill-with-docs style
+
+- The `specs` node loads CONTEXT.md, CONTEXT-MAP.md (if present), and relevant ADRs before the interview.
+- It conducts an adversarial interview — one question at a time — challenging terminology against the domain glossary.
+- ADR entries are proposed and written live for non-obvious decisions only (not every answer).
+- GSD's assumptions-first mode is available as a configuration flag (`workflow.discuss_mode: assumptions`) for experienced developers in established codebases.
+
+### `plan-checker` loop
+
+- Maximum 3 iterations before escalation to a human gate.
+- Stall detection: if the issue count does not decrease between consecutive iterations, escalate immediately rather than burning the remaining retries.
+- Validates four dimensions: consistency (no orphaned dependencies, all PRD acceptance criteria covered), completeness (mandatory fields present), decision coverage (every trackable CONTEXT.md decision appears in at least one issue), Nyquist compliance (every issue maps to a test command).
+
+### `review` command — self-contained
+
+- The `review` Archon command is self-contained within `unic-archon-dlc`. It does not shell out to `pr-review-toolkit`.
+- It covers: code quality, test coverage adequacy, silent failure patterns, type design quality.
+- It is inspired by `pr-review-toolkit` patterns but has no runtime dependency on it.
+
+### Branching strategy
+
+- Default: Gitflow (`main` + `develop`, feature branches from `develop`).
+- Alternative: GitHub Flow (`main` only, feature branches from `main`).
+- Branch names and PR targets are derived automatically from the chosen strategy — no separate prompt.
+
+### Triage label vocabulary
+
+- Three tiers: state labels, type labels, priority labels.
+- Each tier provides canonical role names internally; the `docs/agents/labels.md` file maps them to actual tracker strings.
+- The `to-issues` and `triage` workflow nodes always use canonical names; a tracker adapter translates at write time.
+
+### README deliverables
+
+The plugin README must include:
+
+1. A Mermaid flowchart showing all six workflows, phase nodes, and human gate markers.
+2. A node reference table: workflow · node · type (prompt/loop/bash/interactive) · human gate (✓ / —).
+3. Quick-start: install + first run in three steps.
+4. Configuration reference: every `.archon/unic-dlc.config.json` key with defaults.
+5. `docs/workflow/` layout diagram.
+6. Dependency map: Archon version requirement, no required peer plugins.
+
+---
+
+## Testing Decisions
+
+### What makes a good test
+
+Tests verify external behaviour — inputs and outputs — not implementation details. A good test for this plugin exercises a module through its public interface and asserts on the observable result without caring how the result was produced internally. Tests should not mock internal collaborators; they should use real inputs and assert on real outputs.
+
+### Modules with tests
+
+**Config loader/validator** — reads `.archon/unic-dlc.config.json`, validates all fields, returns a typed config object or a structured error. Deep module: all config concerns behind a simple `loadConfig(path)` interface. Test: valid config parses correctly; missing mandatory fields return structured errors; unknown keys are ignored.
+
+**Issue tracker adapter** — translates canonical label names to tracker-specific strings and generates create/update CLI commands for each configured backend. Deep module: all tracker-specific knowledge encapsulated. Test: for each backend (GitHub, ADO, Jira, local markdown), canonical label input produces the correct CLI command string.
+
+**Dependency tree builder + YAML generator** — reads `issues.json`, builds the dependency DAG, detects parallel groups, generates a valid Archon YAML file. Deep module: pure data transformation. Test: linear dependency chain produces serial nodes; independent issues produce parallel nodes; circular dependencies are detected and reported; output YAML is valid Archon syntax.
+
+**Setup explorer** — reads project state (git remote, `CLAUDE.md`, `CONTEXT.md`, existing `.archon/`) and returns a structured snapshot of what is already configured. Deep module: all exploration logic isolated. Test: given a mock project directory, returns correct snapshot; missing files are reported as absent, not errored.
+
+### Prior art
+
+- Existing test patterns in this repo use `node:test` built-in runner with `.mjs` test files.
+- See `packages/release-tools/` for examples of pure function tests over file-system utilities.
+
+---
+
+## Out of Scope
+
+- A visual Archon workflow builder UI for `unic-archon-dlc` — YAML files are the authoring format.
+- Integration with Linear — GitHub Issues, ADO, Jira, and local markdown are the supported backends for v1.
+- A managed/hosted version of the workflows — the plugin is self-hosted in the target project.
+- Automatic promotion of issues through states without human approval at gate nodes.
+- A `ralph`-style loop runner for this plugin — the Archon runtime is the execution engine.
+- Translations of the command file prompts into languages other than English.
+- Any UI design contract phase (GSD's 6-pillar UI contract) — out of scope for v1, can be added as a separate command.
+- Cross-AI execution delegation (running `code-green` on a different AI agent than `code-red`).
+
+---
+
+## Further Notes
+
+- The plugin name `unic-archon-dlc` signals both ownership (Unic) and the relationship to Archon (this is an expansion pack, not a standalone tool). The DLC metaphor is intentional.
+- The `explore` workflow is explicitly optional and pre-plan — it can be skipped entirely for well-understood features. Its output feeds `plan` as an optional input; `plan` works without it.
+- Dynamic parallelisation via runtime-generated YAML (`yaml-gen`) means the `build` workflow is never a static file shipped with the plugin — it is always generated fresh per feature. This is a deliberate design: the execution graph reflects the actual dependency tree, not a generic template.
+- GSD's slopsquatting gate requires `slopcheck` (Python tool) to be available on `PATH`. If not installed, the `slopcheck` node defaults to marking every new package as `[ASSUMED]` and creating a human checkpoint — intentionally stricter, not silently permissive.
+- The `triage` workflow doubles as both a standalone on-demand status check and the final node of the `cleanup` workflow. Both invocations produce the same `HANDOFF.md` output.
+- This plugin does not create, copy, or manage `LICENSE` files. The maintainer adds those manually per the monorepo convention.
diff --git a/docs/research/archon-native-to-issues.md b/docs/research/archon-native-to-issues.md
new file mode 100644
index 0000000..a7a7622
--- /dev/null
+++ b/docs/research/archon-native-to-issues.md
@@ -0,0 +1,259 @@
+# Archon Native Workflows — Mapping to `to-issues` Behavior
+
+> **Scope note:** This document explored mapping the `to-issues` behaviour onto native Claude Code workflows (no Archon dependency). The PRD at `docs/issues/unic-archon-dlc/PRD.md` chose the Archon-workflow path instead — `to-issues` is implemented as a node inside `plan.yaml`. Read this doc for historical context; do not use it as implementation guidance for issue 07.
+
+**Research date**: 2026-05-14
+**Archon repo**: https://github.com/coleam00/Archon
+**Workflows live at**: `.archon/workflows/defaults/` (not `workflows/` at root)
+
+---
+
+## What We Need
+
+The `to-issues` skill should:
+
+1. Accept a PRD (file or conversation context) as input
+2. Decompose it into vertically-sliced, independently-grabbable issues
+3. Attach `blocked_by` dependency notes between issues
+4. Validate the breakdown interactively with the user before writing
+5. Write issues to the local markdown tracker (`docs/issues/<slug>/`)
+
+---
+
+## Workflows Examined
+
+### 1. `archon-ralph-dag`
+
+**What it does**: End-to-end PRD→implementation loop using a DAG of user stories.
+
+| Aspect                    | Detail                                                                                                                 |
+| ------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| Input                     | Idea text, `prd.md`, or a directory containing `prd.md` + `prd.json`                                                   |
+| Output                    | Implemented code, committed commits, draft PR                                                                          |
+| Issue decomposition       | Yes — via `archon-ralph-generate` sub-command; produces `prd.json` with `userStories[]` array                          |
+| Dependency handling       | Yes — each story has a `dependsOn: [story-id]` array; the loop selects only stories where all deps have `passes: true` |
+| User validation gate      | No — PRD generation is fully autonomous; no interactive confirmation step                                              |
+| Issue tracker interaction | None — stories live in `.archon/ralph/{slug}/prd.json`, not in a markdown issue tracker                                |
+
+**Story schema (prd.json)**:
+
+```json
+{
+  "id": "US-001",
+  "title": "...",
+  "description": "As a...",
+  "acceptanceCriteria": ["..."],
+  "technicalNotes": "...",
+  "dependsOn": [],
+  "priority": 1,
+  "passes": false,
+  "notes": ""
+}
+```
+
+Dependencies are expressed as `dependsOn: ["US-002"]` (array of story IDs). Priority determines execution order within the DAG: lower priority number = runs first.
+
+**Closeness to `to-issues`**: High on decomposition and dependency DAG. Zero on issue-tracker integration and user validation.
+
+---
+
+### 2. `archon-interactive-prd`
+
+**What it does**: Guided, conversational PRD authoring with three user-confirmation gates.
+
+| Aspect                    | Detail                                                                                |
+| ------------------------- | ------------------------------------------------------------------------------------- |
+| Input                     | Feature idea (free text)                                                              |
+| Output                    | A `prd.md` + a `prd.json` in `$ARTIFACTS_DIR/prds/`                                   |
+| Issue decomposition       | No — stops at the PRD level; does not produce issues or stories                       |
+| Dependency handling       | No                                                                                    |
+| User validation gate      | Yes — three `approval` gates (foundation, deep-dive, scope) before generating the PRD |
+| Issue tracker interaction | None                                                                                  |
+
+**Closeness to `to-issues`**: Excellent user-validation UX, but produces a PRD, not issues. Complementary rather than equivalent.
+
+---
+
+### 3. `archon-create-issue`
+
+**What it does**: Creates a single GitHub issue from a **bug report**, including automated reproduction.
+
+| Aspect                    | Detail                                                    |
+| ------------------------- | --------------------------------------------------------- |
+| Input                     | Bug description                                           |
+| Output                    | One GitHub issue (only if the bug reproduces)             |
+| Issue decomposition       | No — single issue only, no slicing                        |
+| Dependency handling       | No                                                        |
+| User validation gate      | No — gated on reproduction success, not user approval     |
+| Issue tracker interaction | GitHub only (`gh issue create`); not local markdown files |
+
+**Closeness to `to-issues`**: Very different purpose. Single-bug, GitHub-only, no decomposition.
+
+---
+
+### 4. `archon-feature-development`
+
+**What it does**: Implements an existing plan file and creates a PR.
+
+| Aspect                    | Detail                                        |
+| ------------------------- | --------------------------------------------- |
+| Input                     | Path to `$ARTIFACTS_DIR/plan.md`              |
+| Output                    | Implementation + PR                           |
+| Issue decomposition       | No — consumes a plan, does not produce issues |
+| Dependency handling       | N/A                                           |
+| User validation gate      | No                                            |
+| Issue tracker interaction | None                                          |
+
+**Closeness to `to-issues`**: Downstream consumer, not a decomposition tool.
+
+---
+
+### 5. `archon-plan-to-pr`
+
+**What it does**: Executes an existing plan through implementation, 5-agent review, and PR creation.
+
+| Aspect                    | Detail                                                                                                 |
+| ------------------------- | ------------------------------------------------------------------------------------------------------ |
+| Input                     | Path to `plan.md` (created by `archon-create-plan`)                                                    |
+| Output                    | Merged PR                                                                                              |
+| Issue decomposition       | No — plan is a flat task list, not a DAG of issues                                                     |
+| Dependency handling       | No                                                                                                     |
+| User validation gate      | Via `archon-confirm-plan` (verifies that referenced files still exist; it is NOT a design-review gate) |
+| Issue tracker interaction | None                                                                                                   |
+
+**Closeness to `to-issues`**: Not relevant.
+
+---
+
+### 6. `archon-architect`
+
+**What it does**: Codebase health sweep — metrics, analysis, plan, simplify, validate, PR.
+
+| Aspect                    | Detail                                |
+| ------------------------- | ------------------------------------- |
+| Input                     | Optional focus area                   |
+| Output                    | PR with architectural simplifications |
+| Issue decomposition       | No                                    |
+| Dependency handling       | No                                    |
+| User validation gate      | No                                    |
+| Issue tracker interaction | None                                  |
+
+**Closeness to `to-issues`**: Not relevant.
+
+---
+
+### 7. `archon-issue-review-full`
+
+**What it does**: Comprehensive fix + 5-agent code review pipeline for a single GitHub issue.
+
+| Aspect                    | Detail                                       |
+| ------------------------- | -------------------------------------------- |
+| Input                     | GitHub issue number / reference              |
+| Output                    | PR with fixes + review report                |
+| Issue decomposition       | No                                           |
+| Dependency handling       | No                                           |
+| User validation gate      | No                                           |
+| Issue tracker interaction | Reads GitHub, creates PR — not decomposition |
+
+**Closeness to `to-issues`**: Downstream execution, not decomposition.
+
+---
+
+## Sub-commands Relevant to Decomposition
+
+### `archon-ralph-generate` (`.archon/commands/defaults/archon-ralph-generate.md`)
+
+This is the actual decomposition engine used by `archon-ralph-dag`. Key behavior:
+
+- **Phase 4 (Story Breakdown)** explicitly layers stories by: schema/types → backend → UI → integration → tests.
+- Enforces sizing rules: each story must be completable in one AI iteration (~15-30 min).
+- Produces a `dependsOn` array per story (no cycles, lower priority runs first).
+- Acceptance criteria must be pass/fail verifiable, not vague.
+- Writes both `prd.md` (narrative context) and `prd.json` (machine-readable story tracker) to `.archon/ralph/{slug}/`.
+- Runs **fully autonomous** — no user gate.
+
+### `archon-create-plan` (`.archon/commands/defaults/archon-create-plan.md`)
+
+- Produces a flat `plan.md` with sequential tasks (not a DAG).
+- No dependency graph; tasks are ordered by execution necessity.
+- No issue tracker integration.
+
+---
+
+## Gap Analysis
+
+| Requirement                                                | `archon-ralph-generate`                       | `archon-interactive-prd`   | Neither — needs custom |
+| ---------------------------------------------------------- | --------------------------------------------- | -------------------------- | ---------------------- |
+| Accept PRD input                                           | Yes                                           | Yes (produces PRD)         |                        |
+| Vertical slice decomposition                               | Yes (layered: schema→backend→UI)              | No                         |                        |
+| `blocked_by` / dependency graph                            | Yes (`dependsOn` per story)                   | No                         |                        |
+| User validation gate before writing                        | **No**                                        | Yes (3-gate approval flow) |                        |
+| Write to local markdown tracker (`docs/issues/<slug>/`)    | **No** (uses `.archon/ralph/{slug}/prd.json`) | **No**                     | Yes                    |
+| Issues as standalone markdown files                        | **No**                                        | **No**                     | Yes                    |
+| Dependency expressed as `blocked_by` in issue front-matter | **No** (uses `dependsOn` ID refs inside JSON) | **No**                     | Yes                    |
+
+---
+
+## Assessment: Closest Native Workflow
+
+**`archon-ralph-generate` is the closest native analog** to `to-issues` decomposition behavior.
+
+It provides:
+
+- Principled vertical slicing (schema → backend → UI → integration)
+- Explicit dependency DAG (`dependsOn[]` per story)
+- Sizing discipline (one AI iteration per story)
+- Verifiable acceptance criteria rules
+
+It is missing:
+
+- A user-confirmation gate before committing the breakdown
+- Writing to the local markdown issue tracker (`docs/issues/<slug>/issue.md`)
+- The `blocked_by` front-matter field that our issue format uses
+- The 8-state triage label vocabulary (`needs-triage` → `ready-for-agent` etc.)
+
+**`archon-interactive-prd`** provides the missing user-gate UX (3-phase `approval` nodes) but does not slice into issues at all.
+
+---
+
+## Recommendation
+
+### Option A — Adapt `archon-ralph-generate` (preferred)
+
+Adapt the decomposition logic from `archon-ralph-generate` as the core of a new `to-issues` skill:
+
+1. **Import the layering + sizing discipline** verbatim (Phase 4 of `archon-ralph-generate`).
+2. **Add one `approval` gate** (borrowed from `archon-interactive-prd`) after the AI produces the draft story list and before any files are written — letting the user review, reorder, or veto slices.
+3. **Replace the output target**: instead of `.archon/ralph/{slug}/prd.json`, write one markdown file per issue to `docs/issues/<slug>/issue.md` using our issue template.
+4. **Map the dependency format**: `dependsOn: ["US-002"]` → `blocked_by: [other-slug]` in the issue front-matter.
+5. **Apply the triage label**: new issues get `needs-triage` by default, or `ready-for-agent` if the user confirms them during the gate.
+
+This approach means we reuse ~70% of the decomposition logic (the hardest part to design) and only need to write:
+
+- The user-gate node
+- The output formatter (JSON story → markdown issue)
+- The dependency slug resolver
+
+### Option B — Build from scratch
+
+Only warranted if the Archon decomposition logic is too Archon-specific (e.g., hard-coded to Bun/TypeScript projects). Reading `archon-ralph-generate`, the decomposition phases (Phases 1-4) are project-agnostic — they read `CLAUDE.md` to adapt to any codebase. So scratch-build is not justified.
+
+### Option C — Shell out to `archon-ralph-generate`
+
+The `to-issues` skill could invoke `archon-ralph-dag` with `--dry-run` or similar. This is not viable: `archon-ralph-dag` has no dry-run mode and immediately starts implementation. The decomposition command (`archon-ralph-generate`) is an Archon CLI internal; it is not independently invokable from a Claude Code skill.
+
+---
+
+## Summary Table
+
+| Workflow                                         | Decomposition | Dependency DAG |  User Gate   |     Issue Tracker      | Verdict                                 |
+| ------------------------------------------------ | :-----------: | :------------: | :----------: | :--------------------: | --------------------------------------- |
+| `archon-ralph-dag` (via `archon-ralph-generate`) |      Yes      |      Yes       |      No      | `.archon/ralph/*.json` | **Best base — adapt output + add gate** |
+| `archon-interactive-prd`                         |      No       |       No       | Yes (3-gate) |          None          | Good UX pattern for the gate node       |
+| `archon-create-issue`                            |      No       |       No       |      No      |      GitHub only       | Not relevant                            |
+| `archon-feature-development`                     |      No       |       No       |      No      |          None          | Not relevant                            |
+| `archon-plan-to-pr`                              |      No       |       No       |      No      |          None          | Not relevant                            |
+| `archon-architect`                               |      No       |       No       |      No      |          None          | Not relevant                            |
+| `archon-issue-review-full`                       |      No       |       No       |      No      |     GitHub (reads)     | Not relevant                            |
+
+**Bottom line**: No native Archon workflow covers the full `to-issues` behavior. The right path is to adapt the decomposition logic from `archon-ralph-generate` (layered slicing + `dependsOn` DAG), bolt on a single user-approval gate from `archon-interactive-prd`'s pattern, and replace the `.archon/ralph/` output with our local markdown issue format. A custom workflow is required, but it is not a ground-up build — roughly two-thirds of the design already exists in Archon.
diff --git a/docs/research/archon-vs-native-skills.md b/docs/research/archon-vs-native-skills.md
new file mode 100644
index 0000000..b7d335a
--- /dev/null
+++ b/docs/research/archon-vs-native-skills.md
@@ -0,0 +1,328 @@
+# Archon vs Native Claude Code Primitives
+
+**Research question:** Can the `unic-archon-dlc` workflow be implemented entirely with native Claude Code primitives, dropping Archon as a runtime dependency?
+
+**Scope:** The six-workflow DLC (explore, plan, build, qa, cleanup, triage) as specified in `docs/issues/unic-archon-dlc/PRD.md`.
+
+**Date:** 2026-05-14
+
+---
+
+## Part 1 — Claude Code Native Primitives (what this repo actually has)
+
+### Execution primitives
+
+| Primitive                             | Mechanism                                                                                                                                | Evidence in repo                                                                              |
+| ------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
+| **Subagent spawning**                 | `Agent tool` with `subagent_type: general-purpose`                                                                                       | `implement-feature` SKILL.md step 4; `/tdd` AFK prompt template                               |
+| **Sequential DAG (topological)**      | Skill reads `## Blocked by` edges, computes topo sort in-context, calls subagents one at a time                                          | `implement-feature` SKILL.md steps 3–6; `docs/agents/feature-runner.md`                       |
+| **Loop with exit condition**          | `ralph-loop` plugin (Stop hook intercepts exit, re-feeds prompt); `LOOP_COMPLETE` signal pattern; `/loop /implement-feature` composition | `ralph/afk.sh`; `ralph/PROMPT.md`; ralph-loop plugin README                                   |
+| **AFK batch runner**                  | `ralph/afk.sh` — docker sandbox, `--print --output-format stream-json`, iterates N times, stops on `<promise>LOOP_COMPLETE</promise>`    | `ralph/afk.sh`; `ralph/once.sh`                                                               |
+| **Session-scoped recurring task**     | `CronCreate` tool — in-memory cron, fires while REPL is idle, auto-expires in 7 days                                                     | Deferred tool schema                                                                          |
+| **Persistent remote-scheduled agent** | `RemoteTrigger` tool — creates claude.ai routines with cron schedules that survive session exit                                          | Deferred tool schema                                                                          |
+| **Isolated branch per feature**       | `EnterWorktree` / `ExitWorktree` tools + `git worktree add .claude/worktrees/<slug>`                                                     | `implement-feature` SKILL.md step 2; `feature-runner.md`                                      |
+| **Bash nodes**                        | `Bash tool` inside any skill/agent; hooks (PreToolUse, PostToolUse) run Node.js scripts on every file edit                               | `.claude/hooks/block-lockfile.mjs`; `.claude/hooks/test-on-edit.mjs`; `.claude/settings.json` |
+| **Hook-triggered side effects**       | `PreToolUse` / `PostToolUse` hooks — run arbitrary Node.js scripts before/after any tool call                                            | `.claude/settings.json`                                                                       |
+
+### State / persistence primitives
+
+| Primitive                          | Mechanism                                                                                                      |
+| ---------------------------------- | -------------------------------------------------------------------------------------------------------------- |
+| **Cross-session persistence**      | Markdown files committed to git (`docs/issues/`, `docs/workflow/`) — agents read them at start of each session |
+| **Transient within-session state** | In-context memory; temp files the skill writes and reads during one run                                        |
+| **Status machine**                 | 8-state vocabulary encoded in `**Status:**` frontmatter of issue `.md` files                                   |
+| **Durable cron jobs**              | `CronCreate` with `durable: true` — persists to `.claude/scheduled_tasks.json`, survives restart               |
+
+### Human interaction primitives
+
+| Primitive                     | Mechanism                                                                                                                 |
+| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
+| **Interactive gate (HITL)**   | Issue `**Type:** HITL` — `ralph/PROMPT.md` explicitly skips HITL issues; human resolves them manually before next AFK run |
+| **HITL bash script template** | `diagnose/scripts/hitl-loop.template.sh` — structured step/capture helpers for human-in-the-loop shell sessions           |
+| **Approval before PR**        | `implement-feature` runs unattended but opens a PR — GitHub/ADO PR review is the approval gate                            |
+
+### Skills available as workflow nodes
+
+Skills are loaded by the `Skill tool` inside any Agent call. The following are installed and relevant:
+
+- `/tdd` — red-green-refactor loop, used as the implementation node in `implement-feature`
+- `/grill-with-docs` — adversarial interview that writes ADRs live (maps to the `specs` node)
+- `/grill-me` — general design interview (maps to early `specs` node)
+- `/to-prd` — synthesise session into a PRD (maps to the `to-prd` node)
+- `/to-issues` — decompose PRD into vertically-sliced issues (maps to the `to-issues` node)
+- `/triage` — 8-state issue lifecycle management
+- `/improve-codebase-architecture` — post-implementation arch review (maps to `arch-review`)
+- `/diagnose` — systematic debugging loop
+- `/implement-feature` — topological issue runner (maps to the `build` workflow)
+- `/verify-spec` — check acceptance criteria against codebase
+
+### What is NOT a native primitive
+
+- No declarative DAG file format (no YAML runtime)
+- No named node types in a schema (prompt / loop / bash / interactive are informal categories, not runtime constructs)
+- No `$ARTIFACTS_DIR` convention — agents write to arbitrary paths they agree on
+- No built-in parallel fan-out within a single session (true simultaneity requires multiple running `claude` processes)
+- No loop node with a configurable `max_iterations` field in a config file — must be encoded in skill prose or passed as a `--max-iterations` flag to `ralph-loop`
+- No interactive node schema — HITL is a convention (issue type field + manual step), not a runtime gate that pauses and waits
+
+---
+
+## Part 2 — Archon Primitives
+
+Based on Archon (github.com/coleam00/Archon) documentation and the PRD's design decisions:
+
+### Core runtime concepts
+
+| Archon concept                  | What it does                                                                                                                           |
+| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| **YAML DAG**                    | Workflow defined as a `.yaml` file with named nodes, `depends_on` edges, `type:` field                                                 |
+| **Node types**                  | `prompt` (LLM call), `loop` (repeat until condition or max iterations), `bash` (shell command), `interactive` (pause for human input)  |
+| **`depends_on`**                | Explicit dependency edge between nodes — Archon resolves execution order and runs nodes in parallel when no dependency exists          |
+| **Parallel execution**          | Nodes with no shared dependency run concurrently by the runtime — no extra scripting needed                                            |
+| **`interactive: true` node**    | Runtime pauses, presents output to human in the Archon UI, resumes after approval — a first-class synchronous gate                     |
+| **`loop` node**                 | Runs a child node repeatedly, with `condition:` (exit when true) and `max_iterations:` (hard cap) as YAML fields                       |
+| **`$ARTIFACTS_DIR`**            | Runtime-managed ephemeral directory per workflow run — all nodes share it, nothing is committed                                        |
+| **Command files**               | `.md` files that define an Archon slash-command; analogous to Claude Code `.claude/commands/`                                          |
+| **Dynamic workflow generation** | A `bash` node can write a new `.yaml` file to `.archon/workflows/`; the runtime can then invoke it (the `yaml-gen` pattern in the PRD) |
+
+### Key architectural property
+
+Archon is an **external runtime** that runs workflows, not a model-side construct. The YAML DAG is parsed by the Archon process; Claude is called as a tool inside each `prompt` node. This means:
+
+- Parallelism is real OS-level concurrency (multiple Claude calls in-flight simultaneously)
+- Human gates (`interactive: true`) pause the Archon process, not the Claude context window
+- `$ARTIFACTS_DIR` is a filesystem path managed by Archon, not an in-context convention
+- Loop state (iteration count, last result) is tracked by the Archon process
+
+---
+
+## Part 3 — Gap Analysis
+
+For each of the 8 workflow requirements:
+
+### Req 1 — Parallel execution (4 research agents simultaneously)
+
+**Archon:** Native. Nodes with no `depends_on` run in parallel by the runtime. The explore workflow's four research agents (stack, features, architecture, pitfalls) are simply four sibling nodes.
+
+**Claude Code native:**
+
+- `implement-feature` runs issues sequentially, one at a time (topological order, single agent at a time).
+- True parallelism would require spawning multiple `claude` processes from a bash script (e.g., `afk.sh`-style with `&` and `wait`), or calling the Claude API directly from a Node.js orchestrator.
+- The `Agent tool` inside a skill can only be called sequentially within one Claude session — there is no "call four Agents in parallel" capability natively.
+- The `ralph-loop` pattern and `implement-feature` are single-threaded by design.
+
+**Verdict:** Gap. Achievable with a custom Node.js orchestrator that spawns four `claude --print` processes in parallel and collects their outputs, but this is substantial custom infrastructure — not a native primitive.
+
+---
+
+### Req 2 — Sequential DAG with dependency resolution
+
+**Archon:** Native via `depends_on` edges in YAML. Runtime resolves order automatically.
+
+**Claude Code native:**
+
+- `implement-feature` implements this fully in skill prose: reads `## Blocked by` from each issue file, computes topological sort in-context, executes issues in that order.
+- Conflict detection, missing-blocker check, and unsatisfied-dependency check are all implemented.
+- The DAG is derived from markdown files, not a YAML schema, but the behaviour is equivalent for serial execution.
+
+**Verdict:** Covered. The `implement-feature` skill already solves this for serial execution. The gap is only parallelism (Req 1), not ordering.
+
+---
+
+### Req 3 — Loop nodes (repeat until condition, max iterations)
+
+**Archon:** Native. `type: loop` with `condition:` and `max_iterations:` as YAML fields. Stall detection requires custom logic inside the loop body.
+
+**Claude Code native:**
+
+- `ralph-loop` plugin implements this via a Stop hook: intercepts exit, re-feeds the same prompt, stops on a completion promise string or `--max-iterations`.
+- The `plan-checker` loop in the PRD (max 3 iterations, stall detection) maps cleanly onto `ralph-loop` with `--max-iterations 3` and a completion promise, plus inline stall detection logic written into the skill.
+- `implement-feature` uses a `LOOP_COMPLETE` signal + `/loop` composition for the outer queue-drain loop.
+
+**Verdict:** Covered. `ralph-loop` covers the loop primitive. Stall detection and iteration-count checks are written into skill prose — more verbose than a YAML field, but functionally equivalent.
+
+---
+
+### Req 4 — Interactive gates (pause, present to human, resume)
+
+**Archon:** Native. `interactive: true` on any node suspends the Archon process and presents output in the UI. The human clicks approve/reject and the process resumes.
+
+**Claude Code native:**
+
+- No equivalent runtime gate exists. The closest pattern in this repo is the HITL issue type: an issue is tagged `**Type:** HITL`; the AFK runner skips it; the human resolves it manually; the next AFK iteration sees it resolved.
+- This is asynchronous and session-boundary-crossing: the human approval happens between two separate `ralph` iterations, not within one.
+- The `hitl-loop.template.sh` is for a human following a bash script to capture input — it does not pause a running agent.
+- For synchronous interactive gates within a running session, there is no primitive. A skill could emit a question and wait for the human to type, but only in the interactive (non-AFK) mode.
+
+**Verdict:** Partial gap. Asynchronous gates (across sessions) are handled by the HITL issue convention. Synchronous gates (pause a running AFK workflow mid-execution, wait for approval, resume) require either (a) running interactively rather than AFK, or (b) a custom orchestrator that polls for a "gate file" written by the human. This is the most significant functional gap.
+
+---
+
+### Req 5 — State persistence (survive session boundaries, resume AFK runs)
+
+**Archon:** `$ARTIFACTS_DIR` for transient state; workflows can write to the project repo for persistence. Session boundary survival depends on Archon process management.
+
+**Claude Code native:**
+
+- This is a strength of the native approach: all state lives in git-committed markdown files (`docs/issues/<slug>/`, `docs/workflow/<slug>/`).
+- `implement-feature` explicitly handles resumption: if `.claude/worktrees/<slug>` already exists, it reuses the worktree and skips already-`resolved` issues.
+- `ralph/afk.sh` re-reads all issue files on every iteration — state is always read from disk, never from in-context memory.
+- `CronCreate` with `durable: true` persists scheduled tasks to `.claude/scheduled_tasks.json` and survives restart.
+- `RemoteTrigger` routines survive session exit entirely (server-side scheduling).
+
+**Verdict:** Covered, and arguably stronger than Archon here. The git-based state model means state survives not just session boundaries but also machine reboots, re-clones, and context window resets. Archon's `$ARTIFACTS_DIR` is ephemeral by design.
+
+---
+
+### Req 6 — Bash nodes (git, gh, az, slopcheck as first-class steps)
+
+**Archon:** Native. `type: bash` node runs a shell command. Output is captured and available to subsequent nodes as a named artifact.
+
+**Claude Code native:**
+
+- The `Bash tool` is available inside any skill or agent invocation. Agents routinely call `git`, `gh`, `pnpm`, etc.
+- `test-on-edit.mjs` and `block-lockfile.mjs` hooks show that bash-equivalent logic (Node.js scripts) can be triggered automatically on tool use events.
+- `PreToolUse` / `PostToolUse` hooks can run any shell command before or after any tool call.
+- The `slopcheck` pattern (check package names before install) can be implemented as a `PreToolUse` hook on `Bash(npm install:*)` / `Bash(pnpm add:*)`.
+
+**Verdict:** Covered. Every Archon `bash` node maps to a `Bash tool` call inside a skill. Hooks provide the "always-on" bash node equivalent for cross-cutting concerns.
+
+---
+
+### Req 7 — Dynamic workflow generation (`issues.json` → `run-<slug>.yaml`)
+
+**Archon:** The `yaml-gen` bash node writes a new `.yaml` workflow file at runtime. Archon can then invoke it.
+
+**Claude Code native:**
+
+- The `implement-feature` skill already does the dynamic equivalent: it reads `## Blocked by` edges from issue markdown files, builds a topological execution queue at runtime, and runs it.
+- There is no YAML file generated — the DAG is computed in-context and executed directly.
+- For the specific `yaml-gen` → `run-<slug>.yaml` pattern (generating a file that a runtime then reads), this would be unnecessary in the native model: the orchestrator skill reads the dependency tree directly and drives execution without an intermediate file.
+- If a YAML representation is desired for auditability (e.g., to commit `run-<slug>.yaml` to the repo as a record), a bash node/skill could write it — but nothing would "read and execute" it; it would just be a documentation artifact.
+
+**Verdict:** Covered differently. Archon needs the YAML because the runtime is separate from the LLM. Native Claude Code collapses the orchestrator and the executor into the same agent — there is no separate runtime to hand the YAML to. The dynamic parallelisation logic lives in skill prose rather than a generated file. This is simpler but less auditable.
+
+---
+
+### Req 8 — Subagent spawning (each node spawns specialized subagents)
+
+**Archon:** Each node is an isolated LLM call with its own system prompt, context, and tool access. "Subagent" is implicit — every node is effectively a fresh agent call.
+
+**Claude Code native:**
+
+- The `Agent tool` with `subagent_type: general-purpose` spawns a subagent that has access to all tools including the `Skill tool`.
+- `implement-feature` uses this explicitly: each issue is handed to a subagent via `Agent tool`, which then loads `/tdd` via the `Skill tool` and runs it.
+- Skills can be composed: the subagent prompt tells it to load `/tdd`, `/grill-with-docs`, `/to-issues`, etc.
+- The subagent receives a constructed prompt (the tdd-prompt-template) rather than sharing the parent's context window, which is equivalent to Archon's per-node isolation.
+
+**Verdict:** Covered. The `Agent tool` is the native subagent primitive. It is already used for this purpose in `implement-feature`. The main difference is that Claude Code subagents are serial (Req 1 gap), while Archon nodes can run in parallel.
+
+---
+
+## Part 4 — Trade-off Summary
+
+### What you gain by being Archon-free
+
+**1. No runtime dependency to install and maintain**
+Archon must be on PATH in every target project. The install hook must verify it. Version drift between Archon and the plugin's YAML schema creates upgrade friction. Going native means `claude` is the only dependency — already required.
+
+**2. Git is the state machine**
+Archon's `$ARTIFACTS_DIR` is ephemeral. The native model stores everything in committed markdown, making state inspectable, diffable, and recoverable from any git checkout. This is a genuine advantage for long AFK runs.
+
+**3. Simpler mental model for contributors**
+The YAML DAG schema is an additional layer contributors must learn: node types, `depends_on` semantics, `interactive:` flags, `$ARTIFACTS_DIR` naming conventions. Native skills are just markdown with prose instructions — the same format contributors already use for everything else in this repo.
+
+**4. Cross-platform by construction**
+The monorepo's cross-platform requirement (macOS, Windows, Linux) is already met by Node.js hooks and pnpm. Archon's platform compatibility is a separate concern outside this repo's control.
+
+**5. Composable with existing skills**
+Native skills are already installed and working: `/grill-with-docs`, `/to-issues`, `/triage`, `/implement-feature`. A native DLC orchestrator would call these directly without re-implementing their logic in YAML nodes. Archon workflows would re-implement equivalent behaviour in isolation.
+
+**6. No `$ARTIFACTS_DIR` coordination overhead**
+Archon workflows that need to pass data between nodes must write to `$ARTIFACTS_DIR` with agreed filenames. Native agents pass data through the prompt context or git-committed files — no cross-node artifact naming convention required.
+
+---
+
+### What you lose or must build
+
+**1. True parallel execution — must build**
+Archon runs sibling nodes concurrently at the OS level. Native Claude Code has no equivalent. To run four research agents simultaneously, a custom orchestrator must spawn four `claude --print` subprocesses in parallel and collect their outputs. This is a ~50–100 line Node.js script (or bash with `&`/`wait`), but it is not a primitive — it must be built, tested, and maintained. Without it, the four explore agents run sequentially, making the explore workflow 4x slower.
+
+**2. Synchronous interactive gates — must build or redesign**
+Archon's `interactive: true` pauses a running workflow and waits for human approval inline. Native Claude Code has no synchronous pause primitive in AFK mode. Options:
+
+- **Redesign as async gates:** split the workflow at each gate boundary into two separate runs. The first run writes a "gate file" or sets an issue to `ready-for-human`; the human approves and sets it to `ready-for-agent`; the second run picks up. This is the existing HITL convention and works well for planned gates, but requires the human to actively restart the run rather than clicking "approve" in a UI.
+- **Run interactively at gate points:** the `ralph-loop` can be configured to not re-loop past a certain prompt, forcing the session to go interactive at gate boundaries. This is less clean than Archon's UI but functional.
+- **Custom gate polling:** a bash node writes a gate file; a cron job or loop polls until a human edits the file; execution resumes. This is fragile and not recommended.
+
+For the PRD's five explicit PR gates (after PRD, after plan-checker, after report, after UAT, per-ADR in cleanup), the async redesign is the right answer — these are naturally session-boundary events anyway.
+
+**3. Declarative workflow schema — must decide if needed**
+Archon provides a YAML file per workflow that is auditable, shareable, and human-readable as a process spec. Native skills encode the same logic in prose inside `SKILL.md`. This is a documentation trade-off, not a capability gap. If workflow auditability is important (e.g., for compliance or onboarding), a custom YAML schema for documentation purposes could be written separately from the execution layer, but nothing would "run" it — it would be a companion spec, not a DAG executor.
+
+**4. Explicit artifact hand-off between phases — must define convention**
+Archon's `$ARTIFACTS_DIR` is a named, scoped, automatically cleaned-up directory shared between nodes in one run. Native agents writing to `docs/workflow/<slug>/` achieve the same persistence but without automatic scoping or cleanup. The convention must be defined and enforced by skill prose (already done in the PRD's "Persistent artifact layout" section).
+
+**5. `slopcheck` integration — must build**
+The `slopcheck` bash node in the PRD calls an external Python tool. Native implementation requires either (a) a `PreToolUse` hook on `Bash(pnpm add:*)` that runs `slopcheck`, or (b) a skill step that explicitly calls `slopcheck` before any install command. Option (a) is more robust and is the natural hook-based pattern for this repo.
+
+---
+
+### Recommendation matrix
+
+| Requirement                 | Archon                              | Native                               | Build cost if native                               |
+| --------------------------- | ----------------------------------- | ------------------------------------ | -------------------------------------------------- |
+| Parallel execution          | Native, zero cost                   | Gap — must build                     | Medium (parallel subprocess orchestrator ~100 LOC) |
+| Sequential DAG              | Native                              | Covered (`implement-feature`)        | None                                               |
+| Loop nodes                  | Native                              | Covered (`ralph-loop`)               | None                                               |
+| Interactive gates (sync)    | Native                              | Partial gap — redesign as async      | Low (async HITL convention already exists)         |
+| State persistence           | Native (ephemeral `$ARTIFACTS_DIR`) | Better (git-committed markdown)      | None — advantage                                   |
+| Bash nodes                  | Native                              | Covered (`Bash tool`, hooks)         | None                                               |
+| Dynamic workflow generation | Native                              | Covered differently (in-context DAG) | None — no YAML file needed                         |
+| Subagent spawning           | Native                              | Covered (`Agent tool`)               | None                                               |
+
+**Net verdict:** 6 of 8 requirements are covered natively with zero build cost. The two gaps are:
+
+1. **Parallel execution** — medium build cost, real performance difference (4× slower explore phase without it).
+2. **Synchronous interactive gates** — low redesign cost; the async HITL convention already in this repo is a viable substitute and arguably more appropriate for long AFK workflows.
+
+---
+
+### Recommended path
+
+**Drop Archon. Build one thin parallel orchestrator.**
+
+The native approach covers everything except true parallelism. For the explore workflow's four-agent fan-out, build a `parallel-agents.mjs` helper (a thin Node.js wrapper that spawns N `claude --print` subprocesses, waits for all to complete, and concatenates their outputs into a single artifact file). This becomes one reusable utility that can be called from any skill via the `Bash tool`.
+
+All five interactive gates should be redesigned as async HITL checkpoints using the existing issue-status convention. Each gate becomes an issue with `**Type:** HITL` that the human resolves before the next run phase begins. This is already the model used everywhere else in this repo.
+
+The result is a plugin that:
+
+- Ships no external runtime dependency
+- Stores all state in git (inspectable, resumable, diffable)
+- Uses the same skill/hook/worktree primitives contributors already know
+- Requires one new ~100 LOC Node.js utility for parallel fan-out
+- Trades Archon's synchronous UI gate for the repo's established async HITL convention
+
+---
+
+## Appendix — Primitive inventory used in this analysis
+
+| File / location                                 | Primitive demonstrated                                                                               |
+| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
+| `.claude/skills/implement-feature/SKILL.md`     | Sequential DAG, topo sort, subagent spawning via Agent tool, worktree creation, LOOP_COMPLETE signal |
+| `docs/agents/feature-runner.md`                 | Feature runner lifecycle, HITL convention, resumption model                                          |
+| `ralph/afk.sh`                                  | AFK loop runner, docker sandbox, LOOP_COMPLETE detection                                             |
+| `ralph/once.sh`                                 | Single-iteration interactive runner                                                                  |
+| `ralph/PROMPT.md`                               | Orchestrator prompt: task selection, AFK vs HITL split, topo execution                               |
+| `.claude/settings.json`                         | PreToolUse / PostToolUse hook configuration                                                          |
+| `.claude/hooks/test-on-edit.mjs`                | PostToolUse bash node pattern (run tests on file edit)                                               |
+| `.claude/hooks/block-lockfile.mjs`              | PreToolUse guard node pattern                                                                        |
+| `CronCreate` deferred tool                      | Session-scoped and durable cron scheduling                                                           |
+| `RemoteTrigger` deferred tool                   | Server-side persistent routine scheduling                                                            |
+| `EnterWorktree` / `ExitWorktree` deferred tools | Worktree session management                                                                          |
+| `docs/issues/unic-archon-dlc/PRD.md`            | Full plugin specification, Archon concepts, design decisions                                         |
+
+---
+
+**Decision note (post-research):** The "native-first" option evaluated above was considered and rejected. The PRD at `docs/issues/unic-archon-dlc/PRD.md` documents the decision to keep Archon as the runtime for the DLC plugin. The Archon YAML DAG, `interactive: true` nodes, and `$ARTIFACTS_DIR` are load-bearing parts of the design.
diff --git a/skills-lock.json b/skills-lock.json
index 87938a4..d9c16b6 100644
--- a/skills-lock.json
+++ b/skills-lock.json
@@ -23,7 +23,13 @@
       "source": "mattpocock/skills",
       "sourceType": "github",
       "skillPath": "skills/engineering/grill-with-docs/SKILL.md",
-      "computedHash": "31a5b1ae116558bf7d3f633f442835f54bd7645923d4f45c7823e52a97317666"
+      "computedHash": "1adf321072f53cce3dcaf5357d91b8230d4aa647bb8a51756745337a6ee567b8"
+    },
+    "handoff": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/productivity/handoff/SKILL.md",
+      "computedHash": "d543685cbfb0c64b7bc51a8dc3465975528da9b64f987f863765973b2f3867ab"
     },
     "improve-codebase-architecture": {
       "source": "mattpocock/skills",
@@ -31,11 +37,17 @@
       "skillPath": "skills/engineering/improve-codebase-architecture/SKILL.md",
       "computedHash": "c77b86b4332919499608f9af1880074e1fec65a59b95c70c27a9f39cd137865e"
     },
+    "prototype": {
+      "source": "mattpocock/skills",
+      "sourceType": "github",
+      "skillPath": "skills/engineering/prototype/SKILL.md",
+      "computedHash": "e4d0c8f8cb3fc096ee99405a15491da466545cf4a3694bee5a0c9db2fa621a43"
+    },
     "setup-matt-pocock-skills": {
       "source": "mattpocock/skills",
       "sourceType": "github",
       "skillPath": "skills/engineering/setup-matt-pocock-skills/SKILL.md",
-      "computedHash": "3a32f8f1ed8160c9d286a2aabe88ee9b884c6f3f88a7a6c47b7d5d552c959587"
+      "computedHash": "0164a8b1ef998abca426056c6ed8a7716a9d4692fc6daa5378f68381a6dafd24"
     },
     "tdd": {
       "source": "mattpocock/skills",
@@ -47,13 +59,13 @@
       "source": "mattpocock/skills",
       "sourceType": "github",
       "skillPath": "skills/engineering/to-issues/SKILL.md",
-      "computedHash": "73a91f30784523aa59ec9b02769576ebfc738e2cd5ad8f6441076031f0a5d5ac"
+      "computedHash": "47f648f3414848ccfc62cb41d2828b7e575fb5e7cbd6c4bdf630c063b5dc5e82"
     },
     "to-prd": {
       "source": "mattpocock/skills",
       "sourceType": "github",
       "skillPath": "skills/engineering/to-prd/SKILL.md",
-      "computedHash": "fd8c259f9c44eff08e29a1a2fc71a806a3568d279a55387a361f78620b10f2aa"
+      "computedHash": "6d741474efd4bc3db55fabc2722ed78ca9c374cabcb6212936d79d4fd4a30fcb"
     },
     "triage": {
       "source": "mattpocock/skills",