@lifeaitools/rdc-skills 0.24.10 → 0.24.12

package/skills/channel-formatter/SKILL.md

@@ -83,11 +83,33 @@ skills named in the scope boundary.
 
 1. **Detect channel or pack mode** from the request using the tables above.
 2. **Classify the source**: already-drafted copy, long article/report, transcript, notes, or brief.
-3. **For long sources**, extract thesis, audience, proof points, CTA, constraints, and factual risks before writing.
-4. **Jump to the target channel or pack section** below and apply all rules exactly — do not rely on memory.
-5. **Never mix** markdown conventions across channels.
-6. If the channel or pack is ambiguous, ask once: "Is this for [Channel A] or [Channel B]?"
-7. Produce the formatted or repurposed output directly as the deliverable.
+3. **For thin or under-specified long sources**, enrich before writing instead
+   of inventing context:
+   - If the source names a corpus path, read it.
+   - Otherwise search/read the approved corpus first when available. Resolve
+     `CORPUS_ROOT` (usually `H:/My Drive/global-corpus`) and
+     `LOCAL_CORPUS_ROOT` (usually `C:/Dev/local-corpus`) before searching the
+     repo. If environment variables are not visible, try those default paths.
+   - The corpus search must use an explicit corpus path in the tool arguments
+     (`H:/My Drive/global-corpus` or `C:/Dev/local-corpus`). A relative repo
+     search does not count as enrichment.
+   - Use `Grep`/`Glob`/`Read` or the environment's equivalent tools so the
+     transcript records what was consulted.
+   - Use web search only when the requested output needs current/public facts,
+     the user asks for external context, or corpus context is absent and network
+     search is allowed. Cite/use only what the search actually supports.
+   - Searching only the project repo is not enough for enrichment unless the
+     source itself points to a repo-local corpus file.
+   - If neither corpus nor web context is available, keep the output sparse and
+     mark missing context in assumptions; do not fill gaps creatively.
+4. **For long sources**, extract thesis, audience, proof points, CTA, constraints, and factual risks before writing.
+5. **Jump to the target channel or pack section** below and apply all rules exactly — do not rely on memory.
+6. **Never mix** markdown conventions across channels.
+7. If the channel or pack is ambiguous, ask once: "Is this for [Channel A] or [Channel B]?"
+8. Produce the formatted or repurposed output directly as the deliverable.
+9. Treat extraction notes and source-fidelity guardrails as internal scratchwork.
+   Do not print a "Long-Source Extraction Checklist", factual guardrail list, or
+   absent-topic list unless the user explicitly asks for analysis.
 
 ## Hard Rules (all channels)
 
@@ -167,7 +189,7 @@ Repurpose one source for an announcement:
 - 3 CTA variants
 
 ### Long-Source Extraction Checklist
-Before writing from a long source, identify:
+Before writing from a long source, identify internally:
 - **Thesis:** the central argument or announcement
 - **Audience:** who this is for
 - **Proof:** facts, examples, data, names, dates, or quotes explicitly present
@@ -179,13 +201,39 @@ Before writing from a long source, identify:
 ### Source-Fidelity Rules
 - Do not invent statistics, dates, quotes, citations, partnerships, revenue,
   legal claims, customer names, or outcomes.
+- Do not infer adjacent finance/reporting concepts that sound plausible but are
+  absent from the source, such as pro forma assumptions, reporting cadence,
+  offset mechanisms, governance structures, verification status, or portfolio
+  implications.
+- If corpus or web context was consulted, use it only for facts it directly
+  supports. Do not blend generic domain knowledge into the source as if it were
+  documented.
+- If the source provides a theme label without an explanation, keep the theme
+  label or paraphrase it conservatively. Do not add explanatory clauses that
+  define how it works, who governs it, how it is verified, how often it reports,
+  or what financial model it opposes unless those details are explicit.
+- Do not contrast patient capital with quarters, earnings calls, fund cycles,
+  exits, venture speed, or portfolio management unless those words or concepts
+  appear in the source or consulted corpus/web material.
 - Do not upgrade tentative language into certainty.
 - Do not turn illustrative examples into facts.
 - Preserve caveats when they affect meaning.
 - If a stronger hook needs a proof point the source does not provide, write a
   proof-neutral hook instead.
+- If the source says a topic is absent, excluded, or not mentioned, treat that
+  as an internal guardrail. Do not repeat the absent topic in public-facing
+  channel copy, assumptions, caveats, notes, headings, or summaries unless the
+  user explicitly asks for a contrast, compliance note, or risk disclosure.
+  Strip absent-topic lists from the deliverable entirely.
 - When assumptions are material, include a short "Assumptions:" line before the
   deliverable rather than burying uncertainty in polished copy.
+- Do not output your extraction checklist. The deliverable should start with the
+  requested channel/pack output, except for a brief "Assumptions:" line when a
+  material gap affects the copy.
+- If you include an "Assumptions:" line, limit it to missing useful inputs such
+  as org name, audience, location, date, CTA, or link. Never list absent,
+  excluded, or not-mentioned topics in the assumptions line. If the only
+  uncertainty is an absent-topic guardrail, omit the assumptions line.
 
 ---
 
@@ -231,6 +279,8 @@ channel-native. A pack is not a generic summary repeated in several lengths.
   email/web, concise in Slack.
 - Use channel-specific formatting rules from the sections below.
 - If source proof is weak, use curiosity and framing instead of inflated claims.
+- Do not include extraction notes, guardrail notes, or absent-topic caveats in
+  the pack. Those are reasoning aids, not channel outputs.
 
 ---
 

package/skills/collab/SKILL.md

@@ -1,239 +1,239 @@
----
-name: rdc:collab
-description: "Usage `rdc:collab --session <session_id>` — Bidirectional relay with a claude.ai session — read inbox, do work, write outbox, loop. Use when coordinating with a parallel claude.ai conversation."
----
-
-> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
-> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
-> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
-
-> **Sandbox contract:** This skill honors `RDC_TEST=1` per `guides/agent-bootstrap.md` § RDC_TEST Sandbox Contract. Destructive external calls short-circuit under the flag. Chitchat relay writes (`chitchat_reply`) and git push are skipped under `RDC_TEST=1`.
-
-
-# /rdc:collab — Claude Code Collab Session Listener
-> Invoked as: `/rdc:collab --session <session_id>`
-> You are the build/execute half of a live collab session with claude.ai.
-> Transport: chitchat MCP tools (`chitchat_poll` / `chitchat_reply`) + SSE stream
-> Dave is watching this terminal and can interject at any time.
-
----
-
-## When to Use
-- Project lead wants to delegate a task to a claude.ai session
-- You need bidirectional relay between this CLI agent and a claude.ai coworker
-- An async work handoff is in progress via the chitchat relay
-
-## Arguments
-
-- `rdc:collab --session <id>` — start or resume a collab relay with the given session ID
-
-## What This Is
-
-claude.ai writes tasks into your inbox via `chitchat_send`. The clauth daemon
-queues them and — if you are connected to the SSE stream — pushes the event
-immediately (zero-latency). You read, act, commit, reply via `chitchat_reply`,
-and loop. Dave can watch everything in this terminal and interject by typing —
-treat anything Dave types as a high-priority override.
-
----
-
-## Step 1 — Parse session ID
-
-Extract `--session <uuid>` from args.
-
-If no `--session`, call `chitchat_list` and show all active sessions.
-
----
-
-## Step 2 — Initialize (chitchat-native)
-
-Call `chitchat_list` to verify the session exists in the daemon.
-
-If the session is not found:
-```
-Session <id> not found in clauth daemon.
-Start a session from claude.ai first:
-  chitchat_start(name: "<session-slug>")
-Then pass the returned session_id here.
-```
-
-Send the ready signal via MCP:
-```
-chitchat_reply(session_id, "Claude Code connected. Ready to receive tasks.\ncwd: <rootPath>")
-```
-
-Print to terminal:
-```
-[rdc:collab] Session <id> active (chitchat transport).
-SSE stream: http://127.0.0.1:52437/chitchat/<id>/stream
-Waiting for messages from claude.ai... (Ctrl+C to end)
-```
-
-Note: File relay at `.rdc/relay/sessions/` is kept for backwards compatibility
-but is no longer the primary transport. Chitchat MCP + SSE is the default.
-
----
-
-## Step 3 — Wait for message (SSE-first, poll-fallback)
-
-### Primary path — SSE (zero-latency)
-
-Connect to the SSE stream and wait for the daemon to push a message:
-
-```bash
-curl -s -N --max-time 30 http://127.0.0.1:52437/chitchat/<session_id>/stream
-```
-
-The stream emits:
-- `event: message` lines with `data: <JSON>` when `chitchat_send` fires from claude.ai
-- `: keepalive` comment lines every 15s (ignore these)
-
-**When a `data:` event arrives:** parse the JSON directly — it contains the
-message. The SSE stream drains the inbox as it delivers; do NOT call
-`chitchat_poll` after receiving via SSE. Proceed directly to Step 4 with the
-parsed message body.
-
-**If 30s elapses with no message event (only keepalives or silence):**
-Print `[rdc:collab] Still listening...` and retry SSE immediately. After 10
-consecutive 30s timeouts (5 min idle), print a longer heartbeat but keep
-looping.
-
-**⛔ curl exit 28 (`--max-time`) is SUCCESS, not failure, on an SSE read.**
-`curl --max-time 30` ALWAYS exits 28 at the timeout boundary — that is normal for
-a long-lived SSE stream and says nothing about delivery. If a `data:` event was
-received in the output, process it and proceed to Step 4 — do NOT treat exit 28 as
-a curl failure (lesson 2026-06-08-collab-sse-exit-28-is-success: exit 28 arrived
-together with a full `event: message` / `data: {...}` payload, and reading it as a
-failure misclassified a zero-latency delivery). Only **connection-refused or a
-non-200** is a real curl failure that triggers the polling fallback.
-
-**If curl fails (daemon restart, connection refused, non-200 — NOT a bare exit 28
-with a delivered `data:` event):** fall back to polling path below.
-
-### Fallback path — polling (2s interval)
-
-Use this path only when SSE is unavailable:
-
-```
-loop:
-  result = chitchat_poll(session_id)
-  if result.status == "ready":
-    → proceed to Step 4 with result.message
-  else (status == "idle"):
-    wait 2 seconds
-    continue loop
-```
-
-**`chitchat_poll` return shapes:**
-- `{ status: "idle" }` — inbox empty, keep polling
-- `{ status: "ready", message: "..." }` — message waiting, consume it
-
----
-
-## Step 4 — Process message
-
-You now have the message body (from SSE `data:` JSON or `chitchat_poll` result).
-
-Check if the message begins with `type: stop` (literal prefix) or contains a
-`type` field equal to `"stop"` in the JSON.
-
-**`type: stop`** → go to Step 7.
-
-**Anything else (default: task/message):**
-
-Print to terminal:
-```
-[rdc:collab] Turn <N> from claude.ai:
-──────────────────────────────────────
-<message body>
-──────────────────────────────────────
-```
-
----
-
-## Step 5 — Do the work
-
-Act on the message. Full Claude Code capabilities:
-- File edits, git commits to `develop`
-- Supabase RPC queries
-- Type-checks: `npx tsc --noEmit` (never `pnpm build`)
-- Run skills: `/rdc:plan`, `/rdc:fixit`, etc.
-- Answer questions directly
-
-Follow `.rdc/guides/agent-bootstrap.md` rules throughout.
-
-For long tasks, stream progress updates mid-work:
-```
-chitchat_reply(session_id, "Turn <N> in progress: <what you've done so far>...")
-```
-This lets claude.ai see progress immediately rather than waiting for the full
-response.
-
----
-
-## Step 6 — Send response
-
-When work is done, send the response via MCP:
-
-```
-chitchat_reply(session_id, "<response body>")
-```
-
-Response body format:
-```
-Turn <N> complete.
-Commits: <sha1, sha2 or none>
-
-<what you did, what you found, any questions or decisions needed from claude.ai>
-```
-
-Print to terminal:
-```
-[rdc:collab] Turn <N> done. Response sent via chitchat_reply.
-Waiting for next message...
-```
-
-Return to Step 3.
-
----
-
-## Step 7 — End session
-
-Received `type: stop` message, or Dave pressed Ctrl+C.
-
-Send final summary via MCP:
-```
-chitchat_reply(session_id, "Session complete.\nTurns: <N>\nCommits: <list or none>\nOpen items: <anything unresolved>")
-```
-
-Then call:
-```
-chitchat_stop(session_id)
-```
-
-Print:
-```
-[rdc:collab] Session ended.
-```
-
----
-
-## Dave Interjections
-
-If Dave types in this terminal during a turn:
-- Treat it as an override injected into the current task
-- Acknowledge it in your `chitchat_reply` response
-- If it changes direction mid-task, note what you stopped and why
-- ⛔ **When an interjection appears to CONTRADICT the task premise, restate your
-  understanding in ONE sentence and confirm before branching into a wide
-  `AskUserQuestion` menu.** A tight "I read this as X — correct?" reconciles faster
-  than a multiple-choice and avoids acting on a misread premise (lesson
-  2026-06-08-collab-premise-contradicting-interjection: "there is no pm2 this
-  replaces it" was read as "PM2 is abolished as the transport" and triggered a
-  3-option transport menu, when it meant "there was no dev *site* yet — push to
-  the unchanged PM2 path"; the wide menu over-committed to one interpretation and
-  cost a round).
-
-## Capture lessons (exit step)
-
-Before the final verdict line, follow `.rdc/guides/lessons-learned-spec.md` § Capture procedure. If this run taught something non-obvious — a first root-cause theory that turned out wrong, the documented/standard path not working, a missing gate or check that cost a round, or a surprising tool/infra behavior — write one `.rdc/lessons/<YYYY-MM-DD>-collab-<short-slug>.md` per lesson using the schema in that spec. Set `scope` (`simple` | `architectural`) and `status` (`open`, or `applied` if you shipped the fix in this same run, with the commit linked). Commit the lesson file(s) on `develop` alongside the run's other commits, and note "N lessons captured" in your verdict/summary. A run that taught nothing writes nothing — absence is the default.
+---
+name: rdc:collab
+description: "Usage `rdc:collab --session <session_id>` — Bidirectional relay with a claude.ai session — read inbox, do work, write outbox, loop. Use when coordinating with a parallel claude.ai conversation."
+---
+
+> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
+> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
+> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
+
+> **Sandbox contract:** This skill honors `RDC_TEST=1` per `guides/agent-bootstrap.md` § RDC_TEST Sandbox Contract. Destructive external calls short-circuit under the flag. Chitchat relay writes (`chitchat_reply`) and git push are skipped under `RDC_TEST=1`.
+
+
+# /rdc:collab — Claude Code Collab Session Listener
+> Invoked as: `/rdc:collab --session <session_id>`
+> You are the build/execute half of a live collab session with claude.ai.
+> Transport: chitchat MCP tools (`chitchat_poll` / `chitchat_reply`) + SSE stream
+> Dave is watching this terminal and can interject at any time.
+
+---
+
+## When to Use
+- Project lead wants to delegate a task to a claude.ai session
+- You need bidirectional relay between this CLI agent and a claude.ai coworker
+- An async work handoff is in progress via the chitchat relay
+
+## Arguments
+
+- `rdc:collab --session <id>` — start or resume a collab relay with the given session ID
+
+## What This Is
+
+claude.ai writes tasks into your inbox via `chitchat_send`. The clauth daemon
+queues them and — if you are connected to the SSE stream — pushes the event
+immediately (zero-latency). You read, act, commit, reply via `chitchat_reply`,
+and loop. Dave can watch everything in this terminal and interject by typing —
+treat anything Dave types as a high-priority override.
+
+---
+
+## Step 1 — Parse session ID
+
+Extract `--session <uuid>` from args.
+
+If no `--session`, call `chitchat_list` and show all active sessions.
+
+---
+
+## Step 2 — Initialize (chitchat-native)
+
+Call `chitchat_list` to verify the session exists in the daemon.
+
+If the session is not found:
+```
+Session <id> not found in clauth daemon.
+Start a session from claude.ai first:
+  chitchat_start(name: "<session-slug>")
+Then pass the returned session_id here.
+```
+
+Send the ready signal via MCP:
+```
+chitchat_reply(session_id, "Claude Code connected. Ready to receive tasks.\ncwd: <rootPath>")
+```
+
+Print to terminal:
+```
+[rdc:collab] Session <id> active (chitchat transport).
+SSE stream: http://127.0.0.1:52437/chitchat/<id>/stream
+Waiting for messages from claude.ai... (Ctrl+C to end)
+```
+
+Note: File relay at `.rdc/relay/sessions/` is kept for backwards compatibility
+but is no longer the primary transport. Chitchat MCP + SSE is the default.
+
+---
+
+## Step 3 — Wait for message (SSE-first, poll-fallback)
+
+### Primary path — SSE (zero-latency)
+
+Connect to the SSE stream and wait for the daemon to push a message:
+
+```bash
+curl -s -N --max-time 30 http://127.0.0.1:52437/chitchat/<session_id>/stream
+```
+
+The stream emits:
+- `event: message` lines with `data: <JSON>` when `chitchat_send` fires from claude.ai
+- `: keepalive` comment lines every 15s (ignore these)
+
+**When a `data:` event arrives:** parse the JSON directly — it contains the
+message. The SSE stream drains the inbox as it delivers; do NOT call
+`chitchat_poll` after receiving via SSE. Proceed directly to Step 4 with the
+parsed message body.
+
+**If 30s elapses with no message event (only keepalives or silence):**
+Print `[rdc:collab] Still listening...` and retry SSE immediately. After 10
+consecutive 30s timeouts (5 min idle), print a longer heartbeat but keep
+looping.
+
+**⛔ curl exit 28 (`--max-time`) is SUCCESS, not failure, on an SSE read.**
+`curl --max-time 30` ALWAYS exits 28 at the timeout boundary — that is normal for
+a long-lived SSE stream and says nothing about delivery. If a `data:` event was
+received in the output, process it and proceed to Step 4 — do NOT treat exit 28 as
+a curl failure (lesson 2026-06-08-collab-sse-exit-28-is-success: exit 28 arrived
+together with a full `event: message` / `data: {...}` payload, and reading it as a
+failure misclassified a zero-latency delivery). Only **connection-refused or a
+non-200** is a real curl failure that triggers the polling fallback.
+
+**If curl fails (daemon restart, connection refused, non-200 — NOT a bare exit 28
+with a delivered `data:` event):** fall back to polling path below.
+
+### Fallback path — polling (2s interval)
+
+Use this path only when SSE is unavailable:
+
+```
+loop:
+  result = chitchat_poll(session_id)
+  if result.status == "ready":
+    → proceed to Step 4 with result.message
+  else (status == "idle"):
+    wait 2 seconds
+    continue loop
+```
+
+**`chitchat_poll` return shapes:**
+- `{ status: "idle" }` — inbox empty, keep polling
+- `{ status: "ready", message: "..." }` — message waiting, consume it
+
+---
+
+## Step 4 — Process message
+
+You now have the message body (from SSE `data:` JSON or `chitchat_poll` result).
+
+Check if the message begins with `type: stop` (literal prefix) or contains a
+`type` field equal to `"stop"` in the JSON.
+
+**`type: stop`** → go to Step 7.
+
+**Anything else (default: task/message):**
+
+Print to terminal:
+```
+[rdc:collab] Turn <N> from claude.ai:
+──────────────────────────────────────
+<message body>
+──────────────────────────────────────
+```
+
+---
+
+## Step 5 — Do the work
+
+Act on the message. Full Claude Code capabilities:
+- File edits, git commits to `develop`
+- Supabase RPC queries
+- Type-checks: `npx tsc --noEmit` (never `pnpm build`)
+- Run skills: `/rdc:plan`, `/rdc:fixit`, etc.
+- Answer questions directly
+
+Follow `.rdc/guides/agent-bootstrap.md` rules throughout.
+
+For long tasks, stream progress updates mid-work:
+```
+chitchat_reply(session_id, "Turn <N> in progress: <what you've done so far>...")
+```
+This lets claude.ai see progress immediately rather than waiting for the full
+response.
+
+---
+
+## Step 6 — Send response
+
+When work is done, send the response via MCP:
+
+```
+chitchat_reply(session_id, "<response body>")
+```
+
+Response body format:
+```
+Turn <N> complete.
+Commits: <sha1, sha2 or none>
+
+<what you did, what you found, any questions or decisions needed from claude.ai>
+```
+
+Print to terminal:
+```
+[rdc:collab] Turn <N> done. Response sent via chitchat_reply.
+Waiting for next message...
+```
+
+Return to Step 3.
+
+---
+
+## Step 7 — End session
+
+Received `type: stop` message, or Dave pressed Ctrl+C.
+
+Send final summary via MCP:
+```
+chitchat_reply(session_id, "Session complete.\nTurns: <N>\nCommits: <list or none>\nOpen items: <anything unresolved>")
+```
+
+Then call:
+```
+chitchat_stop(session_id)
+```
+
+Print:
+```
+[rdc:collab] Session ended.
+```
+
+---
+
+## Dave Interjections
+
+If Dave types in this terminal during a turn:
+- Treat it as an override injected into the current task
+- Acknowledge it in your `chitchat_reply` response
+- If it changes direction mid-task, note what you stopped and why
+- ⛔ **When an interjection appears to CONTRADICT the task premise, restate your
+  understanding in ONE sentence and confirm before branching into a wide
+  `AskUserQuestion` menu.** A tight "I read this as X — correct?" reconciles faster
+  than a multiple-choice and avoids acting on a misread premise (lesson
+  2026-06-08-collab-premise-contradicting-interjection: "there is no pm2 this
+  replaces it" was read as "PM2 is abolished as the transport" and triggered a
+  3-option transport menu, when it meant "there was no dev *site* yet — push to
+  the unchanged PM2 path"; the wide menu over-committed to one interpretation and
+  cost a round).
+
+## Capture lessons (exit step)
+
+Before the final verdict line, follow `.rdc/guides/lessons-learned-spec.md` § Capture procedure. If this run taught something non-obvious — a first root-cause theory that turned out wrong, the documented/standard path not working, a missing gate or check that cost a round, or a surprising tool/infra behavior — write one `.rdc/lessons/<YYYY-MM-DD>-collab-<short-slug>.md` per lesson using the schema in that spec. Set `scope` (`simple` | `architectural`) and `status` (`open`, or `applied` if you shipped the fix in this same run, with the commit linked). Commit the lesson file(s) on `develop` alongside the run's other commits, and note "N lessons captured" in your verdict/summary. A run that taught nothing writes nothing — absence is the default.