create-claude-cabinet 0.46.0 → 0.47.0

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

@@ -0,0 +1,770 @@
+---
+name: orient-classic
+description: |
+  Pre-retirement standalone copy of the classic session-start briefing.
+  Reads project state, syncs data, scans work items, runs health checks,
+  then briefs you so the session starts informed. A self-contained skeleton
+  skill (phases/ directory pattern) that keeps working even after the live
+  /orient is retired or redefined by the watchtower transition — it does NOT
+  delegate to /orient. Use when: "orient-classic", "/orient-classic", or to
+  roll back to the classic session-start briefing 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/orient-classic/phases/context.md
+    role: "Project-specific: what to read at session start"
+  - type: file
+    path: .claude/skills/orient-classic/phases/data-sync.md
+    role: "Project-specific: how to sync fresh data"
+  - type: file
+    path: .claude/skills/orient-classic/phases/work-scan.md
+    role: "Project-specific: what work items to check"
+  - type: file
+    path: .claude/skills/orient-classic/phases/deferred-check.md
+    role: "Project-specific: evaluate waiting triggers on deferred items"
+  - type: file
+    path: .claude/skills/orient-classic/phases/health-checks.md
+    role: "Project-specific: system health checks"
+  - type: file
+    path: .claude/skills/orient-classic/phases/auto-maintenance.md
+    role: "Project-specific: recurring session-start tasks"
+  - type: file
+    path: .claude/skills/orient-classic/phases/briefing.md
+    role: "Project-specific: how to present the orientation"
+  - type: file
+    path: .claude/skills/orient-classic/phases/cabinet.md
+    role: "Project-specific: which cabinet members to activate"
+  - type: file
+    path: .claude/skills/orient-classic/phases/skills-menu.md
+    role: "Project-specific: what skills to show after briefing"
+  - type: file
+    path: cabinet/_briefing.md
+    role: "Project identity and configuration"
+argument-hint: "mode — e.g., 'quick'"
+---
+
+# /orient-classic — Session Briefing (classic)
+
+This is the standalone classic copy of the original `/orient` skill,
+preserved so the session-start briefing 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 `/orient` 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 orientation.
+- **Empty**: Run normal full orientation.
+
+## Purpose
+
+Start every session with a briefing. Before anyone makes a decision,
+assemble what happened since last time, what needs attention, and what's
+on the agenda. Without this, Claude starts every session blind — same
+mistakes, same questions, same missed context. Orient reads the past so
+debrief can write 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 — what files to read, what data to sync, what work
+items to check — 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.
+
+**Phase separation principle:** Phases that both gather data and act on
+the results should use clear structural separation. Without it, the
+model tends to treat data-gathering as completion — running a query
+satisfies the "do something" impulse and the acting step gets skipped.
+Use numbered steps with explicit transitions: "1. Query X. 2. **Now
+act on the results above:** [specific action]." If the acting step is
+critical, mark it as `**BLOCKING**` — querying is not processing.
+
+## Why This Matters
+
+If Claude Code starts a session without reading what happened last time,
+it has no memory. If it ends a session without recording what happened,
+the next session starts blind. Orient doesn't need to be complex — a
+minimal orient reads a project description and a status file. A mature
+orient pulls fresh data, checks queues, evaluates health, and surfaces
+what needs attention. The complexity grows from use: each check gets
+added because its absence caused a problem. But the loop itself must
+exist from day one, or nothing that follows has a foundation.
+
+## Workflow
+
+### 0. Frontier-Model Watchdog (core)
+
+The operator can designate a frontier model — the model heavy thinking is
+supposed to run on — in `~/.claude/cc-registry.json` under the
+`frontierModel` key (set via `npx create-claude-cabinet --frontier-model
+<value>` or by hand). This check is **visibility only**: it never blocks,
+pins, or routes anything. It exists because the session model is the
+single lever controlling all heavy thinking (skills and spawned cabinet
+members inherit it), and the failure mode is being accidentally on the
+wrong model without noticing.
+
+1. Read `frontierModel` from `~/.claude/cc-registry.json`:
+   ```bash
+   node -e "try{const r=require(process.env.HOME+'/.claude/cc-registry.json');const k=(r.frontierModel||'').trim();if(k)console.log(k)}catch(e){}"
+   ```
+2. **Zero cases (silent no-op, no nag to configure):** key absent, file
+   absent, file unparseable, or key empty/whitespace-only. An empty
+   string is treated as absent — `''` is a substring of every model ID
+   and would match everything, leaving the watchdog permanently silent
+   while appearing configured.
+3. Compare the key against this session's own model (you know which
+   model you are running as). **This is the canonical match rule** —
+   any other runtime implementing this check (e.g. the watchtower
+   SessionStart hook) references this definition rather than redefining
+   it:
+   - **Strip any bracketed runtime suffix from the session model ID
+     before exact comparison** — real session IDs carry one (e.g.
+     `claude-fable-5[1m]`); the suffix is session configuration, not
+     model identity. Alias containment uses the full unstripped ID.
+   - The key is an **exact model ID** if it starts with `claude-` AND
+     contains a digit (e.g. `claude-fable-5`, `claude-opus-4-8`).
+     Exact IDs require an exact, case-insensitive match against the
+     suffix-stripped session model ID.
+   - Otherwise the key is a **family alias** (e.g. `fable`, `opus`,
+     `claude-fable`). Aliases match if the session model ID contains
+     the alias, case-insensitively.
+   - Examples:
+     | Key | Session model | Verdict |
+     |---|---|---|
+     | `fable` | `claude-fable-5` | match (alias containment) |
+     | `fable` | `claude-opus-4-8` | MISMATCH — warn |
+     | `claude-fable-5` | `claude-fable-5` | match (exact) |
+     | `claude-fable-5` | `claude-fable-5[1m]` | match (exact; bracketed suffix stripped) |
+     | `claude-fable-5` | `claude-fable-5-20260301` | MISMATCH — warn (exact key, non-identical ID) |
+     | `claude-fable-6` | `claude-fable-5` | MISMATCH — warn (stale key nags loudly by design) |
+     | *(absent / empty)* | anything | silent no-op |
+4. **On mismatch, the warning is the FIRST line of the briefing** —
+   before any other section, loud and unmissable:
+   > ⚠ **This session runs `<session model>`; your designated frontier
+   > model is `<key>`** — switch with `/model` or relaunch. (Update the
+   > designation with `npx create-claude-cabinet --frontier-model <new>`
+   > if it's stale.)
+5. On match, say nothing. Do not block anything either way.
+
+A stale key after a model-family transition produces a visible nag —
+that is the design, not a bug: the failure mode is loud by construction,
+and updating the key takes seconds.
+
+Boundary note: on installs with the watchtower module, the same check
+also runs in the SessionStart hook (warning lands before orient); on all
+other installs, this orient step is the sole boundary.
+
+### 1. Load Context (core)
+
+Read `phases/context.md` for the list of files and state to load at
+session start. This typically includes status files, memory from prior
+sessions, and project-specific context.
+
+**Default (absent/empty):** Read at minimum:
+- The project's root `CLAUDE.md` (already loaded by Claude Code)
+- `system-status.md` or equivalent state file if one exists
+- `.claude/memory/patterns/` — enforcement patterns from prior sessions.
+  Scan the directory, read each pattern file. These are project-level
+  feedback that guides behavior (what to avoid, what to keep doing).
+- **Built-in memory index.** Claude Code loads `MEMORY.md` from the
+  project's memory dir at session start automatically (200-line /
+  25KB budget). During orient, glance at the index sections and load
+  topic files whose descriptions match the session's likely focus.
+  Resolve the memory dir via:
+  ```bash
+  node -e "console.log(require('./lib/project-context').resolveMemoryDir())" 2>/dev/null || \
+    echo "$HOME/.claude/projects/$(pwd | sed 's|/|-|g')/memory"
+  ```
+  Health-check the dir with `node scripts/validate-memory.mjs --quiet`
+  if the script exists (surface violations under Attention Items).
+
+- **Deployment method detection:** Check for deployment indicators and
+  surface the deploy command in the briefing so sessions don't default
+  to wrong deployment methods (e.g., `git push` when the project uses
+  `railway up`):
+  - `railway.toml` → Railway (`railway up --detach`)
+  - `fly.toml` → Fly.io (`fly deploy`)
+  - `vercel.json` or `.vercel/` → Vercel (`vercel --prod`)
+  - `netlify.toml` → Netlify (`netlify deploy --prod`)
+  - `.github/workflows/deploy*` → GitHub Actions (push triggers deploy)
+  - `Dockerfile` alone → manual container deploy (surface as "Docker-based,
+    check deployment docs")
+
+  If found, include in the briefing: "**Deployment:** [method] via [command]"
+
+- **Platform → MCP registry (advisory):** when a deployment platform is
+  detected, check whether its agent/MCP integration is registered and, if
+  not, surface an advisory (subject to the dismissal state in the
+  health-checks section — advisory id `mcp:<platform>`). A missing
+  platform MCP has cost real debugging time. **This pass ships Railway
+  only**; the registry is shaped for future rows (platform → indicator →
+  probe key → install options) but only verified platforms are added
+  (vercel/fly/netlify had no GA agent-MCP surface as of 2026-06 — recheck
+  at the quarterly landscape review).
+
+  | Platform | Indicator | Probe (presence only) | Advisory options |
+  |---|---|---|---|
+  | Railway | `railway.toml` | a railway-ish key under `mcpServers` in `~/.claude.json` | local: `railway setup agent -y` · remote: register `mcp.railway.com` (OAuth, no local install) |
+
+  **Probe by exit code only — never read or echo `~/.claude.json` values**
+  (`mcpServers` holds tokens). For example:
+  ```bash
+  grep -q 'railway' "$HOME/.claude.json" 2>/dev/null || echo "NOT REGISTERED"
+  ```
+  If `~/.claude.json` is absent, skip the probe silently. If the key is
+  absent, surface:
+  > ⚠ Railway project detected but no Railway MCP registered. Register it
+  > for agent access — local: `railway setup agent -y`, or remote: add
+  > `mcp.railway.com` via OAuth. (Offer both; hardcode neither.)
+
+The goal: build a mental model of where things stand before doing
+anything else.
+
+### Feedback pipeline check
+
+> The feedback **outbox flush** is no longer orient's job. Watchtower
+> Ring 1 (`flushFeedbackOutbox()` in `watchtower-lib.mjs`) is the sole
+> owner of delivering `~/.claude/cc-feedback-outbox.json` into the CC
+> repo's `feedback/`, every tick (act:d53ff509). Orient's duplicate
+> flush used an incompatible `{date}-{slug}-{seq}.md` filename scheme
+> that defeated Ring 1's skip-if-exists guard, causing re-delivery of
+> already-resolved items — it has been retired.
+
+1. **Scan wrong-write locations.** Check `.claude/memory/feedback/*.md`
+   and `.claude/feedback/*.md` for files that may be CC upstream
+   feedback misfiled. **Exclude project-scoped files** — skip any file
+   whose name starts with `feedback-project-` or whose frontmatter
+   contains `scope: project-specific`. Those are intentionally
+   project-scoped decisions/constraints, not CC upstream feedback; they
+   belong in the project's built-in memory dir (per-file curated entries
+   via `/cc-remember`), CLAUDE.md, or a pib-db deferred trigger — not
+   in the outbox.
+   If remaining candidates found: "Found N feedback files in [path]
+   that may be CC upstream feedback written to the wrong location.
+   Move to outbox?"
+
+2. **Triage incoming feedback at arrival (CC source repo only).**
+   `feedback/` root means exactly one thing: *not yet triaged*. It is
+   an inbox, not a backlog — resolution state lives in pib-db, never
+   in file location. For each `.md` file in `feedback/` root (not
+   `resolved/`):
+
+   - **File it**: create a pib-db action (or attach to an existing
+     one), then prepend a one-line resolution stamp
+     (`> **Resolution (date):** tracked — act:xxxx`) and move the file
+     to `feedback/resolved/`.
+   - **Or decline it**: prepend the stamp with the decline reason and
+     move it to `feedback/resolved/`.
+   - **Or leave it** only when the triage genuinely needs the
+     operator — surface it in the briefing's Attention Items and say
+     why.
+
+   **BLOCKING** — counting the files is not triaging them. A file
+   still in root after two sessions is a process failure, not a
+   backlog item. (Rule adopted 2026-06-11 after 76 files accumulated
+   across two months and required a three-agent reconciliation sweep;
+   the file-location-as-status parallel to pib-db is exactly the
+   two-sources-of-truth drift `maintainability.md` warns about.)
+
+### 2. Sync Data (core)
+
+Read `phases/data-sync.md` for how to pull fresh canonical data from
+remote sources (databases, APIs, shared storage).
+
+**Skip (absent/empty).** Purely local projects don't need it. Projects
+with remote canonical data stores define their sync commands here.
+
+Report if sync fails — a stale local cache is better than no data, but
+the user should know it's stale.
+
+### 3. Scan Work Items (core)
+
+Read `phases/work-scan.md` for what work items to check. This includes
+whatever the project uses to track work: a backlog, task list, inbox,
+queue, or issue tracker.
+
+**Default (absent/empty):** If `scripts/pib-db.mjs` exists, run the
+standard work scan.
+
+**Access method:** Use `pib_*` MCP tools when available (see
+`.claude/cabinet/pib-db-access.md`), fall back to `node scripts/pib-db.mjs`
+CLI.
+
+1. **Active projects and open actions:**
+   Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+   ```sql
+   SELECT p.fid, p.name,
+     (SELECT COUNT(*) FROM actions a WHERE a.project_fid = p.fid AND a.completed = 0 AND a.deleted_at IS NULL) as open_actions
+   FROM projects p
+   WHERE p.status = 'active' AND p.deleted_at IS NULL
+   ORDER BY open_actions DESC
+   ```
+
+2. **Flagged actions** (prioritized items needing attention):
+   Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+   ```sql
+   SELECT a.fid, a.text, p.name as project
+   FROM actions a
+   LEFT JOIN projects p ON a.project_fid = p.fid
+   WHERE a.flagged = 1 AND a.completed = 0 AND a.deleted_at IS NULL
+   ```
+
+3. **Staleness detection** — flag projects that need attention:
+
+   **Completion candidates** — active projects where all actions are done:
+   Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+   ```sql
+   SELECT p.fid, p.name
+   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
+   ```
+
+   **Stale projects** — active projects with no action completed in 14+ days:
+   Use `pib_query` (or `node scripts/pib-db.mjs query`) with:
+   ```sql
+   SELECT p.fid, p.name,
+     MAX(a.completed_at) as last_completion
+   FROM projects p
+   LEFT JOIN actions a ON a.project_fid = p.fid AND a.completed = 1
+   WHERE p.status = 'active' AND p.deleted_at IS NULL
+     AND (SELECT COUNT(*) FROM actions a2 WHERE a2.project_fid = p.fid AND a2.completed = 0 AND a2.deleted_at IS NULL) > 0
+   GROUP BY p.fid
+   HAVING last_completion < date('now', '-14 days')
+     OR last_completion IS NULL
+   ```
+
+   Surface in briefing as actionable signals:
+   - "N projects may be ready to close (0 open actions)"
+   - "N projects have had no activity in 14+ days"
+
+4. **Spring-clean heuristic** — suggest `/spring-clean` when the backlog
+   shows structural cruft. Fire when ANY of:
+   - An active project has 10+ open actions AND no completion in 14+ days
+   - Total active projects > 7
+   Cap at once per 7 days — check if a spring-clean note exists in the
+   last 7 days of session context before surfacing. When it fires,
+   append to Attention Items:
+   *"Backlog may benefit from `/spring-clean` (N stale, M open actions
+   in mega-projects)."*
+
+If pib-db doesn't exist, skip with no warning — the project may use
+a different work tracking system configured in `phases/work-scan.md`.
+
+### 4. Deferred-Trigger Evaluation (core)
+
+Read `phases/deferred-check.md` for how to surface items waiting on
+specific trigger conditions and evaluate whether any now apply in the
+current session's context.
+
+**Default (absent/empty):** If pib-db is available, call `pib_list_triggered`
+(MCP) or `node scripts/pib-db.mjs list-triggered` (CLI fallback). If zero
+items are returned, skip silently. Otherwise:
+
+1. Surface items in the briefing under a "Deferred (N items with triggers)"
+   heading with each item's fid, text, trigger condition, and
+   last-checked status.
+2. For each item, evaluate the trigger text against current session
+   context (project state, recent git activity, user's stated focus).
+   If unsure, mark `needs-info` rather than guessing `triggered`.
+3. For each item, call `pib_mark_trigger_checked` with result
+   (`triggered | still-waiting | needs-info | condition-obsolete`)
+   and brief reasoning in notes.
+4. Include any items that evaluated to `triggered` in the briefing's
+   **Attention Items** section. For each, collect the user's decision
+   via `AskUserQuestion`:
+   - `header`: `"Triggered"`
+   - `question`: "[fid] appears triggered — [trigger summary]. What to do?"
+   - `options`:
+     - Reopen — "Change status back to open, ready to work"
+     - Leave deferred — "Keep it deferred, not ready yet"
+     - Mark obsolete — "Trigger condition no longer relevant"
+   - `multiSelect: false`
+
+   Map: Reopen → status to open; Leave deferred → no-op; Mark obsolete
+   → `pib_mark_trigger_checked` with `condition-obsolete`.
+   (See `skill-output-conventions.md`.)
+
+**Cost control:** Cap this phase at 30 seconds total. If N > 10 items,
+evaluate only the 5 least-recently-checked.
+
+### 5. Health Checks (core)
+
+Read `phases/health-checks.md` for system health and validation checks
+to run at session start. These catch problems early — stale data, broken
+references, failed background processes, configuration drift.
+
+**Skip (absent/empty).** Projects add health checks as they discover
+failure modes worth detecting early.
+
+**Built-in check (always runs):** If `~/.claude/cc-registry.json`
+exists, verify this project is in it and the entry is current. If
+other registry entries point to paths that no longer exist, silently
+note it — mention during briefing only if the user might care (e.g.,
+"Your old project 'deal-v1' seems to have been deleted — want me to
+remove it from the registry?").
+
+### Environment advisories have a background home — skip when watchtower owns them
+
+The LSP, platform-MCP, hookify, and briefing-file advisories below now have a
+single home: the watchtower **SessionStart context builder**, which runs
+`scripts/watchtower-advisories.mjs` with a persistent per-project dismissal
+memory (`.claude/cabinet/advisories-state.json`; rules in
+`.claude/cabinet/advisories-state-schema.md`) so nothing re-nags every
+session. That module is the single implementation of the dismissal rules
+(act:f9ea075d).
+
+- **If watchtower is installed** (`~/.claude-cabinet/watchtower/config.json`
+  exists), the context builder already surfaced these advisories in the
+  ambient state injection — **SKIP the advisory checks below** (LSP, hookify,
+  briefing file). Re-running them here only double-nags.
+- **Otherwise (no watchtower)**, run the checks below as **one-shot hints**
+  with no dismissal memory. If `scripts/watchtower-advisories.mjs` is present,
+  prefer shelling it (`node scripts/watchtower-advisories.mjs --project-path .`,
+  one hint per line) — it is the single implementation. These advisories
+  **show** an install command; they NEVER run it.
+
+### LSP plugin check
+
+Detect the project's tech stack and verify matching LSP plugins (advisory
+ids `lsp:<lang>` — subject to the dismissal state above):
+
+| Indicator | Language | Plugin | Install command |
+|---|---|---|---|
+| tsconfig.json or *.ts files | TypeScript | typescript-lsp | `/plugin install typescript-lsp` |
+| pyproject.toml, requirements.txt, *.py | Python | pyright-lsp | `/plugin install pyright-lsp` |
+| Cargo.toml | Rust | rust-analyzer-lsp | `/plugin install rust-analyzer-lsp` |
+| go.mod | Go | gopls-lsp | `/plugin install gopls-lsp` |
+| Gemfile or *.rb files | Ruby | ruby-lsp | `/plugin install ruby-lsp@claude-plugins-official` |
+
+For each detected language, check if the plugin is installed:
+```bash
+claude plugin list 2>/dev/null | grep -q "<plugin-name>" || echo "NOT INSTALLED"
+```
+
+Surface missing plugins as health warnings (respecting the dismissal state):
+> ⚠ TypeScript detected but typescript-lsp not installed. This plugin
+> catches missing imports, type errors, and invalid props automatically
+> after every edit. Install: `/plugin install typescript-lsp`
+
+**Ruby is special — two more prerequisites.** The ruby-lsp plugin is a
+no-op unless the gem is present AND the LSP tool is enabled. The advisory
+MUST state both, or it sends the user into a silent no-op:
+> ⚠ Ruby detected but ruby-lsp not active. Install the plugin
+> (`/plugin install ruby-lsp@claude-plugins-official`), the gem
+> (`gem install ruby-lsp`), and set `ENABLE_LSP_TOOL=1`.
+
+Advisory only — do not block orient for missing plugins.
+
+### hookify advisory (advisory id `plugin:hookify`)
+
+If `.claude/rules/enforcement-pipeline.md` exists in the project AND
+`hookify` is absent from `claude plugin list` output, surface a one-line
+advisory (subject to the dismissal state above — note its signal is
+**static**, so a declined hookify stays declined):
+> ⚠ This project uses the enforcement pipeline but `hookify` isn't
+> installed — it generates hooks from natural language. Install:
+> `/plugin install hookify`
+
+Edge case: if `claude plugin list` fails or hangs, skip silently —
+advisory absence is safe.
+
+### Unmerged branch check
+
+Scan for branches with commits ahead of the main branch that may
+represent unmerged work from prior sessions (especially worktree
+sessions that ended without merging):
+
+```bash
+git for-each-ref --format='%(refname:short)' refs/heads/ | while read branch; do
+  ahead=$(git log --oneline main..$branch 2>/dev/null | wc -l | tr -d ' ')
+  if [ "$ahead" -gt 0 ]; then
+    echo "$branch: $ahead commits ahead"
+  fi
+done
+```
+
+Also check `git worktree list` for active worktrees whose branches
+have diverged from main.
+
+Surface as advisory, then collect the decision via `AskUserQuestion`:
+- `header`: `"Branch"`
+- `question`: "Branch `[name]` has N commits ahead of main. What to do?"
+- `options`:
+  - Merge — "Merge into main now"
+  - Continue — "Leave it, still working on it"
+  - Discard — "Delete the branch (destructive)"
+- `multiSelect: false`
+
+Map: Merge → `git merge [branch]` (surface conflicts if any). Continue →
+no-op. Discard → warn "permanently deletes N commits" and require
+explicit second confirmation before `git branch -D`.
+
+**Known platform limitation:** The Claude Code Agent tool with
+`isolation: "worktree"` branches from the remote tracking ref, not
+local HEAD. Unpushed commits are invisible to worktree agents. Always
+push before spawning worktree agents, or manually review their diffs
+for spurious deletions of unpushed work.
+
+### Briefing file check
+
+Verify that cabinet briefing files exist at `.claude/cabinet/`. Without
+these, cabinet members run without project context and produce generic
+findings.
+
+Check for `.claude/cabinet/_briefing.md` (the hub file). If absent:
+
+> ⚠ No cabinet briefing files found at `.claude/cabinet/`. Cabinet
+> members will run without project context. Run `/onboard` to generate
+> them.
+
+If briefing files exist at the project root (`_briefing.md`,
+`_briefing-identity.md`, etc.) but NOT in `.claude/cabinet/`:
+
+> ⚠ Briefing files found at project root but not in `.claude/cabinet/`
+> where cabinet members expect them. Move them:
+> `mkdir -p .claude/cabinet && mv _briefing*.md .claude/cabinet/`
+
+Advisory — do not block orient for missing briefings.
+
+> **Orient vs Pulse vs Audit:** Orient health checks verify *operational*
+> state — is the system running, is data fresh, are processes alive?
+> Pulse (embedded in orient) verifies *descriptive* accuracy — do counts
+> match, do documented states match reality? Audit verifies *quality*
+> through expert cabinet members — is the code sound, are conventions
+> holding? Orient runs every session; pulse runs inside it; audit runs
+> periodically. Each asks a different question about the same system.
+
+### 6. Auto-Maintenance (core)
+
+Read `phases/auto-maintenance.md` for recurring automated tasks that
+should run every session. These are operations that would decay if left
+to human memory — the anti-entropy principle in action.
+
+**Default (absent/empty):** Run the built-in memory structural validator
+if available: `node scripts/validate-memory.mjs --quiet || true`. Catches
+orphan files, broken references, exceeded caps. Surface violations under
+Attention Items. No periodic consolidation or compaction needed — memory
+is file-based and self-persistent. Projects add additional maintenance
+tasks as they discover operations that need regular execution.
+
+### 7. Activate Cabinet Members (core)
+
+Read `phases/cabinet.md` for which expert cabinet members or lenses
+should be active during this session. Cabinet members watch for specific
+concerns (quality, security, process adherence, non-project items)
+without being explicitly invoked for each decision.
+
+**Skip (absent/empty).**
+
+### 8. Cabinet Consultations (core)
+
+Spawn cabinet members whose `standing-mandate` includes `orient`.
+
+**Discovery:** Read `.claude/skills/_index.json` and filter to entries
+where `standingMandate` includes `"orient"`. Each matching entry has
+a `directives.orient` 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 context loaded in step 1 (project state, recent work)
+- The member's `directives.orient` as the task
+
+Spawn in parallel where possible. If a member has no directive for
+`orient`, 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 1 minute. Include their output in the
+briefing only when they have something to contribute. Silent is fine.
+
+**Persist actionable findings (BLOCKING — printing is not persisting):**
+A finding that exists only as briefing prose evaporates the moment the
+user scrolls past it. After collecting member output:
+
+1. Classify each finding a member surfaced: **informational** (context
+   the user reads once — a status confirmation, color on the current
+   state) 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 BEFORE the briefing renders:
+   - **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: "orient"}`. 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
+     briefing line — loudly, so the user knows nothing persists it.
+3. Each briefing 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.
+
+### 9. Present Briefing (presentation)
+
+Read `phases/briefing.md` for how to present the orientation results.
+This phase controls format, sections, tone, and any time-aware or
+context-aware presentation modes.
+
+**Default (absent/empty):** Present a structured briefing with these
+required sections in this order:
+
+1. **Project State** — version, what's active, high-level status
+2. **Work Items** — active projects, open action counts, flagged/overdue
+   items listed explicitly
+3. **Attention Items** — anything surfaced by health checks, feedback
+   reports, extraction proposals, stale/completable projects
+4. **Maintenance** — memory validator results (if any violations), any project-specific weekly tasks run
+5. **Cabinet Notes** — output from cabinet consultations (only if they
+   had something to say). Actionable findings cite the id they were
+   filed under in step 8 (`dec-…` or `act:…`) — or say **UNTRACKED**
+   when no persistence layer was available.
+
+Keep sections consistent across sessions. Omit a section only if it
+has literally nothing to report (not "nothing interesting" — nothing
+at all). Use the same section names and order every time.
+
+### 10. Show Available Skills (core)
+
+After the briefing, show the user what skills are available. This
+serves the same purpose as a menu at a restaurant — you can't order
+what you don't know exists.
+
+**Default (absent/empty):** Invoke the `/menu` skill. This dynamically
+discovers all skills in `.claude/skills/` (both CC upstream and project-
+specific), reads their frontmatter, and presents them grouped by
+auto-invocable vs manual. It also suggests which skills are most
+relevant given current context.
+
+Read `phases/skills-menu.md` for project-specific overrides (e.g.,
+highlighting certain skills, suppressing others, or changing the
+presentation format).
+
+### 11. 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 (e.g., "runs after work scan, before briefing"). Execute them
+at their declared position.
+
+### 12. Name the Session
+
+Rename the session so the sidebar is scannable. Every session that starts
+with `/orient-classic` looks identical in the history — naming fixes this.
+
+After the briefing and the user's response, derive a short name (3-6
+words) from what the user says they're working on. If the user hasn't
+stated a focus, ask.
+
+## Phase Summary
+
+| Phase | Absent = | What it customizes |
+|-------|----------|-------------------|
+| `context.md` | Default: read CLAUDE.md, status, memory | What files and state to load |
+| `data-sync.md` | Skip | How to sync remote data |
+| `work-scan.md` | Default: pib-db scan + staleness detection | What work items to check |
+| `deferred-check.md` | Skip silently if no triggered items | Surface waiting items and evaluate triggers |
+| `health-checks.md` | Skip | System health checks |
+| `auto-maintenance.md` | Default: memory structural validator | Recurring session-start tasks |
+| `cabinet.md` | Skip | Which cabinet members to activate |
+| `briefing.md` | Default: simple summary | How to present orientation |
+| `skills-menu.md` | Default: invoke /menu | What skills to show and how |
+
+## Quick Mode
+
+Phases are either **core** (maintain system state) or **presentation**
+(surface information for the user). For lightweight sessions where the
+user already knows what they're doing, skip presentation phases. Core
+phases always run because they keep the system healthy.
+
+- **Core phases** (always run): frontier-model watchdog, context,
+  data-sync, work-scan, deferred-check, health-checks, auto-maintenance,
+  cabinet, cabinet-consultations
+- **Presentation phases** (skippable): briefing, skills-menu
+
+A quick orient skips the presentation phases: instead of the full
+briefing and the /menu invocation, output a compact confirmation —
+attention items surfaced by the core phases, then a one-line pointer
+that `/menu` lists available skills.
+
+## Extending
+
+To customize a phase: write content in the corresponding `phases/` file.
+To skip a phase: leave the file empty or don't create it.
+To add a phase the skeleton doesn't define: create a new file in
+`phases/` with a description of when it runs relative to the core
+phases. Claude reads whatever phase files exist at runtime.
+
+Examples of phases mature projects add:
+- Command queue processing (check for instructions from external UIs)
+- Deferred item evaluation (re-check trigger conditions on paused work)
+- Time-aware briefing modes (first session of day vs. returning session)
+- Calendar integration (upcoming events that need preparation)
+
+## Calibration
+
+**Core failure this targets:** Starting a session without context, forcing
+the user to reconstruct state from memory or ask for information the
+system already has.
+
+### Without Skill (Bad)
+
+New session starts. Claude says "How can I help?" The user asks about
+their project status — Claude searches files, reads logs, gives a partial
+picture. The user asks about pending tasks — Claude queries again. The
+user mentions something from last session — Claude has no memory of it.
+
+Three round trips to assemble context that one orientation would have
+surfaced. Meanwhile, an overdue deadline sits unmentioned because nobody
+asked about it.
+
+### With Skill (Good)
+
+New session starts. Claude loads project state, syncs fresh data, scans
+the work backlog, and presents: here's where things stand, here's what
+needs attention, here's what changed since last time. The overdue item
+is surfaced before the user has to remember it. One message, full
+picture. The user decides what to work on from an informed position.