docs: add canonical glossary + install mattpocock skills adapted for repo

docs/glossary.md is the shared vocabulary source for humans and agents.
Resolves every cross-cutting term used in this repo (feature, use case,
manifest, slice, conformance, dispatch, ...) with one-sentence definitions,
relationships, and flagged ambiguities. Linked from CLAUDE.md "Read First"
and AGENTS.md preamble so every session loads it early.

.claude/skills/ installs four mattpocock skills adapted to this monorepo:
  - to-prd: writes to docs/work/prds/ with the repo's PRD frontmatter +
    merged user-stories/implementation/testing sections
  - grill-with-docs: points at docs/decisions/ + docs/glossary.md; adds
    feature.manifest.ts + conformance-rule cross-checks
  - grill-me: minor — adds pnpm work / fallow / manifest shortcuts
  - handoff: adds the repo's specific don't-duplicate artifacts list

Also fixes a missed "Phase-1" residual in CLAUDE.md's Read First section.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.claude/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: grill-with-docs
+description: Stress-test a plan against this repo's domain glossary, ADRs, conformance rules, and feature manifests. Update docs/glossary.md inline as terms crystallize; offer ADRs sparingly. Use when the user wants to harden a plan before it becomes a PRD.
+---
+
+<what-to-do>
+
+Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions **one at a time**, waiting for feedback on each before continuing.
+
+If a question can be answered by exploring the codebase, explore the codebase instead of asking. The repo has fast feedback loops — run `pnpm work status`, grep manifests, read feature `feature.manifest.ts`, check ADRs. Speculation is a last resort.
+
+</what-to-do>
+
+<supporting-info>
+
+## Repo doc map
+
+This repo uses a **single context** with these doc locations:
+
+```
+/
+├── docs/
+│   ├── glossary.md                 ← lazy-create when first term resolves
+│   ├── decisions/                  ← ADRs (adr-NNN-<slug>.md, 3-digit zero-pad)
+│   │   ├── adr-001-monorepo-tool.md
+│   │   ├── adr-018-audit-and-compliance.md
+│   │   └── ...
+│   ├── architecture/               ← long-form specs + workflow design
+│   ├── work/                       ← PRDs, epics, stories, tasks
+│   └── guides/                     ← how-to runbooks
+└── packages/<feature>/src/feature.manifest.ts   ← per-feature contract
+```
+
+There is **no `CONTEXT.md` or `CONTEXT-MAP.md`** — this repo uses `docs/glossary.md` (create lazily) plus the per-feature `feature.manifest.ts` files for machine-readable domain shape. Don't create the multi-context layout (`CONTEXT-MAP.md`) unless this becomes a polyrepo.
+
+## During the session
+
+### Challenge against the glossary + manifests
+
+When the user introduces a term that conflicts with `docs/glossary.md` (if it exists) or with a `feature.manifest.ts` entry, call it out immediately:
+
+> "Your glossary defines `cancellation` as the act of voiding an unsent invoice, but you seem to mean the user-initiated subscription teardown — which is it?"
+
+> "`auth.signIn` exists in `packages/auth/src/feature.manifest.ts` with that exact slug — are you adding a new use case or extending the existing one?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term:
+
+> "You're saying `account` — do you mean a `User` (entity in `packages/auth`) or a Payload-collection record? Those are distinct."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent edge cases that force precision about boundaries between concepts. Lean on the existing feature set — auth, blog, media, marketing-pages, navigation — for grounding examples.
+
+### Cross-reference with code
+
+When the user states how something works, verify it against the code. Look at:
+
+- The feature's `feature.manifest.ts` for declared use cases, audits, publishes, consumes
+- `packages/<feature>/src/application/use-cases/` for the actual shape
+- `packages/<feature>/src/di/bind-production.ts` for what's wired
+- `docs/decisions/adr-NNN-*.md` for the decision history
+
+If you find a contradiction, surface it:
+
+> "You said cross-feature reactions happen through the bus, but `packages/auth/src/feature.manifest.ts` shows `publishes: []` — has this been wired yet?"
+
+### Cross-reference with ADRs
+
+Before recommending an approach, scan `docs/decisions/` for relevant ADRs. If your recommendation contradicts a current-status ADR, surface that explicitly:
+
+> "You're proposing direct cross-feature imports, but `adr-006-vertical-feature-packages.md` plus rule R20 in the ESLint config forbid that — events (`core-events`) are the sanctioned path. Want to use events, or do you want to reopen the ADR?"
+
+### Cross-reference with conformance rules
+
+The conformance system (`docs/architecture/agent-first-workflow-and-conformance.md`) defines hard contracts:
+
+- Every use case has a manifest entry → contracts → tests → impl (in that order)
+- TS brands (`Instrumented`, `Captured`, `Audited`) attached at DI bind time
+- ESLint rules enforce manifest ↔ code alignment
+- `pnpm conformance` enforces cross-feature event closure
+
+If the plan would violate any of these, flag it.
+
+### Update `docs/glossary.md` inline
+
+When a term is resolved during the conversation, append it to `docs/glossary.md` right then — don't batch. Lazy-create the file when the first term is resolved. Use the format in [glossary-format.md](./glossary-format.md).
+
+Only include terms meaningful to **this repo's domain** (template / monorepo / agent-first workflow / clean architecture / vertical features). Skip general programming concepts. Skip implementation details — those belong in code or ADRs.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **Result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any is missing, skip the ADR. The repo's ADRs follow a long-form `Context → Decision → Alternatives considered → Consequences → Related` shape (see `docs/decisions/adr-015-events-and-jobs.md` for a representative example). Number is next-highest in `docs/decisions/` zero-padded to 3 digits (`adr-020-...`, `adr-021-...`).
+
+If the grill produced a major refactor decision rather than a new feature, lead the user to an ADR; if it produced a feature plan, lead to a PRD via `to-prd`.
+
+</supporting-info>

.claude/skills/grill-with-docs/glossary-format.md

@@ -0,0 +1,62 @@
+# docs/glossary.md Format
+
+## Structure
+
+```md
+# Glossary
+
+Domain vocabulary for `template-vertical`. Terms specific to this repo — clean architecture, vertical features, agent workflow, conformance. General programming concepts don't belong here; implementation details belong in code or ADRs.
+
+## Architecture
+
+**Feature**:
+A vertical slice owning its Clean Architecture layers (entities → application → infrastructure → DI → integrations).
+_Avoid_: module, domain, app.
+
+**Use case**:
+A single business action exposed by a feature, implemented as a factory `(deps) => async (input) => output`. Each one has a manifest entry, a Zod input/output schema pair, a colocated test, and a controller.
+_Avoid_: command, action, handler.
+
+**Manifest**:
+The `feature.manifest.ts` file that declares a feature's use cases, audits, publishes, consumes, and required core packages. Source of truth for conformance gates.
+
+**Conformance**:
+The 5-gate enforcement system (TS brands → ESLint → boot assertion → `pnpm conformance` → fallow) that keeps manifest and code aligned.
+
+## Workflow
+
+**PRD**:
+The top-level requirements doc at `docs/work/prds/<date>-<slug>.prd.md` that seeds an epic.
+
+**Epic**:
+A large body of work containing stories. Folder at `docs/work/<epic-slug>/_epic.md`.
+
+**Story**:
+One use case or technical capability. Folder under the epic, file `_story.md`.
+
+**Task**:
+One vertical slice = one PR = one commit. File `<slug>.task.md` under the story folder.
+
+## Relationships
+
+- A **PRD** decomposes into one or more **Epics**
+- An **Epic** contains one or more **Stories**
+- A **Story** is implemented by one or more **Tasks**
+- A **Use case** is declared in a **Manifest** before it has code
+- **Conformance** asserts that the **Manifest** and the code agree
+
+## Flagged ambiguities
+
+- (none yet — append here when conflicts are resolved during grilling)
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
+- **Flag conflicts explicitly.** When grilling surfaces ambiguity, capture both meanings under "Flagged ambiguities" with the resolution.
+- **Keep definitions tight.** One sentence max. Define what it IS, not what it does.
+- **Show relationships.** Use bold term names; express cardinality where obvious.
+- **Only domain terms specific to this repo.** General programming concepts (timeouts, retries, errors, DI) don't belong even if used heavily. Before adding, ask: is this concept unique to template-vertical, or generic?
+- **Group under subheadings** when natural clusters emerge (Architecture, Workflow, Instrumentation, etc.).
+
+This repo is **single-context**: one `docs/glossary.md`, no `CONTEXT-MAP.md`. Don't switch to multi-context layout unless the repo splits.