signal-person

name

signal-person

description

Use when the user wants a deep read on one person they manage or work with — to prep for a 1:1, a performance conversation, or to refresh a teammate's signal cache. Triggers on phrases like "signal <name>", "what's going on with <name>", "prep me on <name>", "how is <name> doing", "refresh <name>'s signals", or "/signal-person <name>". Gathers Jira, GitHub PR, and Slack signals for the person, synthesizes a manager-level picture, and writes/enriches their signal cache at ~/.claude/signal-cache/{shortname}.json. The morning-startup skill reads and lightly refreshes the same cache during daily 1:1 prep; this skill is the deeper, on-demand analysis and the owner of the cache schema.

Signal Person

A companion to morning-startup. It builds a manager-level picture of one person and persists it to a per-person signal cache that morning-startup reuses for fast daily 1:1 prep. Run it ad hoc — before an important 1:1, a quarterly review, or whenever a person's cache feels stale.

The central question this skill answers is: "What does this person need from me, and what should I be paying attention to?"

---

Before You Start: Resolve the Person

The person registry lives in the morning-startup config (single source of truth): ~/.claude/skills/morning-startup/config.md → the 1:1 People — Signal Registry table.

Given the user's input (a name or a shortname):

• Match it against the registry to resolve: shortname, display name, Slack username, GitHub handle (optional), and work email if present.
• If the person is not in the registry: proceed using whatever identifiers you can infer (name → Slack/Jira lookup), but tell the user they aren't registered and offer to add a row to the registry so future caching is automatic. Without a shortname you cannot key a cache file — ask the user for one before writing.

If config.md is missing, tell the user to set up morning-startup first (it owns the registry), then stop.

---

Step 1: Gather Signals (Run in Parallel)

Gather all sources simultaneously. The user is a manager — read everything at the leadership level, not the IC level.

1a. Jira

Resolve the person's account ID with mcp__claude_ai_Atlassian__lookupJiraAccountId (by display name), then use mcp__claude_ai_Atlassian__searchJiraIssuesUsingJql with the cloud ID from morning-startup config. JQL: assignee = "[accountId]" AND statusCategory != Done ORDER BY updated DESC

For each active issue capture: key, summary, status, priority, days since last update. Flag stuck = no update in 7+ business days, or status is Blocked.

1b. GitHub PRs (optional — needs a GitHub handle and the gh CLI)

If a handle is known and gh is available:

• Open PRs authored by them: gh search prs --author <handle> --state open
• Merged in the last 7 days: gh search prs --author <handle> --merged --created '>=[7d ago]' Capture: open PR list (repo, number, title, age, draft?) and pr_volume_7d (merged+open count). If unavailable, skip silently and leave PR fields unchanged from any prior cache.

1c. Slack

mcp__claude_ai_Slack__slack_search_public_and_private query from:[slack-username] after:[7 days ago]. Look for: blockers raised, decisions made, unresolved threads, sentiment. Summarize at the manager level — skip routine status chatter.

---

Step 2: Synthesize

Produce a short manager-level read:

• What they need from me: the single most useful thing the user can give this person right now — a decision, an unblock, air cover, recognition, a course-correction.
• Watch: patterns worth attention — e.g. Jira going stale while PRs keep merging (tracking hygiene), a blocker that's been raised twice, a drop in activity.
• One question: a specific question to ask in the next 1:1, grounded in the signals.

Never generic. Every line cites a ticket, PR, or thread.

---

Step 3: Write the Cache

Create ~/.claude/signal-cache/ if it doesn't exist. Write ~/.claude/signal-cache/{shortname}.json.

Merge, don't clobber. If a cache already exists, preserve durable fields (known_context, and what_they_need unless your analysis updates it). Overwrite the freshly-gathered signal fields. Set last_updated to now (ISO 8601) and last_updated_by to "signal-person".

Canonical cache schema

This skill owns the schema. morning-startup reads it and lightly refreshes the signal fields during daily 1:1 prep (writing last_updated_by: "morning-startup"), but preserves the durable fields below.

{
  "shortname": "jordan",
  "display_name": "Jordan Smith",
  "slack_username": "jordan",
  "github_handle": "jsmith",
  "work_email": "[e-mail]",

  "last_updated": "2026-06-01T08:30:00-04:00",
  "last_updated_by": "signal-person",

  "jira_active": [
    {
      "key": "INFR-123",
      "summary": "Migrate datastore to new cluster",
      "status": "In Progress",
      "priority": "High",
      "days_since_update": 10,
      "stuck": true
    }
  ],
  "prs_open": [
    { "repo": "persona/infra", "number": 42, "title": "Bump node pool", "age_days": 3, "draft": false }
  ],
  "pr_volume_7d": 9,
  "recent_context": "Merged 9 PRs last week; INFR-123 stale 10 bd despite active PRs.",

  "known_context": "Leads the compute migration. Prefers async written updates.",
  "what_they_need": "A decision on the migration cutover date."
}

Durable fields (manager-maintained, preserved across refreshes): known_context, what_they_need. Signal fields (refreshed on every run): jira_active, prs_open, pr_volume_7d, recent_context, last_updated*.

---

Step 4: Report

Print a concise summary to the user:

## Signal: [Display Name] ({shortname})

**What they need from you:** [one specific thing]

**Stuck / open:**
- [KEY-123] [summary] — stuck [N] bd
- (or "no stuck tickets")

**Activity:** [N] PRs merged last week · [N] open PRs · [Slack one-liner]

**One question for your next 1:1:** [grounded question]

**Watch:** [optional pattern]

_Cache updated → ~/.claude/signal-cache/{shortname}.json_

---

Notes

• This skill and morning-startup share one cache. Running either keeps it current; this one goes deeper and is the schema authority.
• Keep ~/.claude/signal-cache/ out of any synced/committed location — it contains per-person work signals. It lives under ~/.claude/, which is runtime state.
• Add new people to the registry in morning-startup/config.md so their caches are keyed consistently and picked up automatically in daily 1:1 prep.