Operations: daily drivers
Operations: daily drivers/primeOperations 🔒
What it is. Session initializer: loads full workspace context, runs a parallel health block, surfaces priorities, and recommends the day's skills.
What it does. Reads the context files in order (personal, business, strategy, current data, people, pipeline, workspace index, datastore index), then runs seven read-only health checks in parallel via scripts/prime-health-parallel.py (CRM, knowledge, memory, email-intel state, threads archive-scan, Fireside daemon, Sync-Exchange daemon). If the Fireside or Sync-Exchange daemon is dead the health block spawns a detached one. It renders an Active Threads panel from MEMORY.md, flags sync files older than 48 hours as SYNC STALE, and defers the skill catalog to the router rather than duplicating it.
How to use it. Run once at the start of every working session. Mid-session, use /next for the logical next step, /dashboard for the morning briefing alone, or /state-check for function-by-function health.
/prime
(no arguments; slash-command only, cannot be triggered from natural language)Customize. Reads .workspace-identity.json to branch CEO versus exec paths (flat versus corporate/ + personal/); disable-model-invocation: true in frontmatter. On exec workspaces it prepends a setup-wizard completion line when completion_pct < 100.
/dashboardOperations
What it is. Generates the daily CEO Morning Dashboard: a single-page HTML and PDF briefing aggregating CRM health, pipeline, calendar, email, strategy, and data freshness.
What it does. Runs scripts/generate-dashboard.py --pdf, which reads all workspace data sources (CRM health via scripts/crm-health.py --json, pipeline, calendar and email sync files, strategy, metrics) and writes morning-dashboard.html plus .pdf. It then validates hidden characters with scripts/sanitize-text.py and reports urgent-item count, today's meetings, and a pipeline snapshot. An optional live sea-state enrichment runs a quick WebSearch when requested.
How to use it. Use for the morning operational briefing. For a full context load at session start use /prime; for the logical next action use /next; for the end-of-week review use /weekly-review.
/dashboard
"give me the morning brief"Customize. The --pdf flag on the backing script; branding is 31C corporate (GT Standard fonts and logos from datastore/brand/, with an explicit surfaced warning if they fail to embed rather than a silent Inter fallback). An R10 Capture Payoff panel auto-hides on any workspace with no Odin brain.
/next [area]Operations
What it is. State-aware "what's next" recommender: reads what just happened and names the logical next step plus the exact slash-command to run.
What it does. Runs scripts/next-signal.py --json to build a ranked recent-actions list from four sources (the session handoff pointer, newest outputs/ files, recent git log subjects, active business threads), then maps each action to its producing skill via scripts/skill_graph.py and looks up its follow-on edges. It emits 2 to 4 ranked one-line recommendations, or nothing when no edge is strong enough. Strictly read-only: it names the command but never invokes it, and it reads business threads only (personal threads stay out of the signal).
How to use it. Use at a mid-session lull or "where were we". Do NOT use for a full context load at session start (/prime), function-health diagnosis (/state-check), the daily briefing (/dashboard), or the end-of-week review (/weekly-review).
/next deals
"what should I do now?"Customize. Optional area argument (for example deals or content) to scope the recommendation. Both backing scripts run standalone from terminal or chat, no daemon or browser.
/radar [ack <key> | crunch on|off]Operations
What it is. Manual-actions and silent-health detector: surfaces which high-consequence manual actions are objectively overdue and which machine states have degraded. A detector, never an executor.
What it does. Runs scripts/ops-radar.py, which computes every signal, applies ack and crunch suppression, and prints a detailed due-items view (or "all clear"). Tier A machine states (ollama down, memory-index stale) self-heal on the timer; Tier B manual actions (backup, publish, weekly-review, cold-sweep, Odin collect/reflect) only nudge when objectively overdue, and for each due item the skill names the one command that clears it. It never sends, commits, publishes, or runs a manual action; a daily timer pushes the same counts-only line to Telegram.
How to use it. Use to see what is overdue or to ack/crunch. Do NOT use for a full morning brief (/dashboard or /prime), naming the single next action (/next), or function-by-function health (/state-check); the radar FEEDS those.
/radar ack backup --ttl 24h
"what am I forgetting to run?"Customize. ack <key> silences one signal until its TTL (--ttl 24h|7d) or until severity worsens; valid keys include backup, publish, weekly_review, cold_sweep, odin_cadence, ollama, memory_index. crunch on|off toggles the critical-floor-only posture.
/queue [list | show <id> | approve <id> | edit <id> | dismiss <id> | retry <id>]Operations
What it is. The terminal-native Action Queue: the one lane where proactive agents (cold-sweep, email-intel, viraid) deposit drafted actions for the CEO's go/no-go.
What it does. Drives scripts/action-queue.py entirely in-process, daemon-free and browser-free. list and show are read-only; edit rewrites a draft (flipping it to ready_for_review); dismiss suppresses re-proposal for 14 days; retry re-sends a failed card. Critically, approve SENDS the card synchronously in the same command and prints the outcome: this typed approve is the explicit human approval click that the lethal-trifecta and console-first rules require. It refuses any email_send card that does not resolve gated, and nothing is ever auto-sent.
How to use it. Use to clear the pending-draft backlog. Do NOT use to see what is overdue workspace-wide (/radar), to draft cold nudges (/cold-sweep), or for inbox triage (/email-intel); this is the approve/send surface those skills feed.
/queue approve a1b2
"show my drafts"Customize. One approve per explicit instruction ("approve the first one" means only the first). Edit takes --subject and --body-file; dismiss takes --reason. All mutations must go through scripts/action-queue.py, never queue.json directly.
/weekly-review [week date]Operations
What it is. The CEO weekly review: sea state, heading, pipeline movement, Tribe state, content cadence, top-3 priorities, and course corrections, with week-over-week continuity.
What it does. Phase 0 finds the most recent prior review and grades last week's priorities and course corrections against observable signals. Phase 1 loads context and pipeline files; Phase 2 analyzes deal movement (advances, stalls beyond 14 days, wins/losses, weighted value), content cadence against 3 posts and 1 newsletter per week, and context freshness. Phase 3 writes the 2-to-3-page review to outputs/operations/reviews/YYYY-MM-DD-weekly-review.md. On the CEO workspace it optionally surfaces ripe Odin reflection clusters, gated on explicit go-ahead.
How to use it. Use at the end of the week (Friday) or start of the next. For a single function's health use /state-check; for the daily briefing use /dashboard.
/weekly-review 2026-06-27
"friday review"Customize. Optional week-date argument sets the review week and output filename. Weighting bands (Discovery 10 percent through Closed-Won 100 percent) and cadence targets live in the skill body. The Odin reflection phase is a provable no-op on any workspace without an knowledge/odin-brain/ directory.
/dream [focus area]Operations 🔒
What it is. Reflective memory consolidation: a periodic pass that merges recent learnings into durable, well-organized memory files for future sessions.
What it does. Orients over existing memory files and MEMORY.md, gathers recent signal from git log and business/pipeline state, validates technical claims against Context7 (scripts/context7.py), and passes a mandatory security gate before any write. It then merges (never duplicates), converts relative dates to absolute, prunes superseded files, keeps MEMORY.md under its 200-line budget, and produces a consolidation report. It leaves sections marked <!-- managed-by: ... --> (like Active Threads) untouched.
How to use it. Use at the end of a productive session or for periodic memory hygiene. For a simple one-off memory write use the auto-memory system; for knowledge-base notes use /zk; for session-resume snapshots use /checkpoint. To only detect defects without mutating, use /memory-hygiene.
/dream deployment
"consolidate memories"Customize. Optional focus-area argument scopes targeted transcript investigation; disable-model-invocation: true in frontmatter. If either security rules file is missing the pass stops before Phase 2, incomplete but safe.
/memory-hygieneOperations
What it is. Objective-defect detector for the memory ecosystem (auto-memory plus Odin brain): flags only mechanically-verifiable rot, never mutating memory.
What it does. Runs scripts/memory-hygiene.py, which reads the auto-memory directory and runs odin-brain-health.py --compile, then writes a dated report and exits non-zero when objective defects are present. The gate covers dangling or circular superseded_by refs, orphan memory files not linked from MEMORY.md, and an over-budget MEMORY.md; advisory (non-gating) signals include stale files older than 45 days and Odin stale seeds. If the brain is unavailable the script degrades clearly and still reports the auto-memory half.
How to use it. Use to check whether memory has accumulated objective rot, on demand or weekly. Do NOT use to consolidate, merge, or reword (that is judgement, use /dream), to recall a fact (/recall), or for operational function health (/state-check).
/memory-hygiene
"scan memory for defects"Customize. No flags; detector only. Resolution is handed to /dream with the specific defects as a worklist.
/census <aggregating question> [--corpus SCOPE]Operations
What it is. Recursive Language Models (RLM, arXiv:2512.24601) applied to the workspace: a question whose answer requires visiting many files is answered by a traversal program rather than by retrieval, so the corpus never enters the context window.
What it does. Runs scripts/census.py, which mounts the named corpus scopes read-only inside a bubblewrap sandbox with no network and no secrets, executes a Python traversal program at recursion depth 1, and returns structured JSON of counts, paths or pairs with the sources that produced them. Free prose needs --free-text and comes back tagged provenance: untrusted. It refuses any scope naming an air-gapped path (exit 5, checked first) and a corpus that fits the context window (exit 4).
How to use it. Use when the answer sits in no single file and needs the whole set counted. Do NOT use to find something already recorded (/recall), to capture a note (/zk), for external intel (/osint), or for an exact string (Grep). Read the printed traversal program before approving it.
/census "how many active threads have not moved in 30 days" --corpus threads
"which pipeline rows have no CRM card"Customize. Scopes are named with repeated --corpus flags (threads, crm, context, auto_memory, knowledge, outputs); an unnamed scope is not mounted at all. --return-budget caps the characters allowed back into the caller's context. The eval/exec carve-out and its four compensating controls are governed by .claude/rules/generated-code-execution.md. CEO-only, never synced to executives.
/sentinel [start|stop|status|logs|config]Operations 🔒
What it is. Manages the Sentinel background daemon that monitors corporate email (Exchange) and Telegram for urgent messages and evaluates meeting invites against the CEO Calendar Policy.
What it does. Drives scripts/sentinel.py to start (foreground or --daemon), stop (--stop), check --status, run a single dry-run cycle (--test), or view logs (tail .sentinel/sentinel.log); the default action starts the daemon if not already running and shows status. The daemon scores email urgency via the Claude API, recommends CEO actions, and can auto-accept or auto-decline policy-compliant invites while escalating VIP/external senders to Telegram. Runtime state lives in .sentinel/state.json, .sentinel/sentinel.log, and .sentinel/sentinel.pid.
How to use it. Use to start, stop, or check the comms-monitoring daemon. For a one-off inbox triage use /email-intel; for ad-hoc Telegram use /telegram.
/sentinel status
"is the comms monitor running?"Customize. Config at <data-root>/config/sentinel_config.yaml (engine fallback scripts/sentinel_config.example.yaml): check_interval_minutes (default 15), urgency_threshold (default 7 on a 1-10 scale), vip_senders, monitored_chats, notification.dedup_cooldown_minutes, digest times, and calendar auto-accept/decline policy. Where alerts land is not in that file: they go out over the notifications bot to SENTINEL_TELEGRAM_TARGET (falling back to ODIN_CADENCE_TELEGRAM_TARGET) in .env. Prerequisites: ANTHROPIC_API_KEY, TELEGRAM_NOTIFY_BOT_TOKEN, an authenticated Telegram session, and Exchange credentials in .env. disable-model-invocation: true.
/bridge-health [--stale SECONDS] [--gate] [--json]Operations 🔒
What it is. Read-only rollup health check on the bridge daemon fleet: heartbeat staleness, version drift, config drift, active sessions, and the optional Phase 1 to Phase 2 adoption-gate verdict.
What it does. Wraps two scripts. First it runs the local liveness probe scripts/bridge-daemon.py --health (pretty-printing the /health JSON, falling back to on-disk heartbeat if the HTTP probe fails). Then it runs scripts/daemon-fleet-health.py for a per-workspace status grid (ok/stale/version-mismatch/config-drift/error/missing) with a rollup summary line. With --gate it curls the daemon's /telemetry/summary endpoint and labels the four adoption metrics PASS/BELOW. It ends with a one-line verdict and per-status remedies.
How to use it. Use when the dashboard feels stale, the sync-pill is amber or red, the daemon may have crashed, or before a /push-updates that changes daemon config. For a single-machine liveness probe run scripts/bridge-daemon.py --health directly.
/bridge-health --gate
/bridge-health --stale 60 --jsonCustomize. --stale SECONDS sets the staleness threshold (default 120); --gate adds the adoption-gate summary; --json emits machine-readable output. disable-model-invocation: true. Config edits go to corporate/daemon/config.yaml plus /push-updates, not here.
/cold-sweep [--dry-run]Operations
What it is. Drains overdue CRM "red debt" into the Action Queue as routed, voice-drafted nudges for one-click CEO approval. It only drafts; it never sends.
What it does. The deterministic routing (who, what priority) is done headless by scripts/cold_sweep_core.py, which reads crm-health.py --json and deposits email_send cards with draft_status: needs_draft (via the daemon schedule or a manual scripts/cold-sweep.py run). This skill fills each needs_draft card with a roughly 150-word nudge in Misha's voice, cites one real specific from the contact file, validates with sanitize-text.py and humanization-check.py, and flips the card to ready_for_review through scripts/action-queue.py edit. The CEO then approves and sends synchronously from the terminal with /queue approve <id>; this skill never sends.
How to use it. Use to drain the whole overdue-CRM backlog into ready drafts. For a single follow-up use /follow-up; for pipeline review use /crm.
/cold-sweep --dry-run
"drain the cold contacts"Customize. --dry-run previews the routed cards without drafting and stops. Routing thresholds live in cold_sweep_core; the daemon runs the sweep on a 06:30 local schedule when enabled. Never invents contacts or fabricates a hook to hit the word count.
/thread <command> [args]Operations
What it is. The operational threads registry: the running state of multi-step business and personal situations across sessions, distinct from CRM (people), pipeline (deals), and ZK (ideas).
What it does. Drives scripts/thread.py with subcommands: open, log (with --artifact, --decision, --follow-up, --done), close, hold, reopen, list, find, show, and archive-scan (used by /prime). It never opens or logs silently: before invoking the CLI it asks for approval. Personal threads are strictly protected: their content is never referenced in any output leaving the workspace, backed by a PreToolUse hook, .gitignore, classification, and a path filter.
How to use it. Use for a multi-step situation that follows through across sessions. For a single email use /email-draft; for a note use /zk; for a contact log use /crm. Code work and debugging are explicitly out of scope.
/thread log <thread-id> "sent reply" --follow-up "chase next week"
"open a thread for the vendor dispute"Customize. Thread type is business or personal at open; list filters on --type and --status; archive-scan --apply archives closed threads. The approval gate is always on (relaxation deferred to v2).