/relationship-radar

/relationship-radar

Relationships decay quietly — the person you spoke to every week three months ago just… stopped coming up. This surfaces who is going cold while you can still do something about it, ranked by how long it's been.

Honest scope (read this): today the radar reads the signal that exists now — each person page's recorded last-interaction date, corroborated by meeting recency. It does not yet have the entity engine's automatic "temperature / what's cooling" surface — that isn't built. So the radar is only as good as the last-interaction dates on your person pages, and it says so plainly when the signal is thin rather than inventing a coldness score. When the entity temperature surface ships, this skill gets richer; it does not block on it.

Step 1 — Load the people signal

Call build_people_index (writes/refreshes System/People_Index.json) and read its people[]: each carries name, role, company, status, and last_interaction (a date, or empty). Drop anyone whose status marks them archived/inactive — the radar is about live relationships.

If the index is empty or absent, say so and point to the fix (add person pages, or set last-interaction dates) — do not present an empty radar as "all healthy."

Step 2 — Rank by staleness

For each remaining person with a last_interaction date, compute days since last contact (today − last_interaction) and bucket by these stated heuristics (not a hidden score):

• Going cold — ~30–60 days since contact. Was a real relationship; the gap is opening.
• Slipping — 60+ days. At risk of going dark.
• Warm — under ~30 days. Not shown unless asked; the radar is about what needs attention.

Weight toward people whose role/company signals they matter (a key customer, a manager, a close collaborator) — surface those first even at a shorter gap. Say why each surfaced ("was weekly in Q1, nothing for 7 weeks").

Step 3 — Handle the people you can't assess (degrade honestly)

People with no last-interaction date can't be ranked by it. Don't guess a coldness. Instead:

• Try to corroborate from meeting recency — scan recent meetings for their name/email and use the latest as an interaction proxy, saying that's what you did.
• If there's still no signal, list them under "Can't assess — no interaction date recorded" and offer to backfill (a last-interaction date on the page, or running process-meetings). Never silently drop them and never fake a date.

Step 4 — Present the radar

Show a short ranked list, most-stale-and-important first. Each row, by name: person (and role/company), last contact (date + "N days ago"), the bucket, and one line of why it matters. Refer to people by name, never by id or raw file path. If genuinely nobody is cold, say that plainly — a quiet radar is a real, good result, not a reason to pad the list.

Step 5 — Optional reconnect (confirm-gated, never automatic)

Offer — don't impose — to turn a surfaced person into a "reach out to {name}" task. Nothing is created without the user's per-item say-so. For each one they pick, call Work MCP create_task (infer the pillar per the CLAUDE.md rules; carry the person's name + last-contact into the task), then read back the created task IDs before reporting. If they just want to see the radar, stop after Step 4.