@cohortapp/agent-sdk 2.3.0

package/plugins/maestro-skills/skills/org-recall.md

@@ -0,0 +1,81 @@
+---
+name: org-recall
+description: Consult the shared org knowledge plane — facts, contacts, and meetings other agents have recorded, ACL-scoped to what you may see. Use to pull org-wide context into your work before answering, or to record a fact for the rest of the fleet.
+---
+
+# Org Recall
+
+The org knowledge plane is the fleet's shared, ACL'd memory. Where session-search and
+collective recall give you a memory of *your own* work, this gives you a window into
+what the *org* knows: a fact agent A records is retrievable by agent B inside the ACL,
+invisible outside it. It is the org-wide RAG source to consult when building context
+before you answer — alongside, not instead of, your local recall.
+
+Backed by `lib/org/knowledge.mjs` over the Cohort knowledge plane. **Fail-open**: if
+the org is off or unreachable, `recall` returns `[]` and `remember` is a no-op — never
+a throw.
+
+## The server owns the ACL — always
+
+This is load-bearing: the client **never** filters and never decides what you may see.
+The server applies a non-bypassable floor (org/unit group membership, `barrier:<cell>`
+deny-override, participant-derived ACLs) derived from your **verified** identity, and
+returns only what you may read. Whatever comes back is, by construction, in-scope. The
+`group` argument is a scoping *hint* that can only shrink results, never widen them.
+Every `recall` is an **audited read** server-side — so consult it deliberately (one
+query per context build), not in a tight loop.
+
+## When to use
+
+- Before answering something that other agents likely have context on — pull the shared
+  facts first.
+- To record a durable fact the rest of the fleet should be able to find later.
+- To look up an org contact or a recorded meeting.
+
+## Recall (the org-RAG read)
+
+```bash
+node --input-type=module -e '
+import { recall } from "./lib/org/knowledge.mjs";
+import { loadConfig } from "./lib/collective/config.mjs";
+const cfg = await loadConfig(process.cwd());
+const facts = await recall("DFSA licensing timeline", { cfg, limit: 8 });
+console.log(JSON.stringify(facts, null, 2));   // [] if org off / nothing visible
+'
+```
+
+Use `recallDetailed` instead of `recall` when you want the provenance envelope
+(`returnedIds`, `groupsConsidered`) to show where an answer came from — e.g. "from
+facts X,Y across groups org, unit:eng" — without a second call.
+
+## Remember (record a shared fact)
+
+```bash
+node --input-type=module -e '
+import { remember } from "./lib/org/knowledge.mjs";
+import { loadConfig } from "./lib/collective/config.mjs";
+const cfg = await loadConfig(process.cwd());
+const res = await remember("Board approved the Q3 hiring plan on 2026-06-10", { cfg });
+console.log(JSON.stringify(res));   // {ok:true,...} | {ok:false,skipped:true} if org off
+'
+```
+
+Most updates should **append** (provenance-preserving) — that is the default. Pass
+`{ id, expectedVersion }` for a CAS replace of an existing fact, or use `forget(id,
+{ reason })` to tombstone one (it is never hard-deleted). `rewrite` is
+designated-owner-only — reserved for asserting authorship, not routine edits.
+
+## Contacts and meetings
+
+The same module exposes the shared contact and meeting books:
+`upsertContact` / `listContacts` and `recordMeeting` / `listMeetings`. Use these so
+"who is X" and "did we meet Y" resolve against the org's shared record, not just your
+local notes.
+
+## Notes
+
+- Run from the agent repo root so `config/collective.yaml` resolves.
+- This is the *org* plane. For your own past sessions use `session-search`; for this
+  machine's cross-session cards use collective recall. They complement each other.
+- Recording a fact makes it visible to everyone in the ACL — keep it factual and
+  attributable, never a raw transcript.

package/plugins/maestro-skills/skills/pipeline-review.md

@@ -0,0 +1,76 @@
+---
+name: pipeline-review
+description: Review the rollup acquisition pipeline — target status, due diligence progress, new targets, regulatory filing status. Use for pipeline check-ins and board reporting.
+---
+
+# Acquisition Pipeline Review
+
+You are {{agent.fullName}}, {{agent.title}}. Produce a comprehensive review of the rollup acquisition pipeline.
+
+## Data Sources
+
+1. **Pipeline tracker** — Read `memory/workstreams/acquisitions.md` for the current state of all targets.
+2. **Due diligence files** — Check `memory/workstreams/acquisitions/dd/` for in-progress DD on active targets.
+3. **Regulatory status** — Read `memory/workstreams/regulatory.md` for any regulatory dependencies on acquisitions.
+4. **Financial models** — Check `inputs/finance/` for valuation models and deal terms.
+5. **Strategic criteria** — Read `config/acquisition-criteria.md` for target screening parameters.
+6. **Recent communications** — Check `outputs/comms/` for any correspondence with targets, advisors, or regulators.
+
+## Review Process
+
+1. **Update each target's status** — Verify the pipeline stage is current:
+   - Identified -> Researching -> Initial Contact -> NDA Signed -> DD In Progress -> LOI -> Negotiation -> Signed -> Closing -> Closed
+2. **Flag stalled targets** — Any target that hasn't moved stages in 2+ weeks gets flagged.
+3. **Check DD completions** — For targets in DD, assess what's done and what's outstanding.
+4. **Assess pipeline health** — Is there enough top-of-funnel? Are too many targets stuck in one stage?
+5. **Regulatory cross-check** — Ensure acquisition timeline aligns with licensing and regulatory timelines per jurisdiction.
+
+## Output Format
+
+```
+# Acquisition Pipeline Review — [DATE]
+
+## Pipeline Summary
+- **Total targets**: [n]
+- **Active (in DD or beyond)**: [n]
+- **Closed this quarter**: [n]
+- **Pipeline value**: [estimated total]
+
+## Active Targets
+
+### [Target Name] — [Stage]
+- **Jurisdiction**: [country/region]
+- **Status**: [current situation in 1-2 sentences]
+- **DD Progress**: [% complete, key outstanding items]
+- **Timeline**: [expected close date]
+- **Blockers**: [if any]
+- **Next action**: [specific next step with owner]
+
+[Repeat for each active target]
+
+## Pipeline Health
+| Stage | Count | Avg Time in Stage | Flagged |
+|---|---|---|---|
+| Identified | [n] | [days] | [any flags] |
+| DD In Progress | [n] | [days] | [any flags] |
+| Negotiation | [n] | [days] | [any flags] |
+| Closing | [n] | [days] | [any flags] |
+
+## Stalled / At Risk
+- **[Target]**: Stalled at [stage] for [n] days — [diagnosis and recommendation]
+
+## New Targets to Evaluate
+- [Any newly identified targets with brief rationale]
+
+## Regulatory Dependencies
+- [Any regulatory milestones that gate acquisitions]
+
+## {{agent.firstName}}'s Assessment
+[Overall pipeline health, velocity concerns, recommendations for acceleration or pruning]
+```
+
+## Output
+
+1. Write to `outputs/pipeline/pipeline-review-YYYY-MM-DD.md`.
+2. Update `memory/workstreams/acquisitions.md` with any status changes.
+3. Present summary in conversation.

package/plugins/maestro-skills/skills/regulatory-status.md

@@ -0,0 +1,81 @@
+---
+name: regulatory-status
+description: Check regulatory status across all 7 jurisdictions — the regulator gap progress, incorporation status, licensing timelines. Use for regulatory check-ins and compliance tracking.
+---
+
+# Regulatory Status Check
+
+You are {{agent.fullName}}, {{agent.title}}. Produce a comprehensive regulatory status report across all jurisdictions.
+
+## Data Sources
+
+1. **Regulatory tracker** — Read `memory/workstreams/regulatory.md` for the master status of all jurisdictions.
+2. **the regulator gap analysis** — Check `memory/workstreams/regulatory/dfsa/` for Dubai Financial Services Authority progress.
+3. **Incorporation files** — Check `memory/workstreams/regulatory/incorporations/` for entity setup status per jurisdiction.
+4. **Licensing applications** — Check `memory/workstreams/regulatory/licensing/` for active applications and correspondence.
+5. **Legal counsel updates** — Check `inputs/legal/` for any new advice or regulatory correspondence.
+6. **Compliance calendar** — Read `config/regulatory-calendar.md` for upcoming deadlines and filing dates.
+
+## Jurisdictions
+
+Track status across all 7 jurisdictions:
+
+1. **DIFC (Dubai)** — the regulator licensing, gap analysis, remediation
+2. **Abu Dhabi (ADGM)** — FSRA licensing, entity setup
+3. **Saudi Arabia** — CMA licensing, local partner requirements
+4. **Bahrain** — CBB licensing framework
+5. **Qatar (QFC)** — QFCRA requirements
+6. **UK** — FCA authorization (if applicable)
+7. **Cayman Islands** — CIMA registration
+
+## Report Structure
+
+```
+# Regulatory Status Report — [DATE]
+
+## Summary Dashboard
+| Jurisdiction | Entity | Incorporation | License App | License Status | Next Deadline |
+|---|---|---|---|---|---|
+| DIFC | [entity name] | [done/pending] | [submitted/drafting/na] | [approved/pending/gap] | [date + item] |
+| ADGM | ... | ... | ... | ... | ... |
+[all 7 jurisdictions]
+
+## the regulator Gap Analysis Progress
+- **Total gaps identified**: [n]
+- **Remediated**: [n] ([%])
+- **In progress**: [n]
+- **Outstanding**: [n]
+- **Critical gaps**: [list any blocking items]
+
+## Jurisdiction Details
+
+### [Jurisdiction Name]
+- **Status**: [1-2 sentence current situation]
+- **Recent progress**: [what moved since last check]
+- **Blockers**: [if any]
+- **Next steps**: [specific actions with owners and dates]
+- **Cost to date**: [fees, legal costs if tracked]
+
+[Repeat for each jurisdiction]
+
+## Upcoming Deadlines (Next 30 Days)
+| Date | Jurisdiction | Item | Owner | Status |
+|---|---|---|---|---|
+| [date] | [jurisdiction] | [filing/meeting/deadline] | [who] | [on track/at risk] |
+
+## Cross-Jurisdiction Dependencies
+- [Any items where one jurisdiction's progress depends on another]
+
+## Regulatory Risks
+- [Identified risks with likelihood and impact assessment]
+
+## {{agent.firstName}}'s Assessment
+[Overall regulatory program health, velocity, and recommendations for acceleration]
+```
+
+## Output
+
+1. Write to `outputs/regulatory/regulatory-status-YYYY-MM-DD.md`.
+2. Update `memory/workstreams/regulatory.md` with any new information.
+3. Flag any deadlines within 14 days as urgent in the conversation.
+4. Present summary in conversation.

package/plugins/maestro-skills/skills/router-why.md

@@ -0,0 +1,78 @@
+---
+name: router-why
+description: Explain a model-routing decision — which model on which harness the router would pick for a task, and why. Use when a spawn used an unexpected model, when validating a routing-config change, or to understand the cost/fallback of a task class.
+---
+
+# Router Why
+
+The LLM router decides which model on which harness runs each spawn — cheap/local
+models for cheap work, Anthropic for the rest, and an Anthropic safety net whenever
+config is missing or a provider is down. When that decision is surprising, this skill
+makes it explainable. It is a **read-only** simulation: it resolves the chain for a
+request without spawning anything.
+
+Backed by `maestro router why` (which calls `lib/model-router/resolve.mjs#resolveChain`
+with your real `config/model-routing.yaml` and catalog).
+
+## When to use
+
+- A spawn used a model you didn't expect — find out which rule matched.
+- You changed `config/model-routing.yaml` and want to confirm the new routing.
+- You need the estimated cost or the fallback chain for a given task class.
+- A model is being skipped — check whether its breaker is open or its credential is missing.
+
+## Explain a decision
+
+By task class (the common case):
+
+```bash
+maestro router why classify
+maestro router why deep_reasoning
+```
+
+By a full request object (when data class, harness hint, or budget band matters):
+
+```bash
+maestro router why '{"task_class":"summarize","data_class":"internal","lane":"batch"}'
+```
+
+The output is the resolved `RouteDecision`: the **chosen** model (provider / model /
+harness / transport), the ordered **chain** it would fall through, the `tried` entries
+with skip reasons (breaker open, credential missing, data-class disallowed), the
+estimated cost, the resolved `lane`, and the mandatory one-line `explain` string plus
+the `audit` block (which rule matched, fallback reason, config source, overlay
+version).
+
+## Validate config before debugging
+
+If the decision looks wrong, first confirm the config is valid:
+
+```bash
+maestro router validate
+```
+
+This lints `config/model-routing.yaml` against the catalog and env — unknown refs,
+missing credentials, malformed rules. A warning here often explains a surprising route.
+
+## Reading the result
+
+- **Which rule matched** — `audit.rule` (the `match` block, a named rule, or
+  `<default>`). First-match wins, top to bottom.
+- **Why a model was skipped** — each `tried` entry carries a `reason`: `breaker_open`
+  (provider tripped — see `health.mjs` cooldowns), `missing_credential` (no
+  local key and no org lease available — see the `org-credential` skill),
+  `data_class_disallowed` (the backend isn't allowed that data class).
+- **Budget pressure** — when daily spend crosses a band (75/90/100%), the budget
+  ladder degrades the chain to cheaper rungs; the chosen model may be lower-grade than
+  the rule's first choice. That is expected under load, not a fault.
+- **Anthropic safety net** — if `chosen` is Anthropic and the explain says
+  `no_v2_config` / `kill_switch`, the router collapsed to the safe default; routing is
+  effectively off.
+
+## Notes
+
+- Run from the agent repo root so the config and catalog resolve.
+- This never spawns or spends — it only simulates the decision.
+- To change routing, edit `config/model-routing.yaml` (a `routing_policy` rule or an
+  alias), re-run `maestro router validate`, then re-check with `maestro router why`.
+  Full reference: `docs/guides/model-routing.md`.

package/plugins/maestro-skills/skills/schedule-meeting.md

@@ -0,0 +1,91 @@
+---
+name: schedule-meeting
+description: Schedule a meeting using Google Calendar MCP or Calendly. Handle timezone conversion, find availability, and send invites.
+---
+
+# Schedule Meeting
+
+You are {{agent.fullName}}, {{agent.title}}. Schedule meetings efficiently with proper timezone handling and availability checks.
+
+## Required Inputs
+
+When invoked, gather from the user (or infer from context):
+
+- **Participants**: Who needs to attend? (names or email addresses)
+- **Purpose**: What is the meeting about? (used for title and agenda)
+- **Duration**: How long? (default: 30 minutes)
+- **Urgency**: When does this need to happen? (today, this week, flexible)
+- **Preferred times**: Any constraints from {{agent.principal.firstName}} or participants?
+
+## Process
+
+### 1. Resolve Participants
+
+- Check `config/contacts.md` for participant email addresses, timezones, and scheduling preferences.
+- Note any known scheduling constraints (e.g., "never before 10am", "Fridays off").
+
+### 2. Check Availability
+
+- Use Google Calendar MCP (`mcp__google_calendar`) to check {{agent.principal.firstName}}'s calendar for open slots.
+- If participant calendars are accessible, cross-reference availability.
+- If not, propose 2-3 options for the organizer to share.
+
+### 3. Timezone Handling
+
+- Default CEO timezone: Read from `config/settings.md` (typically Gulf Standard Time, UTC+4).
+- Convert all proposed times to each participant's local timezone.
+- Always display times in both the CEO's timezone and the participant's timezone.
+- Use format: "2:00 PM GST / 10:00 AM GMT / 6:00 AM EST"
+
+### 4. Create the Event
+
+Using Google Calendar MCP (when available):
+
+- **Title**: Clear, specific (not just "Meeting" or "Call")
+- **Description**: Include agenda, context, any prep materials needed
+- **Duration**: As specified
+- **Attendees**: All participants
+- **Reminders**: 15 minutes before (default)
+- **Video link**: Add Google Meet or Zoom as appropriate
+
+### 5. Send Invites
+
+- Calendar invite goes via Google Calendar.
+- For important external meetings, also draft a courtesy email: "Looking forward to our call on [date]..."
+
+## Output Format
+
+```
+# Meeting Scheduled
+
+**Title**: [Meeting title]
+**Date**: [Day, Date]
+**Time**: [Time with all relevant timezones]
+**Duration**: [Duration]
+**Participants**: [List with emails]
+**Location**: [Video link or physical location]
+**Agenda**:
+1. [Item]
+2. [Item]
+
+**Calendar event created**: [Yes/No — pending MCP availability]
+**Invite sent to**: [list]
+
+**Pre-meeting prep needed**:
+- [Any documents to prepare or review before the meeting]
+```
+
+## Output
+
+1. Create calendar event via MCP if available.
+2. Log to `outputs/calendar/meetings-scheduled.md` for tracking.
+3. If meeting relates to an open loop, update `memory/executive/open-loops.md`.
+4. Present confirmation in conversation.
+
+## Scheduling Principles
+
+- Protect deep work blocks — avoid scheduling over focus time if marked on calendar.
+- Batch meetings when possible — avoid isolated 30-min calls breaking up the day.
+- Buffer time — leave 15 minutes between back-to-back meetings.
+- Morning preference for high-stakes meetings (investor, board, key partner).
+- Friday afternoons: avoid scheduling unless urgent.

package/plugins/maestro-skills/skills/session-search.md

@@ -0,0 +1,71 @@
+---
+name: session-search
+description: Recall your own past Claude Code sessions verbatim — full-text search across every prior session transcript, with four modes (discovery, scroll, read, browse). Use when you need the exact wording, the precise steps, or the full context of something you did before, beyond the budgeted memory digest.
+---
+
+# Session Search
+
+Verbatim recall of your own past sessions. The SessionStart memory digest gives
+you a small, budgeted gist; this gives you the full transcript on demand. Backed
+by a local FTS5 index over `logs/sessions/*.jsonl` at `state/learning/sessions.db`.
+
+It shells `scripts/learning/session-search.mjs`. Run it from the agent repo root
+(so `AGENT_ROOT` resolves). If the index looks empty, ingest first.
+
+## When to use
+
+- You remember solving something but not exactly how — find and re-read it.
+- A user references "what you said last week" and you need the precise wording.
+- You want to reuse the concrete steps of a past procedure verbatim.
+- Prefer this over re-deriving an approach you have clearly done before.
+
+## Modes
+
+### discovery (default) — FIND a session
+Ranked full-text hits across all sessions. Each matched session shows a
+**bookend** (its first and last turn, for orientation) plus the matching turns
+with snippets.
+
+```bash
+node scripts/learning/session-search.mjs "duplicate charge reconciliation"
+```
+
+### scroll — read AROUND a hit
+A window of turns either side of a specific turn (from a discovery result).
+
+```bash
+node scripts/learning/session-search.mjs --mode=scroll --session=<session_id> --seq=42 --window=6
+```
+
+### read — the FULL session
+Every turn of one session, in order.
+
+```bash
+node scripts/learning/session-search.mjs --mode=read --session=<session_id>
+```
+
+### browse — recent sessions
+The most-recent sessions (metadata only), newest first.
+
+```bash
+node scripts/learning/session-search.mjs --mode=browse --top=20
+```
+
+### ingest — (re)build the index
+Idempotent; safe to run anytime. The Stop-hook worker and a daily catch-up keep
+it warm automatically, so you rarely need this by hand.
+
+```bash
+node scripts/learning/session-search.mjs ingest
+```
+
+## Output
+
+Add `--json` to any command for machine-readable output (useful when chaining a
+discovery hit into a scroll/read call).
+
+## Notes
+
+- Read-only and fail-open: a missing index returns empty results, never an error.
+- This indexes YOUR sessions only — it is not a replacement for `rag_search`
+  (the knowledge/decisions corpus) or `collective recall` (cross-session cards).

package/plugins/maestro-skills/skills/set-reminder.md

@@ -0,0 +1,93 @@
+---
+name: set-reminder
+description: Create a dynamic scheduled job in natural language — "remind me Friday 9am", "every weekday 8am summarize the channel". Use to set a one-off reminder or a recurring task with a payload, list what is scheduled, or cancel a job.
+---
+
+# Set Reminder (dynamic jobs)
+
+The everyday-employee scheduling primitive: turn "remind X this Friday at 9am" or
+"every weekday at 8am summarize the channel" into a real job the daemon fires. This is
+distinct from the framework's fixed cadences (morning brief, inbox sweep) — those are
+built in; this is for the ad-hoc jobs you create on demand.
+
+Backed by `lib/scheduling/dynamic-jobs.mjs` over an atomic
+`state/scheduling/jobs.json`. The daemon's `dynamic-jobs` cadence checks `dueJobs()`
+on its timer and delivers each job's payload — you just create the job; firing is
+automatic. Pure, fail-open, and crash-safe (a corrupt store reads as empty; a missed
+window catches up once rather than replaying a burst).
+
+## When to use
+
+- "Remind me / remind <person> at <time>" — a one-off nudge.
+- "Every <weekday/day> at <time>, do <recurring task>" — a recurring job with a payload.
+- Listing what you have scheduled, or cancelling a job you no longer need.
+
+## Parse the "when" first
+
+`parseWhen(text, { tz })` turns a phrase into either `{ at }` (one-off) or `{ cron }`
+(recurring). Pass the principal's timezone so "9am" lands on the right wall clock
+(read it from `config/settings.md` / agent config; defaults to UTC).
+
+It recognises: `in 2 hours` / `in 30 minutes`, `tomorrow 9am`, `today 5pm`, a bare
+time (`9am` → next occurrence), `friday 9am` / `next friday 9am`, and recurring forms
+`every weekday at 8am` (cron `0 8 * * 1-5`), `every day at 7am`, `every monday 9am`,
+`every weekend …`. If nothing schedule-like is found it returns `null` — ask the user
+to rephrase rather than guessing.
+
+## Creating a job
+
+```bash
+node --input-type=module -e '
+import { parseWhen, createJob } from "./lib/scheduling/dynamic-jobs.mjs";
+const tz = "Asia/Dubai";                       // the principal timezone
+const when = parseWhen("every weekday at 8am", { tz });
+if (!when) { console.error("could not parse the time — ask to rephrase"); process.exit(2); }
+const job = createJob({
+  agentRoot: process.cwd(),
+  when,                                         // {at,tz} or {cron,tz} from parseWhen
+  action: "channel-summary",                    // REQUIRED: what the trigger should do
+  payload: { channel: "#engineering", text: "Summarize overnight activity" },
+});
+console.log(JSON.stringify(job, null, 2));
+'
+```
+
+`createJob` requires `when` (the `parseWhen` descriptor) and `action` (a string the
+firing trigger dispatches on); `payload` is the free-form arguments that action needs —
+a reminder text, a task description, a channel id. Keep the payload small and
+self-describing; the daemon hands it straight to `schedules/triggers/dynamic-jobs.md`
+when the job fires. `ttlMs` overrides the default one-off staleness window.
+
+## Listing and cancelling
+
+```bash
+# list
+node --input-type=module -e '
+import { listJobs } from "./lib/scheduling/dynamic-jobs.mjs";
+console.log(JSON.stringify(listJobs(process.cwd()), null, 2));
+'
+
+# cancel by id
+node --input-type=module -e '
+import { cancelJob } from "./lib/scheduling/dynamic-jobs.mjs";
+console.log(JSON.stringify(cancelJob(process.cwd(), "JOB_ID")));
+'
+```
+
+## Behaviour to know
+
+- **One-off TTL.** A one-off whose window was missed by more than ~6h (e.g. the box was
+  down) is skipped and cancelled rather than fired late — a "9am reminder" never
+  surfaces at 6pm.
+- **Recurring catch-up.** A recurring job that missed several windows fires **once** on
+  the next check and re-targets the next window — it does not replay the backlog.
+- **Crash-safe.** Writes are atomic; an unreadable store reads as empty rather than
+  wedging every job.
+
+## Notes
+
+- Run from the agent repo root so `state/scheduling/` resolves.
+- This creates the job only; the daemon does the firing. If the daemon is down, jobs
+  simply fire (or catch up) when it comes back.
+- When the reminder is a user-facing message, write it in the house voice
+  (`policies/communication-style.md`) — plain, no filler, no emoji.

package/plugins/maestro-skills/skills/slack-followup.md

@@ -0,0 +1,64 @@
+---
+name: slack-followup
+description: Check all pending Slack follow-ups — messages awaiting reply, commitments overdue, threads needing continuation. Use Slack MCP when available.
+---
+
+# Slack Follow-Up Tracker
+
+You are {{agent.fullName}}, {{agent.title}}. Track and surface all pending Slack follow-ups.
+
+## Data Sources
+
+1. **Slack MCP** — Use `mcp__slack` to query channels and DMs for:
+   - Messages from {{agent.principal.firstName}} that received no reply
+   - Messages to {{agent.principal.firstName}} awaiting his reply
+   - Threads where the principal was mentioned but hasn't responded
+   - Commitments made in Slack ("I'll send that by...", "Let me follow up on...")
+2. **If Slack MCP unavailable** — Check `inputs/slack/` for exported conversations.
+3. **Follow-up log** — Read `memory/comms/slack-followups.md` for previously tracked items.
+4. **Contacts** — Reference `config/contacts.md` to understand relationship priority.
+
+## Processing Rules
+
+1. **Scan channels** — Check all active workspace channels for threads involving the CEO or key stakeholders.
+2. **Identify commitments** — Look for language indicating promises or deadlines:
+   - "I'll...", "Will do...", "By [date]...", "Let me get back to you..."
+   - "Can you send...", "Please follow up...", "Waiting on..."
+3. **Calculate overdue status** — Compare commitment dates against today's date.
+4. **Prioritize by relationship** — Investor, board member, and partner follow-ups rank higher.
+
+## Output Format
+
+```
+# Slack Follow-Up Report — [DATE]
+
+## Overdue (Action Required)
+| Thread | Commitment | Due | Days Late | Owner |
+|---|---|---|---|---|
+| [#channel or DM] | [what was promised] | [date] | [n] | [who owes] |
+
+## Due Today
+| Thread | Commitment | Owner |
+|---|---|---|
+| [context] | [what's due] | [who] |
+
+## Awaiting Replies (From Others)
+- **[Person]** in [#channel]: [topic] — sent [date], no reply yet ([n] days)
+
+## Threads Needing Continuation
+- [#channel]: [topic] — last message [date], appears unresolved
+
+## Recommended Actions
+1. [Specific action {{agent.firstName}} recommends, e.g., "Nudge X about Y"]
+2. [Draft nudge message if appropriate]
+```
+
+## Output
+
+1. Write report to `outputs/followups/slack-followup-YYYY-MM-DD.md`.
+2. Update `memory/comms/slack-followups.md` with current state.
+3. Present summary in conversation with recommended actions.
+
+## Tone
+
+Be specific about what's owed and to whom. Don't let things slip quietly — surface them clearly so they can be addressed or consciously deprioritized.