--- name: relations description: "OPS on-demand: This skill should be used when the user asks to \"who do I owe a reply\", \"relationship…" argument-hint: '[queue|brief |find |draft |close |audit]' allowed-tools: - Bash - Read - Grep - Glob - Skill - AskUserQuestion --- # /ops:relations — Relationship Manager Load `ops-rules` before acting. Public repo (no personal data). Outbound: one draft → one approval → one send. If `AskUserQuestion` / `Workflow` are missing, follow Rule 10 in `ops-rules` (Hermes: numbered options / two-turn Telegram card; `delegate_task`). Relationship ledger and decision queue. Answers: who is owed a reply, what was promised, what is going cold, and what context a draft needs before it is written. It never sends anything. ## Configuration Every path and toggle comes from plugin `userConfig`, an env var, or `$HOME`. Nothing in this skill is machine-specific. | userConfig key | Env override | Default | Meaning | | -------------------------- | ------------------------ | ------------------------------------ | ---------------------------------------------- | | `relations_cli` | `RELATIONS_CLI` | `$HOME/.claude-ops/relations/bin/relations-cli` | Ledger CLI entry point (JSON out) | | `relations_db_path` | `RELATIONS_DB` | `$HOME/.claude-ops/relations/people.db` | SQLite ledger, the factual source of truth | | `relations_shadow_mode` | `RELATIONS_SHADOW_MODE` | `true` | When true, no external send on any channel | | `relations_queue_limit` | `RELATIONS_QUEUE_LIMIT` | `10` | Max decision-queue items per report | | `relations_followup_limit_personal` | — | `1` | Unanswered follow-ups allowed, personal | | `relations_followup_limit_business` | — | `2` | Unanswered follow-ups allowed, business | | `relations_suppress_days` | — | `30` | Minimum suppression after a dismissal | Resolve in this order, first non-empty wins. Never hardcode an absolute path: ```bash PREFS_PATH="${PREFS_PATH:-${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json}" read_pref() { [ -f "$PREFS_PATH" ] && python3 -c 'import json,sys;print(json.load(open(sys.argv[1])).get(sys.argv[2],"") or "")' "$PREFS_PATH" "$1" 2>/dev/null; } RELATIONS_CLI="${RELATIONS_CLI:-$(read_pref relations_cli)}" RELATIONS_CLI="${RELATIONS_CLI:-$HOME/.claude-ops/relations/bin/relations-cli}" RELATIONS_DB="${RELATIONS_DB:-$(read_pref relations_db_path)}" RELATIONS_DB="${RELATIONS_DB:-$HOME/.claude-ops/relations/people.db}" if [ ! -x "$RELATIONS_CLI" ]; then echo "relations: no ledger CLI at $RELATIONS_CLI — set userConfig relations_cli or RELATIONS_CLI" >&2 fi ``` A missing CLI is reported as a missing CLI. Never fall back to an empty result: "no follow-ups" and "the ledger is not installed" must never look the same. ## Hard rules 1. **Shadow mode is the default.** With `relations_shadow_mode` true, this skill drafts and stages only. No email, chat, SMS, or calendar invite leaves the box. 2. **Never merge two records on a name.** Hard keys only: contact-provider id, normalized email, E.164 phone, or a previously verified alias. Everything else goes to the review queue. 3. **Every fact, commitment and follow-up carries a source reference.** No source, no row, no draft sentence. 4. **Facts and inference are separate.** An inference never justifies an outbound. 5. **Silence is the default.** Nothing meaningful changed means send nothing. 6. **Contact history never enters agent memory.** Person facts belong in the ledger DB, not in a memory plane or a committed file. See `ops-rules` Rule 0. 7. **Progressive disclosure.** Never load the contact list into context. Query the one person you need. ## Operations | Subcommand | What it does | | ------------------ | ------------------------------------------------------------------- | | `queue` (default) | Ranked decision queue, max `relations_queue_limit`, one per person | | `brief ` | Contact methods, open commitments, sourced facts, recent threads | | `find ` | Resolve an identity by email / phone / name; ambiguity → review | | `draft ` | Full-context draft, staged for approval, never sent | | `close ` | Close a follow-up with a reason | | `snooze ` | Defer with a reason | | `suppress ` | Dismiss for at least `relations_suppress_days` | | `audit` | Duplicates, unsourced rows, stale facts, integrity | ```bash "$RELATIONS_CLI" queue --limit "${RELATIONS_QUEUE_LIMIT:-10}" "$RELATIONS_CLI" brief "$RELATIONS_CLI" find --email user@example.com "$RELATIONS_CLI" close --reason "they replied on chat" ``` ## Draft order (fixed) 1. Resolve identity across every channel the person owns — never answer on one channel while the real conversation is on another. 2. Read the COMPLETE thread, not the latest message. Check **both directions** (sent and received) and **every account** the channel has. 3. Read messages from the recipient and anyone relevant on copy. 4. Check the calendar and open commitments. 5. Check `vip` tier first (see the `vip` skill) — a tier-1 person is drafted with more care and never batched into a digest. 6. Load `humanizer`, write ONE draft in the owner's voice, in the language the thread is already in. 7. Stage it for approval with recipient, channel, thread, and a content hash. If any of those change, ask again. Send only the exact approved content. Never send. Never produce several near-duplicate drafts. ## Follow-up gate States: `i_owe_them`, `they_owe_me`, `waiting_date`, `waiting_document`, `waiting_decision`, `going_cold`, `no_action`, suppressed. The gate blocks on: do-not-automate, archived person, snoozed, suppressed, not due yet, they responded elsewhere, upcoming meeting, unanswered limit (`relations_followup_limit_personal` / `_business`), missing source reference, cross-channel duplicate. Not every unanswered message is overdue. Was a response actually requested? Was something promised? Has that date arrived? Would silence be more natural? ## Report format Plain text, no decoration, recommendation first, max `relations_queue_limit` items, numbered actions per item. If nothing survives the gate, output nothing. ``` relationship desk — monday 1. business, a revised proposal was promised friday (email thread, ) recommendation: send the prepared draft, confidence high 1 approve 2 edit 3 snooze 2 days 4 close 5 show context ``` ## Source authority Current complete thread > verified identity > current calendar event > current conversation > signed document > this ledger > recent public primary source > search result > existing summary > draft. A draft is never a source of truth. On conflict: record it, prefer the newest authoritative primary source, surface it, and do not send until it is resolved. ## Related skills - `vip` — who is checked and answered first; always consulted before triage - `ops-inbox` — channel sweeps feed this ledger - `ops-comms` — the send path, gated by Rule 6 - `people` — contact directory sync (identity layer under this ledger) - `humanizer` — voice pass before any draft is staged - `ops-rules` — Rule 0 (public repo), Rule 6 (per-message approval)