create-claude-cabinet 0.45.0 → 0.47.0

package/templates/skills/debrief-classic/SKILL.md

@@ -0,0 +1,696 @@
+---
+name: debrief-classic
+description: |
+  Pre-retirement standalone copy of the classic session close. Inventories
+  what was done, closes work items, updates state, captures lessons, and
+  prepares the briefing for next time. A self-contained skeleton skill
+  (phases/ directory pattern) that keeps working even after the live
+  /debrief is retired or redefined by the watchtower transition — it does
+  NOT delegate to /debrief. Use when: "debrief-classic", "/debrief-classic",
+  or to roll back to the classic session close during the transition. If
+  "quick" is mentioned, use the Quick Mode section — run core phases only,
+  skip presentation phases.
+related:
+  - type: file
+    path: .claude/skills/debrief-classic/phases/inventory.md
+    role: "Project-specific: how to identify what was done"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/close-work.md
+    role: "Project-specific: how to close work items and resolve feedback"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/auto-maintenance.md
+    role: "Project-specific: recurring session-end tasks"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/update-state.md
+    role: "Project-specific: what state to update"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/health-checks.md
+    role: "Project-specific: session-end health checks"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/record-lessons.md
+    role: "Project-specific: how to capture learnings"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/loose-ends.md
+    role: "Project-specific: non-project items to capture"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/audit-pattern-capture.md
+    role: "Instruction: detect recurring audit findings and write to patterns-project.md"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/checklist-feedback.md
+    role: "Instruction: propose checklist sharpening when bugs were caught this session"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/upstream-feedback.md
+    role: "Instruction: surface CC friction back to source repo"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/qa-handoff-sweep.md
+    role: "Instruction: hand off every worktree→main merge this session still needs QA for"
+  - type: file
+    path: .claude/skills/debrief-classic/phases/report.md
+    role: "Project-specific: how to present the summary"
+  - type: file
+    path: cabinet/_briefing.md
+    role: "Project identity and configuration"
+argument-hint: "mode — e.g., 'quick'"
+---
+
+# /debrief-classic — Session Close (classic)
+
+This is the standalone classic copy of the original `/debrief` skill,
+preserved so the session close can be rolled back during the watchtower
+transition. It is fully self-contained: every phase reference below
+resolves to this skill's own `phases/` directory, so it keeps working
+even after the live `/debrief` is retired or redefined.
+
+## Arguments
+
+If `$ARGUMENTS` is provided:
+- **'quick'**: Use Quick Mode — run core phases only, skip presentation
+  phases (the Quick Mode section below is self-contained).
+- **Any other value**: Ignored; run normal full debrief.
+- **Empty**: Run normal full debrief.
+
+## User Scope Hints
+
+When the user invokes debrief with emphasis on specific phases —
+"debrief, and make sure the docs get updated", "wrap up, don't forget
+the lessons" — that emphasis is **DEFENSIVE, never scope-limiting**.
+The user is guarding a phase they have seen skipped before, not
+granting permission to skip the others. Run the full workflow, and
+treat the named phases as the ones to be extra careful with.
+
+The trap this defuses: a user who emphasizes phase X *because it was
+silently skipped in the past* gets a debrief that runs only phase X —
+the anti-skipping defense becomes the mechanism for more skipping.
+Narrowing must be explicit and exclusionary ("ONLY close work items,
+skip everything else"). Absent words like "only" or "skip", emphasis
+adds attention; it never subtracts scope.
+
+## Purpose
+
+Close every session properly so the next one starts informed. Without
+debrief, completed work stays marked as open, feedback stays unresolved,
+lessons evaporate, and the system gradually disconnects from reality.
+Orient reads the past, debrief writes the future. That's the loop that
+gives your cabinet continuity.
+
+This is a **skeleton skill** using the `phases/` directory pattern. The
+orchestration (what to do and in what order) is generic. Your project
+defines the specifics in phase files under `phases/`.
+
+### Phase File Protocol
+
+Phase files have three states:
+
+| State | Meaning |
+|-------|---------|
+| Absent or empty | Use this skeleton's **default behavior** for the phase |
+| Contains only `skip: true` | **Explicitly opted out** — skip this phase entirely |
+| Contains content | **Custom behavior** — use the file's content instead |
+
+The skeleton always does something reasonable when a phase file is absent.
+Phase files customize, not enable. Use `skip: true` when you actively
+don't want a phase to run — not even the default.
+
+## Identity
+
+You are the closer. You care about finishing — not the building, but the
+part where the dust settles and you walk through making sure every loop
+is closed, every lesson is written down, every state file reflects
+reality. You take this seriously because you've seen what happens when
+debriefs are skipped: stale actions pile up, feedback rots, hard-won
+lessons evaporate, and three sessions later someone re-derives a solution
+that was already found.
+
+You are not a checklist executor. You are the person who owns the close.
+When a session ends, you ensure the system's state reflects what actually
+happened. If work was completed, it gets marked done — not "probably
+done, we'll check later." If a lesson was learned, it gets recorded
+before the context window closes.
+
+## When to Run
+
+- After completing significant work
+- When the user says "debrief", "wrap up", "we're done"
+- At the end of any productive session
+- **Should never be skipped.** A session that produced real work and
+  ends without debrief is a process failure — the next session starts
+  with stale state.
+
+## Workflow
+
+### 1. Inventory What Was Done (core)
+
+Read `phases/inventory.md` for how to identify what the session
+accomplished. This typically involves examining git history,
+conversation context, and files changed.
+
+**Default (absent/empty):** Review at minimum:
+- Recent git commits (`git log --oneline -20`)
+- Files changed (`git diff --stat HEAD~5`)
+- What was discussed and built during the session
+
+The goal: a clear list of what was accomplished, so subsequent steps
+can match it against open work.
+
+### 2. Close Work Items (core)
+
+Read `phases/close-work.md` for how to match session work against open
+items and close them. This includes marking tasks as done, resolving
+feedback, and updating any tracking system.
+
+**Default (absent/empty):** Match the session's work against open items
+in pib-db and propose closing what was completed. If pib-db is not
+initialized, skip gracefully.
+
+1. **Get session work:** `git log --oneline` for this session's commits
+   (since session start or last 2 hours)
+2. **Get open actions:**
+   ```bash
+   sqlite3 pib.db "SELECT fid, text, project_fid FROM actions WHERE completed = 0 AND deleted_at IS NULL ORDER BY flagged DESC, sort_order ASC"
+   ```
+3. **Match:** For each open action, check if the session's commits
+   address it (compare action text/notes against commit messages and
+   changed files)
+4. **Propose:** Present matched actions and ask the user to confirm
+   which to close
+5. **Close confirmed:**
+   ```bash
+   sqlite3 pib.db "UPDATE actions SET completed = 1, completed_at = date('now') WHERE fid = '<fid>'"
+   ```
+
+**Field feedback resolution:** After closing actions, check `feedback/`
+for `.md` files from consuming projects. For each, compare the described
+friction against this session's commits. If the friction was addressed,
+propose deleting the feedback file (it's a queue, not a ledger — the
+fix lives in git history). Partially addressed feedback stays open.
+
+**Project completion scan:** After closing actions, check for projects
+where all actions are now done:
+
+```bash
+sqlite3 pib.db "
+  SELECT p.fid, p.name,
+    (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid) as total,
+    (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 1) as done
+  FROM projects p
+  WHERE p.status = 'active'
+    AND p.deleted_at IS NULL
+    AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid) > 0
+    AND (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 0 AND a.deleted_at IS NULL) = 0
+"
+```
+
+For each result, propose completing the project (show name + action
+count, confirm before closing).
+
+For each open item, determine:
+- **Clearly complete** — mark it done with a reference to what was built
+- **Partially complete** — note progress, don't mark done
+- **Should be deferred** — move to a deferred state with a reason and
+  trigger condition for when to revisit
+- **Uncertain** — ask the user, but only for genuine ambiguity
+
+When closing an item that has documented follow-on work (sub-phases,
+next steps, future enhancements), create new items for each NOW. Known
+work that lives only in completed items' notes will be forgotten.
+
+### 3. Cabinet Consultations (core, **BLOCKING**)
+
+Spawn cabinet members whose `standing-mandate` includes `debrief`.
+This runs early — right after inventory and work-item closing — so
+members can do their work (update docs, check state, verify lessons)
+before subsequent phases duplicate that effort.
+
+**This step is BLOCKING. Debrief cannot close without it.** It is the
+step most often rationalized away late in a long session — the spawns
+feel like overhead, the prose framing reads as optional — and that is
+exactly why it gets a structural gate instead of trust:
+
+1. **Discovery must be evidenced.** Actually read
+   `.claude/skills/_index.json` (or run the frontmatter fallback) and
+   name the members found. "Probably just record-keeper" from memory
+   is not discovery.
+2. **A failed invocation surfaces and STOPS debrief.** If any spawn
+   errors, times out, or is refused, report which member failed and
+   why, then STOP — do not proceed to later phases, do not present a
+   summary, never silently close. Recovery belongs to the user: retry
+   the member, or the user explicitly waives it for this session.
+   Claude never waives a member on its own.
+3. **Verification happens before the summary.** Step 16b re-checks
+   this conversation's agent-tool history for one spawn per
+   debrief-mandated member. A debrief that reaches the report without
+   passing that check is not done.
+
+**Discovery:** Read `.claude/skills/_index.json` and filter to entries
+where `standingMandate` includes `"debrief"`. Each matching entry has
+a `directives.debrief` field — this is the scoped task for that member.
+If the index is missing, fall back to reading `cabinet-*/SKILL.md`
+frontmatter for `standing-mandate` and `directives`.
+
+**Index shape gotcha:** the file is a JSON *object* with a top-level
+`skills` array — entries live at `.skills[]`, not at the document
+root. If the file exists but fails to parse or has an unexpected
+shape, SAY SO in the output and use the frontmatter fallback — never
+silently skip consultations (a quiet parse failure has silently
+skipped this core phase before).
+
+**For each matching member**, spawn an agent with:
+- The member's full SKILL.md (read from the `path` in the index)
+- The session inventory from step 1 (what changed)
+- The member's `directives.debrief` as the task
+
+Spawn in parallel where possible. If a member has no directive for
+`debrief`, skip it — a standing mandate without a directive is a data
+error, not a reason to give the member an open-ended task.
+
+**Cost control:** These are lightweight passes, not full audits. Each
+agent should complete in under 2 minutes. If a member's directive
+produces no findings or changes, it returns silently. Include their
+results in the report only when they surfaced or changed something.
+
+**Persist actionable findings (BLOCKING — printing is not persisting):**
+A finding that exists only as report prose evaporates the moment the
+session closes. After collecting member output and BEFORE presenting
+the session report:
+
+1. Classify each finding a member surfaced: **informational** (context
+   the user reads once) vs **actionable** (a new capability to
+   evaluate, a breaking change to check, a recurring gap — anything
+   that implies future work or a decision). When unsure, classify
+   actionable: dismissing a tracked item is cheap; an evaporated
+   finding is unrecoverable.
+2. **Now act on the classifications above.** Every actionable finding
+   MUST be persisted:
+   - **Watchtower installed** (the queue API at
+     `~/.claude-cabinet/watchtower/scripts/watchtower-queue.mjs`
+     exists): file an `advisor-finding` inbox item — the SAME category
+     and discipline as Ring 3's session advisor pass (see "Session
+     Advisor Pass" in `watchtower-contracts.md`), never a parallel
+     path. Dedup first: read the project's pending items via
+     `listPending` and the recent resolved/dismissed corpus via
+     `listItems`; if an existing item already covers the finding,
+     reference its id instead of filing a duplicate. File via the
+     queue API (same temp-file + `createItem` pattern as /qa-handoff
+     Step 5) with title `<member-short-name>: <finding title>`,
+     `category: "advisor-finding"`, `filed_by: "manual"`, and
+     `evidence: {member, directive_key: "debrief"}`. Cap at 2 filed
+     items per member per session (Phase 2m's cap) — file the most
+     consequential; the rest stay informational lines.
+   - **No watchtower, pib-db available, and the target project is
+     unambiguous:** create a pib-db action instead (`pib_create_action`
+     or `node scripts/pib-db.mjs`), carrying the member name and the
+     finding in the notes.
+   - **Neither available:** mark the finding **UNTRACKED** in its
+     report line — loudly, so the user knows nothing persists it.
+3. Each report line for an actionable finding cites the filed id
+   (`dec-…` queue id or `act:…` fid) so the user can see it is
+   tracked, not merely mentioned.
+
+Note the Ring 3 overlap: on watchtower projects, the session advisor
+pass (Phase 2m) reviews this session's transcript at close and may
+file findings of its own. That pass covers the `session-close`
+roster's directives; this step covers what `debrief`-mandated members
+surfaced live. The shared dedup-vs-pending discipline keeps the two
+from double-filing — whichever files second sees the first's pending
+item and references it instead.
+
+If discovery runs and finds zero members with a `debrief` mandate,
+say so in one line ("no debrief standing mandates in _index.json")
+and proceed. An *evidenced* empty roster is the only non-spawning
+path through this step — "no members matched" without having read
+the index is the loophole this gate exists to close.
+
+### 4. Audit Pattern Capture (core)
+
+Read `phases/audit-pattern-capture.md`. This is an **instruction phase**
+shipped with CC — it detects recurring audit findings from cabinet
+consultations and writes them to the relevant cabinet member's
+`patterns-project.md` file.
+
+Only runs if an audit produced findings this session. If no audit ran,
+skip silently. The phase consumes what cabinet members produced in
+step 3 — it doesn't run cabinet members itself.
+
+**This phase should not be skipped.** It's how project-level patterns
+accumulate over time, feeding the promotion pipeline.
+
+### 5. Auto-Maintenance (core)
+
+Read `phases/auto-maintenance.md` for recurring automated tasks that
+should run at session end. Same principle as orient's auto-maintenance:
+operations that decay if left to human memory.
+
+**Skip (absent/empty).**
+
+### Memory health check
+
+Run the structural validator if available — catches orphan files,
+broken references, and exceeded caps before they accumulate:
+```bash
+node scripts/validate-memory.mjs --quiet 2>&1 || true
+```
+Surface any violations under the session report's "Health" section.
+
+### 6. Update State (core)
+
+Read `phases/update-state.md` for what state files and documentation
+to update. This keeps the system's persistent state aligned with
+reality so the next orient reads accurate information.
+
+**Division of labor with cabinet consultations (step 3):** If a
+record-keeper or similar doc-checking member ran in step 3, it owns
+all documentation updates — both staleness (wrong claims) and additions
+(missing claims). This step handles only what isn't doc work:
+- **User-level state** — preferences, registry entries (see below)
+- **Project-specific non-doc state** — whatever `phases/update-state.md`
+  defines beyond documentation
+
+If a record-keeper ran, don't duplicate its work on docs. If no
+record-keeper ran (no cabinet members, or none with a debrief mandate),
+fall back to the default below.
+
+**Default (absent/empty, no record-keeper):** Check whether
+`system-status.md` (or equivalent) needs updating to reflect what was
+built, fixed, or changed. Also check the user-level state below.
+
+#### User-Level State
+
+Check silently — don't make this a conversation unless something
+needs updating:
+
+- **`~/.claude/CLAUDE.md`** — did the user reveal something about
+  themselves this session that isn't in their profile? A new role,
+  a new tool they use, a preference about how they work? If so,
+  propose adding it. Keep it brief — this isn't an interview.
+- **`~/.claude/cc-registry.json`** — does this project's name or
+  description still match reality? If the project has evolved
+  significantly, propose updating the registry entry.
+
+### 7. Health Checks (core)
+
+Read `phases/health-checks.md` for end-of-session health checks. These
+verify that the session's work didn't break anything and that the system
+is in a good state for next time.
+
+**Skip (absent/empty).**
+
+### 8. Persist Work
+
+**Unmerged commits check:** Run `git log --oneline main..HEAD`. If
+non-empty, enumerate the commits and ask: merge to main now, keep the
+branch, or discard? This prevents orphan worktree branches that sit
+unmerged with no surface signal.
+
+Commit and push the session's changes. Work that's done but not
+committed is half-closed — it lives locally but isn't durable. Persist
+before recording lessons, so the commit captures code and doc changes
+while lessons go to memory (which may live outside the repo).
+
+Separate this session's changes from any pre-existing uncommitted work.
+Don't silently bundle unrelated changes.
+
+### 9. Record Lessons (core)
+
+Read `phases/record-lessons.md` for how to route session outputs to
+their real homes. This is the second irreducible purpose of debrief —
+the first is closing work, this is ensuring the next session is smarter
+than this one.
+
+**The phase file teaches a routing discipline:** every output has
+exactly one home with a forcing function — a per-file curated memory
+via `/cc-remember` (decisions, lessons, preferences, constraints),
+inline in CLAUDE.md or a briefing (for load-bearing project facts),
+a pib-db deferred action (for conditional revisits), or the
+upstream-feedback phase (for CC-applicable friction). Loose `.md`
+files written next to the code they describe (rather than in the
+memory dir via `/cc-remember`) are an **anti-pattern** — they rot
+silently when the code changes. Hybrid observations (part project,
+part CC) must be split.
+
+**Default (absent/empty):** Follow the routing tree in the phase file.
+Ask the user only when routing is genuinely ambiguous — not as a
+catch-all "what did we learn?" prompt, which tends to produce vague
+lessons that don't get recorded anywhere useful.
+
+**Built-in memory unavailable:** If `~/.claude/projects/<slug>/memory/`
+doesn't exist or `/cc-remember` is unreachable, surface this in the
+debrief report:
+
+> **⚠ Built-in memory dir not found.**
+> Lessons from this session weren't captured. Run /cc-remember
+> manually for each lesson, or ensure auto-memory is enabled.
+
+> **Debrief lessons vs audit findings:** Debrief captures session-specific
+> learnings — what was discovered while doing this work, what surprised
+> you, what should change. Audit captures systematic observations from
+> cabinet members — what would a specialist notice looking at the
+> whole codebase? Different inputs (one session vs the whole system),
+> different destinations (memory/feedback vs finding database). Both
+> feed the enforcement pipeline, but through different channels.
+
+### 9b. Checklist Feedback (core, instruction phase)
+
+Read `phases/checklist-feedback.md` and follow it. This phase proposes
+sharpening or adding QA checklist dimensions when a bug was caught this
+session. If the phase file is absent or no bugs were caught, this step
+is a silent no-op.
+
+### 10. Methodology Capture (core)
+
+Read `phases/methodology-capture.md`. This is an **instruction phase**
+shipped with CC — it tells Claude to detect when the session produced
+load-bearing methodology (new skill, multi-phase gate scripts, convention
+docs, calibration harnesses, multi-subagent choreography) and capture
+the layer above individual lessons: the reasoning chain with skeptic's
+counters AND a narrateable summary for external audiences.
+
+Most sessions skip silently (detection heuristics fire only on core
+methodology work — not bug fixes or small refactors). When they fire,
+the user gets a single four-choice question (internal record, narrative
+summary, both, or neither). Output lands in `.claude/methodology/` as
+two files (`<date>-<slug>-internal.md` and `<date>-<slug>-narrative.md`)
+and is surfaced in the report.
+
+**This phase should not be skipped.** It's how the project's load-bearing
+methodology accumulates a defensible record instead of living in
+someone's head.
+
+### 11. Upstream Feedback (core)
+
+Read `phases/upstream-feedback.md`. This is an **instruction phase**
+shipped with CC — it tells Claude to reflect on whether the session
+revealed friction with any CC-provided skill, phase, or convention.
+
+If friction is found, Claude drafts a short feedback item and surfaces
+it in the report for the user to confirm, edit, or dismiss. If
+confirmed, the feedback is delivered to the CC repo (via local link
+or GitHub issue). If nothing — the phase is silent.
+
+This is different from `/cc-extract` (which proposes generalizable
+artifacts for upstreaming). This captures field friction: what hurt,
+what was confusing, what needed a workaround.
+
+**This phase should not be skipped.** It's how CC learns from use.
+
+### 12. Skill Discovery (core)
+
+Silently reflect: did this session involve a workflow the user is
+likely to repeat? Not every session produces one — most don't. But
+when a session walks through a multi-step process that has a clear
+trigger and structure, that's a candidate for a project skill.
+
+**Most sessions: nothing.** This check should be silent when there's
+nothing to surface. Don't force it.
+
+**When there's a candidate:** Describe the pattern and ask:
+
+> "We walked through [analyzing that deal / onboarding that client /
+> writing that report] step by step. If that's something you'll do
+> again, I could turn it into a `/analyze-deal` command so next time
+> you just invoke it and I follow the same process. Want me to?"
+
+If the user says yes, create the skill: a SKILL.md in
+`.claude/skills/[name]/` with the workflow captured as steps. Use
+the skeleton/phase pattern if it makes sense, or keep it simple for
+straightforward workflows. The skill should encode the *process*,
+not the specific content from this session.
+
+If the user says no, move on.
+
+**Separately and less commonly:** did this session produce something
+that could be useful *beyond* this project — in any project? A
+generalizable pattern, cabinet member, or convention? If so, mention
+`/cc-extract` as an option for proposing it upstream to CC. This is
+rarer than project-specific skills.
+
+### 13. Cabinet Check (core)
+
+Silently check: is this project's expertise coverage still right?
+
+**Two checks, both silent unless they find something:**
+
+**Check A — Uncovered technology.** Did this session touch a framework,
+library, or infrastructure not covered by any cabinet member? Compare
+against `.claude/skills/cabinet-*/` and merged committees
+(`node scripts/resolve-committees.cjs`).
+
+**Check B — Dormant member that should be active.** Are there installed
+cabinet members not in any committee that the recent work would benefit
+from?
+
+**Most sessions: nothing.** Silent when nothing is off.
+
+**When there's a gap:** Explain plainly what the project is missing
+in terms of what it would DO for them (no jargon about "cabinet
+members" or "committees"). If the user wants it, activate the member
+via `committees-project.yaml`, `/seed`, or Tier 3 install. Track
+declined suggestions so you don't re-suggest next session.
+
+### 14. Capture Loose Ends (core)
+
+Read `phases/loose-ends.md` for non-project items and environmental
+concerns to capture before closing. Sessions generate non-project
+work — manual tasks, purchases, emails, configuration changes. If
+these aren't captured somewhere, they rely on human memory.
+
+**Skip (absent/empty).**
+
+### Orient contract
+
+Debrief MUST record these for the next session's orient to function:
+
+1. **Session summary** — what was accomplished, captured as a
+   `session_summary_<date>.md` curated entry via `/cc-remember`
+2. **Open items** — any unfinished work, with fids if tracked in pib-db
+3. **Active constraints** — anything discovered this session that limits
+   future work (API limits, broken dependencies, blocked paths) — captured
+   as a `constraint_<short_name>.md` curated entry via `/cc-remember`
+4. **Feedback filed** — count of cc-feedback items filed this session
+
+Orient will read MEMORY.md to surface items 1-3. Item 4 is checked
+via the outbox. If debrief skips any of these, orient starts the next
+session blind on that dimension.
+
+### 15. QA-Handoff Sweep (core)
+
+Read `phases/qa-handoff-sweep.md`. This is an **instruction phase** —
+it performs a `/qa-handoff` for every worktree→main merge from this
+session that still needs post-merge QA (deduped against the inbox), so
+the operator never has to remember to run it per merge.
+
+Runs late, after the session's merges and commits have landed (so it
+sweeps everything). Self-skips silently when there were no merges, all
+merges are already handed off, or `/qa-handoff` (watchtower) isn't
+installed. `/qa-handoff` stays the single source of truth for *how* a
+handoff is packaged; this phase only decides *which* merges still need
+one.
+
+When closing with `/session-handoff` (the default close verb), this
+sweep is phase 1; `/session-handoff` then adds phase 2 — proposing and,
+on approval, launching the next session.
+
+### 16. Discover Custom Phases
+
+After running the core phases above, check for any additional phase
+files in `phases/` that the skeleton doesn't define. These are project-
+specific extensions. Each custom phase file declares its position in
+the workflow. Execute them at their declared position.
+
+### 16b. Pre-Summary Verification (core, **BLOCKING**)
+
+Before presenting the report, verify against this conversation's
+actual agent-tool call history that step 3 happened:
+
+1. Re-state the debrief-mandated roster discovered in step 3 (from
+   `_index.json` or the frontmatter fallback).
+2. For each member on it, confirm a corresponding agent spawn exists
+   in this session's tool-call history with a completed result.
+3. If any member has no spawn — or step 3 never ran — debrief is NOT
+   complete. Say so plainly, run the missing consultations now, and
+   only then proceed to the report. Skipping forward is not an
+   option; neither is retroactively declaring the member unnecessary.
+4. For each ACTIONABLE finding those consultations surfaced, confirm
+   step 3's persistence sub-step filed it (a `dec-…` queue id or
+   `act:…` fid exists to cite, or the finding is explicitly marked
+   UNTRACKED because no persistence layer was available). An
+   actionable finding with none of those is not done — file it now,
+   before the report.
+
+An empty roster passes only if step 3 evidenced it (discovery ran and
+found zero debrief mandates). Uncertainty resolves to running the
+consultation, never to assuming it ran.
+
+### 17. Present Report (presentation)
+
+Read `phases/report.md` for how to present the debrief summary.
+
+**Default (absent/empty):** Present a brief summary in plain English
+(see `cabinet/skill-output-conventions.md` §9 — concept-first, the
+file-and-fid detail stays in the durable state, not the spoken recap):
+- Work items closed (with references)
+- State files updated
+- Lessons recorded
+- Anything needing the user's input
+
+## Phase Summary
+
+| Phase | Absent = | What it customizes |
+|-------|----------|-------------------|
+| `inventory.md` | Default: review git log + session | How to identify what was done |
+| `close-work.md` | Default: match pib-db actions against git log | How to close work items |
+| `auto-maintenance.md` | Skip | Recurring session-end tasks |
+| `update-state.md` | Default: check system-status.md | What state files to update |
+| `health-checks.md` | Skip | Session-end health checks |
+| `record-lessons.md` | Default: route outputs per the decision tree | How to route session outputs to /cc-remember / CLAUDE.md / pib-db triggers / upstream |
+| `audit-pattern-capture.md` | **Instruction: always runs** | Detect recurring audit findings, write to patterns-project.md |
+| `methodology-capture.md` | **Instruction: always runs** | Detect methodology-level work; capture reasoning chain + narrative to `.claude/methodology/` |
+| `upstream-feedback.md` | **Instruction: always runs** | Surface CC friction to source repo |
+| `checklist-feedback.md` | **Instruction: always runs** | Propose checklist sharpening when bugs were caught |
+| `loose-ends.md` | Skip | Non-project items to capture |
+| `report.md` | Default: brief summary | How to present the report |
+
+## Quick Mode
+
+Phases are either **core** (maintain system state) or **presentation**
+(surface information for the user). For lightweight session closes,
+skip presentation phases. **Core phases always run — Quick Mode is not
+a license to skip them.**
+
+- **Core phases** (always run): inventory, close-work,
+  cabinet-consultations, audit-pattern-capture, auto-maintenance,
+  update-state, health-checks, persist-work, record-lessons,
+  checklist-feedback, methodology-capture, upstream-feedback,
+  skill-discovery, cabinet-check, loose-ends,
+  pre-summary-verification
+- **Presentation phases** (skippable): report
+
+A project that wants a quick debrief variant skips the report and
+outputs a minimal summary instead.
+
+### What Quick Mode does NOT skip
+
+**Cabinet-consultations (step 3) is BLOCKING in Quick Mode too — do
+NOT skip, do NOT paraphrase, do NOT defer.** This is where
+record-keeper (and any other debrief-mandated members) verifies
+documentation against reality. Skipping it is the single most common
+Quick Mode failure mode: the consultations *feel* like overhead
+because they spawn agents, but they are the only mechanism that
+catches doc drift, methodology gaps, and stale state. A debrief
+without cabinet-consultations leaves the next orient reading stale
+docs. The pre-summary verification (step 16b) applies in Quick Mode
+unchanged: no spawn evidence, no close.
+
+**Audit-pattern-capture, methodology-capture, and upstream-feedback
+are instruction phases — they ship with CC and are always required**,
+in Quick Mode as much as in full debrief. Their per-session cost is
+near zero when nothing fires.
+
+If a session genuinely has no audit findings, no methodology work,
+and no CC friction, those phases self-skip in seconds. That is not
+the same as Claude choosing to skip them.
+
+## Extending and Calibration
+
+See [calibration.md](calibration.md) for the phase-extension pattern
+(how consuming projects add their own phases) and the without-skill
+vs with-skill illustration of what this skill prevents.