@tekmidian/pai 0.12.2 → 0.13.1

package/dist/daemon-mcp/index.mjs

@@ -1,6 +1,6 @@
 #!/usr/bin/env node
 import { t as PaiClient } from "../ipc-client-CoyUHPod.mjs";
-import { o as loadConfig } from "../config-BuhHWyOK.mjs";
+import { o as loadConfig } from "../config-C8m-tPhP.mjs";
 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 
@@ -3767,6 +3767,580 @@ USE WHEN user says 'trace idea', 'how did X evolve', 'history of X in notes', 'w
 Builds a chronological timeline of how an idea first appeared and evolved across vault notes. Extracts relevant excerpts. Identifies inflection points where framing shifted. Summarizes the evolution arc (first appearance → development → current state).`
 };
 
+//#endregion
+//#region src/daemon-mcp/prompts/reconstruct.ts
+const reconstruct = {
+	description: "Retroactively create session notes from JSONL transcripts and git history when automatic capture failed or was incomplete",
+	content: `## Reconstruct Skill
+
+USE WHEN user says 'reconstruct sessions', 'rebuild session notes', 'recover session notes', 'retroactively create notes', 'create notes from git history', 'notes are missing', 'backfill session notes', 'reconstruct what we did', OR /reconstruct.
+
+### What This Skill Does
+
+Reconstructs session notes for a PAI-registered project by reading:
+1. Git commit history (authoritative record of what was built)
+2. JSONL transcripts (user messages reveal intent, decisions, and context)
+
+Generates one session note per day (or per logical session if multiple sessions existed in a day), numbered sequentially from the highest existing note number.
+
+**ONLY include what can be verified from git log and JSONL. Never invent or embellish content.**
+
+---
+
+### Arguments
+
+| Argument | Default | Description |
+|----------|---------|-------------|
+| \`--days N\` | 7 | Reconstruct notes for the last N days |
+| \`--since YYYY-MM-DD\` | — | Reconstruct from this date forward |
+| \`--until YYYY-MM-DD\` | today | Reconstruct up to this date |
+| \`--dry-run\` | false | Show what would be created without writing files |
+| \`--commit\` | false | Git commit the created notes after writing |
+
+---
+
+### Pre-Action Check
+
+Before starting, verify:
+
+1. **Project is registered**: Run \`pai project detect\` (or \`pai project list\`) to confirm the current project is known to PAI and get its Notes directory path.
+2. **Notes directory exists**: The target directory should be \`Notes/YYYY/MM/\`. Create it if absent.
+3. **Find highest existing note number**: Scan all \`Notes/**/*.md\` files for the pattern \`^NNNN\` to find max note number. New notes continue from there.
+4. **NEVER overwrite existing notes**: If a note file already exists for that date/session, skip it and warn the user.
+
+---
+
+### Step 1 — Find JSONL Files
+
+Claude Code encodes project paths lossily: \`/\`, spaces, dots, hyphens all become \`-\`. A project may have been accessed from multiple base directories (e.g., \`~/Daten/Cloud/Development/ai/PAI\` and \`~/dev/ai/PAI\` both encode to different paths).
+
+**Search strategy — use glob patterns, not exact paths:**
+
+\`\`\`bash
+# Find all encoded project directories that might match this project
+ls ~/.claude/projects/ | grep -i "<project-slug-fragment>"
+
+# For each candidate, look for JSONL files
+ls ~/.claude/projects/<encoded-path>/*.jsonl 2>/dev/null
+
+# Also check the dev copy if the project has one
+# Example: if cwd is ~/dev/ai/PAI, also check ~/Daten/Cloud/Development/ai/PAI encoding
+\`\`\`
+
+Collect ALL JSONL files from ALL matching encoded paths. A session may have been started from either location.
+
+---
+
+### Step 2 — Determine Time Range
+
+Calculate the date range from arguments:
+- \`--days 7\` → from (today - 7 days) to today
+- \`--since 2026-03-01\` → from that date to today (or --until date)
+- Default: last 7 days
+
+---
+
+### Step 3 — Extract Git History
+
+For each day in the range:
+
+\`\`\`bash
+git -C <project-dir> log \\
+  --after="YYYY-MM-DD 00:00:00" \\
+  --before="YYYY-MM-DD 23:59:59" \\
+  --format="%H|%ad|%s" \\
+  --date=short \\
+  --stat
+\`\`\`
+
+Group commits by day. If no commits on a day, skip that day (no note to reconstruct).
+
+Also capture:
+- Files changed per commit (\`--stat\`)
+- Author date (not committer date) for accurate day grouping
+
+---
+
+### Step 4 — Extract User Messages from JSONL
+
+For each JSONL file, parse messages where \`type == "user"\` AND \`message.role == "user"\`:
+
+\`\`\`
+Each line is a JSON object. Look for:
+{
+  "type": "user",
+  "message": {
+    "role": "user",
+    "content": "..." | [{"type": "text", "text": "..."}]
+  },
+  "timestamp": "2026-03-15T10:23:45.000Z"
+}
+\`\`\`
+
+Filter messages by timestamp to match the day being reconstructed.
+
+Extract:
+- The text content of user messages (ignore tool_result entries)
+- Timestamps for ordering
+- Session ID (\`sessionId\` field) to group messages per session
+
+**SKIP** messages that are:
+- Tool results (\`content\` is array with \`type: "tool_result"\`)
+- System-generated (very short single-word messages like "go", "continue")
+- Pure confirmations ("yes", "ok", "sounds good")
+
+**KEEP** messages that reveal:
+- Intent ("build a feature that...", "I need X to do Y")
+- Decisions ("let's use approach A instead of B")
+- Architectural choices
+- Problem descriptions
+- Requirements changes
+
+---
+
+### Step 5 — Identify Logical Sessions
+
+A "logical session" is a continuous work block. Use these signals to split a day into multiple sessions:
+- Gap of more than 3 hours between messages
+- Different JSONL session IDs with significant time gaps
+- Commits with clearly different themes separated by time
+
+If only one logical session exists for a day, create one note. If multiple exist, create one note per session with a suffix: \`NNNN - YYYY-MM-DD - Title.md\`, \`NNNN+1 - YYYY-MM-DD - Title (2).md\`.
+
+---
+
+### Step 6 — Generate Note Title
+
+The note title comes from synthesizing git commits for that session:
+- If commits share a theme: use that theme ("Implement vault indexer")
+- If commits are varied: use the primary/largest change ("Refactor session notes + misc fixes")
+- Use the conventional commit prefix if present: "feat: Add dark mode" → "Add Dark Mode"
+- Title should be 3-7 words, title-case
+
+---
+
+### Step 7 — Write the Note
+
+**Note filename format:** \`NNNN - YYYY-MM-DD - Title.md\`
+
+**Path:** \`Notes/YYYY/MM/NNNN - YYYY-MM-DD - Title.md\`
+
+**Content template:**
+
+\`\`\`markdown
+# Session: [Title]
+
+**Date:** YYYY-MM-DD
+**Status:** Completed
+**Reconstructed:** true (from JSONL + git history)
+
+---
+
+## Work Done
+
+[Group related commits into logical sections by theme/component, not by commit order.
+Each section describes WHAT was built and WHY, derived from commit messages and user messages.
+Use present-tense descriptions: "Add X", "Fix Y", "Refactor Z".]
+
+## Key Decisions
+
+[Architectural choices, technology selections, approach changes.
+ONLY include decisions that are explicitly stated in user messages or strongly implied by commit message changes (e.g., a series of "revert" commits followed by a new approach).
+Format as bullet points.]
+
+## Known Issues at End of Session
+
+[Bugs discovered, things left unfinished.
+Derive from: last commits in session (if they add TODOs or fix-me comments), user messages mentioning problems, or explicit "not done yet" statements.
+Omit this section if nothing can be verified.]
+
+---
+
+**Tags:** #[project-slug] #reconstructed
+\`\`\`
+
+**Filling rules:**
+- Work Done: Always present (use commits as primary source)
+- Key Decisions: Only if verifiable from user messages or commit patterns
+- Known Issues: Only if verifiable; omit section entirely if nothing found
+- Tags: Use the PAI project slug from \`pai project detect\`
+
+---
+
+### Step 8 — Output Summary
+
+After writing (or dry-run preview):
+
+\`\`\`
+Reconstructed N session notes:
+  0042 - 2026-03-13 - Implement Reranker          → Notes/2026/03/
+  0043 - 2026-03-14 - Add Recency Boost            → Notes/2026/03/
+  0044 - 2026-03-15 - Zettelkasten Schema Update   → Notes/2026/03/
+
+Skipped: 2026-03-12 (no commits)
+Skipped: 2026-03-16 (note already exists: 0041 - 2026-03-16 - ...)
+\`\`\`
+
+If \`--commit\` was passed:
+\`\`\`bash
+git add Notes/
+git commit -m "docs: reconstruct session notes for YYYY-MM-DD to YYYY-MM-DD"
+\`\`\`
+
+---
+
+### Step 9 — Extract Knowledge Graph Triples
+
+After reconstructing the session notes, extract structured facts as triples and add them to the temporal knowledge graph. This populates the KG with verifiable facts from the historical record so that future queries (\`kg_query\`, \`pai kg query\`) can answer questions about past decisions.
+
+For each reconstructed note, call \`kg_add\` to store key facts. Examples of facts worth extracting:
+
+- **Project decisions**: \`subject=<project>\`, \`predicate=decided_to\`, \`object=<decision>\`
+- **Version bumps**: \`subject=<project>\`, \`predicate=shipped_version\`, \`object=<version>\`
+- **Architectural choices**: \`subject=<component>\`, \`predicate=uses\`, \`object=<technology>\`
+- **Status changes**: \`subject=<project>\`, \`predicate=status\`, \`object=<current_state>\`
+- **Dependencies**: \`subject=<project>\`, \`predicate=depends_on\`, \`object=<library>\`
+- **Ownership / location**: \`subject=<file_or_module>\`, \`predicate=lives_at\`, \`object=<path>\`
+
+**Procedure for each fact:**
+
+1. Call \`kg_query\` first with the same \`(subject, predicate)\` to check if a fact already exists.
+2. If a new fact supersedes an old one (same subject + predicate, different object), call \`kg_invalidate\` on the old triple's id BEFORE adding the new one.
+3. Call \`kg_add\` with the new fact, setting \`source_session\` to the reconstructed note filename and \`confidence: "EXTRACTED"\`.
+
+**Quality rules:**
+
+- Only extract **atomic, verifiable facts** that can be traced back to a commit, a user message, or an explicit decision in the note.
+- Skip opinions, speculation ("seems like", "probably"), and aspirational statements ("we should").
+- Use \`snake_case\` predicates.
+- Maximum **15 triples per note** — pick the most important.
+- Never invent project names, versions, or paths. Copy them verbatim.
+
+**Alternative (batch mode):** If reconstructing many notes at once, instead of calling \`kg_add\` interactively you may run \`pai kg backfill --project <slug>\` from the terminal after the notes are written. The backfill walks every note in \`Notes/YYYY/MM/\`, runs the same extractor the session-summary-worker uses, and is idempotent (state file at \`~/.config/pai/kg-backfill-state.json\`).
+
+After extraction, append a one-line note to the summary output:
+\`\`\`
+KG: extracted N triples (M added, K superseded) across the reconstructed notes.
+\`\`\`
+
+---
+
+### Anti-Defaults
+
+- **NEVER overwrite existing notes.** Skip silently, report in summary.
+- **NEVER invent content.** If a decision isn't in the JSONL or deducible from commits, leave it out.
+- **NEVER fabricate commit messages.** Copy them verbatim from git log.
+- **NEVER assume intent from assistant messages.** Only user messages reveal intent.
+- **NEVER add speculation.** "It appears that..." or "likely..." should not appear in notes.
+- **DO trim noise.** Skip trivial messages ("ok", "yes", "go") that add no signal.
+- **DO handle missing JSONL gracefully.** If no JSONL files found, generate notes from git only — mark the "Key Decisions" section as "Not available (no JSONL transcript found)".`
+};
+
+//#endregion
+//#region src/daemon-mcp/prompts/whisper.ts
+const whisper = {
+	description: "Manage whisper rules — persistent behavioral constraints injected on every prompt",
+	content: `## Whisper Rules Management
+
+USE WHEN user says 'whisper', 'add whisper rule', 'remove whisper rule', 'list whisper rules', 'show whisper rules', '/whisper', OR wants to manage persistent behavioral rules.
+
+Manage the rules that PAI injects into every prompt via the whisper-rules hook.
+
+Rules are stored in \`~/.claude/whisper-rules.md\` — one rule per line, plain text.
+The hook reads this file on every UserPromptSubmit and injects it as a \`<system-reminder>\`.
+Rules survive compaction, /clear, and session restarts.
+
+### Usage
+
+- \`/whisper\` — show current rules
+- \`/whisper add <rule>\` — add a new rule
+- \`/whisper remove <number>\` — remove rule by line number
+- \`/whisper list\` — list rules with line numbers
+- \`/whisper clear\` — remove all rules (with confirmation)
+
+### Workflow
+
+**Show current rules:**
+Read \`~/.claude/whisper-rules.md\` and display each rule with a line number.
+If the file doesn't exist, say "No whisper rules configured."
+
+**Add a rule:**
+Append the rule as a new line to \`~/.claude/whisper-rules.md\`.
+Create the file if it doesn't exist.
+Do NOT add duplicate rules — check if a similar rule already exists.
+
+**Remove a rule:**
+Read the file, remove the line at the given number, write the file back.
+Show the removed rule for confirmation.
+
+**Clear all rules:**
+Ask for confirmation first ("This will remove all N rules. Confirm?").
+Only proceed if the user explicitly confirms.
+
+### Important
+
+- Rules should be short, imperative statements (1-2 lines max)
+- Every rule is injected on EVERY prompt — keep the list focused on truly critical rules
+- Too many rules dilute their effectiveness and waste tokens
+- The file does not exist by default — PAI ships the hook, the user adds their own rules
+- Rules are global (shared across all sessions and projects)
+`
+};
+
+//#endregion
+//#region src/daemon-mcp/prompts/consolidate.ts
+const consolidate = {
+	description: "Consolidate and clean up session notes — merge duplicates, fix titles, renumber sequentially",
+	content: `## Consolidate Skill
+
+USE WHEN user says 'consolidate notes', 'clean up notes', 'merge duplicate notes', 'fix session notes', 'deduplicate notes', '/consolidate', OR notes directory has duplicates or bad titles.
+
+### What This Skill Does
+
+Cleans up a project's session notes directory by:
+1. Finding duplicate/superseded notes (same topic, different compaction snapshots)
+2. Keeping the most complete version of each topic
+3. Fixing garbage titles (renaming files and H1 headings)
+4. Renumbering sequentially (0001, 0002, 0003...)
+5. Optionally committing the cleanup
+
+### Arguments
+
+- No args: consolidate current project
+- \`--project <slug>\`: consolidate a specific project
+- \`--dry-run\`: show what would change without modifying files
+
+### Workflow
+
+**Step 1: Find the notes directory**
+Use \`pai project detect\` to find the current project, then locate \`Notes/YYYY/MM/\` for the current month.
+
+**Step 2: Inventory all notes**
+List all .md files in the month directory. For each note, read:
+- Filename (number, date, title)
+- H1 heading inside the file
+- Line count (proxy for completeness)
+- First 20 lines (to understand the topic)
+
+**Step 3: Group by topic**
+Group notes that cover the same topic. Two notes are "same topic" if:
+- Their filenames are identical (except the number)
+- OR their H1 titles share >50% word overlap (Jaccard similarity)
+- OR one is a strict subset of the other (shorter note's content is contained in the longer one)
+
+**Step 4: For each group, keep the best**
+- Keep the note with the most lines (most complete)
+- Delete the others
+- If the kept note has a bad title (garbage from user messages, too long, generic), rename it based on the H1 or the Focus/Work Done section
+
+**Step 5: Renumber sequentially**
+After deduplication, renumber all remaining notes: 0001, 0002, 0003...
+Preserve the date and title in the filename.
+
+**Step 6: Fix H1 headings**
+Ensure each note's H1 matches its filename title and number.
+
+**Step 7: Report and optionally commit**
+Show what was done:
+- Notes deleted (with reason)
+- Notes renamed (old → new)
+- Notes renumbered
+Then ask if the user wants to commit: \`git add Notes/ && git commit -m "docs: consolidate session notes"\`
+
+### Title Quality Rules
+
+A title is "garbage" if it:
+- Quotes a user message verbatim (conversational tone, starts with lowercase)
+- Contains \`[object Object]\`, hex hashes, \`task-notification\`
+- Is longer than 80 characters
+- Is generic: "New Session", "Continued Session", "Session N"
+
+Fix by reading the note's ## Work Done or **Focus:** line and deriving a descriptive title.
+
+### Safety
+
+- NEVER delete a note that is the ONLY one for its topic
+- NEVER delete notes from previous months (only consolidate current month)
+- Show the plan before executing (unless --force)
+- Always preserve the most complete version
+`
+};
+
+//#endregion
+//#region src/daemon-mcp/prompts/advisor.ts
+const advisor = {
+	description: "Manage budget-aware advisor mode — control model tiering for subagents based on weekly usage",
+	content: `## Advisor Mode Management
+
+USE WHEN user says 'advisor', 'budget mode', 'set advisor', 'save budget', '/advisor', 'how much budget', OR wants to control model tiering for subagents.
+
+ALSO USE WHEN user says plain-language budget/mode phrases like:
+- "go easy on the budget", "save tokens", "be conservative" → set mode to conservative
+- "use haiku only", "strict mode", "budget is tight" → set mode to strict
+- "lock it down", "critical mode", "almost out of budget" → set mode to critical
+- "go full power", "use whatever model", "no budget constraints", "normal mode", "unrestricted" → set mode to normal
+- "back to auto", "reset advisor", "let the budget decide" → set mode to auto
+
+When you detect these, write the appropriate mode to \`~/.claude/advisor-mode.json\` and confirm what you did.
+
+Advisor mode controls which models subagents use, based on weekly budget consumption.
+
+### Configuration
+
+The config file is at \`~/.claude/advisor-mode.json\`:
+\`\`\`json
+{
+  "weeklyBudgetPercent": 90,
+  "mode": "auto"
+}
+\`\`\`
+
+### Usage
+
+- \`/advisor\` — show current mode and budget
+- \`/advisor set <percent>\` — set weekly budget percentage (triggers auto mode calculation)
+- \`/advisor mode <normal|conservative|strict|critical>\` — force a specific mode
+- \`/advisor auto\` — reset to auto mode (derives from weeklyBudgetPercent)
+- \`/advisor force <model>\` — force all subagents to use a specific model (haiku/sonnet/opus)
+- \`/advisor reset\` — remove the config file (no advisor guidance injected)
+- Or just say it in plain language — see triggers above
+
+### Mode Thresholds (auto mode)
+
+| Budget Used | Mode | Subagent Model | Behavior |
+|-------------|------|----------------|----------|
+| < 60% | normal | Any | No constraints |
+| 60-80% | conservative | Haiku preferred | Escalate to sonnet only if haiku insufficient |
+| 80-92% | strict | Haiku only | Minimize spawning, no opus subagents |
+| > 92% | critical | Haiku or none | Essential work only, minimize all token usage |
+
+### Workflow
+
+**Show current status:**
+Read \`~/.claude/advisor-mode.json\`. Display the mode, budget percentage, and what model constraints are active.
+
+**Update budget percentage:**
+The user reads their weekly budget from the statusline (e.g., "7d: 63% → Fr. 08:00").
+Write the percentage to \`weeklyBudgetPercent\` in the config file.
+If mode is "auto", the whisper hook will compute the appropriate tier.
+
+**Force a mode:**
+Set \`mode\` to the desired value. Overrides auto calculation.
+Useful when the user wants to be aggressive (normal) or cautious (strict) regardless of actual budget.
+
+**Force a model:**
+Set \`forceModel\` to "haiku", "sonnet", or "opus". ALL subagents will use this model.
+Useful for testing or when the user knows exactly what they want.
+
+### Integration
+
+The advisor config is read by the whisper-rules hook on every prompt. Changes take effect immediately — no restart needed. The guidance appears as an ADVISOR MODE line in the system-reminder alongside the whisper rules.
+`
+};
+
+//#endregion
+//#region src/daemon-mcp/prompts/tasks.ts
+const tasks = {
+	description: "Run the task bus — read cross-session work from the tracker, dispatch it to the sessions that own it, and file findings",
+	content: `## Task Bus
+
+USE WHEN user says 'morning routine', 'what needs doing', 'run the routine', 'check my tasks', 'dispatch tasks', 'file a finding', 'add this to todoist', 'what did we find', OR /tasks.
+
+The bus is shared state that outlives any one session. Session-local work stays in each project's \`Notes/TODO.md\`; the bus carries work that is **broader than one session** — findings discovered sideways, and work belonging to a project other than the one you are in.
+
+### Pre-Action Check (MANDATORY)
+
+\`\`\`bash
+pai task list --limit 1
+\`\`\`
+
+If this prints "Task bus is not configured", tell the user to run \`pai setup\` and complete the Task Bus step, then stop. Do not work around it by calling the Todoist MCP directly — the bus resolves ownership against the PAI registry, which the raw MCP knows nothing about.
+
+---
+
+### Workflow 1 — Morning Routine
+
+**Trigger:** "morning routine", "what needs doing", "run the routine".
+
+**Step 1 — Read what is open**
+\`\`\`bash
+pai task list --today      # due today or overdue; drop --today for everything
+\`\`\`
+
+**Step 2 — Report before acting.** Group by owner, lead with overdue and \`p1\`. Never dispatch silently — the user sees the list before sessions start receiving work.
+
+**Step 3 — Dispatch**
+\`\`\`bash
+pai task dispatch --today --dry-run   # always preview
+pai task dispatch --today             # then, once approved
+\`\`\`
+
+| Symbol | Outcome | Meaning |
+|---|---|---|
+| \`→\` | delivered | Sent to an already-running session |
+| \`+\` | spawned | None running; one was launched, then sent to |
+| \`?\` | unrouted | No owner resolved — stays in the findings inbox |
+| \`!\` | unlaunchable | Owner resolved but has no PAI alias to launch |
+| \`·\` | skipped | Auto-dispatch off, or no transport — reported only |
+
+On \`!\`: the fix is \`pai project name <identifier> <shortname>\`. Only aliased projects can be dispatched to — say this rather than reporting a vague failure.
+
+On \`?\`: normal, not an error. Triage is pending.
+
+**Step 4 — Report honestly.** State what actually reached a session. If nothing was dispatched because auto-dispatch is off, say so plainly rather than implying work was handed off.
+
+---
+
+### Workflow 2 — File a Finding
+
+**Trigger:** "file a finding", "add this to todoist", or **any time you discover something outside the current task**.
+
+\`\`\`bash
+pai task add "Short actionable title" \\
+  --owner <project> \\
+  --body "Full procedure AND reasoning" \\
+  --priority p2 \\
+  --url "hook://..."
+\`\`\`
+
+Rules:
+- **\`--body\` is not optional in practice.** Enough that the task is actionable months later, or by the user alone, without re-deriving anything. A bare title is a reminder that something was once known — worthless later.
+- **Omit \`--owner\` when you genuinely do not know.** It lands in the findings inbox for triage. Guessing is worse than leaving it unrouted.
+- **Prefer \`hook://\` URLs over file paths** for \`--url\` (get one via \`mcp__hook__hookmark_link\`). They survive renames and open in DEVONthink To Go on iOS. Plain paths are the fallback.
+- **No generic checklist items.** A recurring item earns its place only because something *actually failed silently*. Otherwise the routine becomes noise and gets ignored.
+
+---
+
+### Workflow 3 — Triage
+
+**Trigger:** "triage", "what did we find", or weekly.
+
+\`\`\`bash
+pai task list --limit 100
+\`\`\`
+
+For each \`unrouted\` item, decide with the user: assign an owner, act now, or delete. Assigning means adding a \`pai:<project>\` label on the tracker — authoritative, and it survives the task being moved.
+
+**The findings inbox should normally be empty.** If it is filling up, the bus has become another place for items to rot. Say so — that is a judgement about the system, not about the user.
+
+---
+
+### Ownership
+
+1. A \`pai:<project>\` label — **authoritative**
+2. Enclosing sub-project name matched against PAI aliases — fallback
+3. Otherwise unrouted
+
+A label matching nothing does **not** fall through to the container. The user meant somewhere specific; quietly routing elsewhere is worse than not routing.
+
+### Notes
+
+- \`pai task done <id>\` closes a task. Dispatched tasks instruct the receiving session to do this, so work is not dispatched twice.
+- One-way by design: PAI and its sessions write; a routine reads. Nothing reads the tracker back into PAI state.
+- Architecture and verified API constraints: \`Notes/docs/task-bus.md\`.
+`
+};
+
 //#endregion
 //#region src/daemon-mcp/resources/aesthetic.ts
 const aesthetic = {
@@ -4646,7 +5220,12 @@ async function startShim() {
 		"vault-connect": vaultConnect,
 		"vault-emerge": vaultEmerge,
 		"vault-orphans": vaultOrphans,
-		"vault-trace": vaultTrace
+		"vault-trace": vaultTrace,
+		"reconstruct": reconstruct,
+		"whisper": whisper,
+		"consolidate": consolidate,
+		"advisor": advisor,
+		"tasks": tasks
 	};
 	for (const [promptName, skill] of Object.entries(SKILL_PROMPTS)) server.prompt(promptName, skill.description, () => ({ messages: [{
 		role: "user",