---
name: shift-handoff-summary
description: >
  Compile everything triaged, investigated, or still open during a SOC shift into a single
  handoff summary for the next analyst. Use this skill whenever a user asks to "summarize the
  shift", "write a handoff", "what happened today", "prep the handoff notes", or asks for a
  rollup of incidents/tickets/triage decisions from a given time window at end of shift. Also
  trigger when a user pastes a list of ticket numbers, alert IDs, or case summaries and asks for
  them consolidated into one handoff document. Do not use for a single-incident report — that's
  a triage or investigation skill; this one is specifically for the end-of-shift rollup across
  multiple items.
---

# Shift Handoff Summary Skill

Turns a scattered set of tickets, triage verdicts, and open questions from a shift into one
handoff document the next analyst can actually use without re-reading every ticket.

---

## Workflow Overview

```
1. Collect the shift's items  →  2. Pull current status per item  →  3. Classify by urgency
   →  4. Flag anything unresolved or ambiguous  →  5. Render handoff document
```

---

## Step 1 — Collect the Shift's Items

Sources for "what happened this shift," in order of preference:

- Items the user pastes directly (ticket IDs, alert summaries, IOC lists)
- `jira` — search issues created/updated in the shift window (ask the user for the time range
  if not given; don't assume a default shift length)
- Prior triage reports generated earlier in the same conversation/session

If nothing is pasted and no Jira connector is available, ask the user to paste the ticket/alert
list rather than guessing at scope.

---

## Step 2 — Pull Current Status Per Item

For each item, use `Atlassian:getJiraIssue` (or the user-pasted status) to get current state:
status, priority, assignee, last update, and any comments logged during the shift.
For items that went through a Polarity triage earlier, reuse that verdict rather than
re-running enrichment — a handoff is a rollup, not a re-investigation.

---

## Step 3 — Classify by Urgency

| Bucket | Criteria |
|---|---|
| **Escalated / active** | MALICIOUS or CRITICAL verdict, still open, needs continued attention |
| **Monitoring** | SUSPICIOUS/investigating, no immediate action needed but not closed |
| **Closed this shift** | Resolved, false positive, or remediated during the shift |
| **Blocked / needs input** | Waiting on user response, vendor, or another team |

---

## Step 4 — Flag Anything Unresolved or Ambiguous

Explicitly call out:
- Items with no clear owner for the next shift
- Verdicts that were uncertain or based on incomplete enrichment (say why)
- Any pattern across multiple items (e.g., three phishing reports from the same sender domain —
  worth flagging as a possible campaign rather than three unrelated tickets)

---

## Step 5 — Render Handoff Document

This is a document, not a chat answer — render via `visualize:show_widget` in HTML mode, or as a
Slack Canvas via `Slack:slack_create_canvas` if the user's workflow lives in Slack (ask, or infer
from context/available tools).

Required sections:

1. **Header** — shift window, analyst name (if given), total items handled, counts per bucket
2. **Escalated / active items** — table: ticket/ID | summary | verdict | current owner | next step
3. **Monitoring items** — same shape, lighter treatment
4. **Closed this shift** — one-line each, for context only
5. **Needs input / blocked** — what's blocking, who it's waiting on
6. **Patterns & campaign notes** — cross-item observations worth the next shift knowing
7. **Footer** — generated timestamp, source of truth (Jira query used, or "user-provided list")

### Visual Design Rules (all reports)

Follow the claude.ai design system exactly:

- **No hardcoded hex colors.** Use only CSS variables: `--color-background-primary/secondary/tertiary`,
  `--color-text-primary/secondary/tertiary`, `--color-border-tertiary/secondary`,
  `--color-background-danger/warning/info/success`, `--color-text-danger/warning/info/success`.
- **Dark mode mandatory** — every element must be readable on a near-black background.
- Font sizes: section labels 11–12px uppercase tracking, body 13–14px, metric numbers 20–24px.
  Font weights: 400 body, 500 headings/labels only. Never 600 or 700.
- Cards: `background: var(--color-background-primary); border: 0.5px solid var(--color-border-tertiary);
  border-radius: 12px; padding: 1rem 1.25rem`.
- Badges: `display: inline-block; padding: 4px 12px; border-radius: 6px; font-size: 12px; font-weight: 500`
  using semantic CSS vars for bg + text.
- Section separators: `border-top: 0.5px solid var(--color-border-tertiary)`.
- Tabler outline icons only (`<i class="ti ti-NAME" aria-hidden="true">`). Never filled variants.
- Sentence case everywhere. No ALL CAPS section titles.
- No gradients, drop shadows, blur, or glow effects.
- Score/meter bars: plain `<div>` with width `${value}%`, no canvas or chart libraries.
- Always render via `visualize:show_widget` (HTML mode). Call `visualize:read_me` with
  `modules: ["mockup"]` first if not already done this session. One line of prose before the
  widget call, nothing after except an offer to drill into any section.

---

## Handling Edge Cases

**No time window given**: Ask once — "what shift window should I pull (e.g. last 8 hours, or a
specific start/end time)?" — rather than guessing, since a wrong window either misses items or
pulls in noise.

**Very high ticket volume**: Summarize closed items as a single count line rather than one row
each; spend detail budget on escalated/blocked items, since those are what the next shift acts on.

**No Jira/Atlassian connector available**: Work entirely from user-pasted content and say so in
the footer, so the next analyst knows the handoff isn't a system-of-record pull.

**Conflicting verdicts logged across the shift for the same entity**: Surface the conflict rather
than silently picking the latest one — that's exactly the kind of thing a handoff should catch.