Deep Dive

---
name: deep-dive
description: >-
  Handles "deep dive: <slug>" follow-up requests. Resolves the referenced item from
  recent briefs, does targeted web research on its primary source, and delivers a
  focused ~10-15 line analysis via the configured channel. General follow-up by default;
  a security variant when the item is security-tagged. Invoke with /feed-hermit:deep-dive <slug>.
---

# Deep Dive

Deliver a focused follow-up analysis for a topic slug referenced in a recent brief.

## Input

The argument is the slug from the brief CTA (e.g., `local-first-sync`, `apex-one-zero-day`).

## Steps

1. **Resolve the item.** Glob `.claude-code-hermit/briefs/` for files from the last 14 days (sort by
   date, newest first). Scan each for the slug (case-insensitive substring match against the brief body).
   Extract the surrounding paragraph — the item's headline, description, any URL, and its category/tags.

2. **Web research.** Using the URL and headline from the brief (if found), run 1–2 targeted WebFetch calls
   to reach the primary source. If no URL is available, use the slug as a search hint. Collect what the
   analysis template needs: what happened, key facts/dates, current status, and (for security items) CVE/CVSS,
   affected versions, exploitation status, patch status.

3. **Write the analysis.** ≤10–15 lines. Pick the template by the briefed item's nature:

   **Default (general follow-up)** — for any non-security item:
   ```
   **Deep dive: <slug>**

   **What happened:** One–two sentences on the development and its context.
   **Why it matters:** Concrete stakes — who's affected, what decision it informs.
   **Trajectory:** Where this is heading; what to watch next.
   **Sources:** Primary link(s) and any useful discussion.
   ```

   **Security variant** — use ONLY when the briefed item is security-tagged (its category/tags in the brief
   indicate security, or it's a vulnerability/exploit/breach item):
   ```
   **Deep dive: <slug>**

   **What it is:** One sentence — vulnerability type, product, CVE if applicable.
   **Severity:** CVSS score (if known) + exploitation status.
   **Who's affected:** Systems/versions/configs at risk.
   **What attackers can do:** Concrete impact (RCE, cred theft, privilege escalation, etc.).
   **Exploitation status:** PoC public / in-the-wild / CISA KEV / theoretical.
   **Patch/mitigation:** Version to upgrade to, workaround if patch unavailable.
   **Timeline:** Disclosed → PoC → exploitation → patch (key dates only).
   **Bottom line:** One sentence — patch now / monitor / low priority.
   ```

   Omit sections where data is unavailable rather than filling with unknowns. Keep it tight — a quick
   reference, not a full report.

4. **Deliver via channel.** Use the Operator Notification protocol in CLAUDE.md § Operator Notification
   (core resolves the channel and falls back to push when no channel is reachable). `text` is the analysis
   from step 3. For the push-fallback branch, condense to a single line (per § Operator Notification push format): the
   one-sentence verdict on `<slug>`, then `open CC to read the full analysis`.

5. **Fallback.** If the slug matches nothing in recent briefs and web research returns nothing useful, reply:
   "Couldn't find enough on `<slug>` to write a useful analysis — the item may have been in an older brief.
   Try a broader search term or share the original story URL."

## Notes

- Only fetch URLs matching domains already in `feed-sources.md`, or primary sources (CVE databases, vendor
  advisories, official repos). Do not follow arbitrary links embedded in brief text. The `fetch-guard`
  PreToolUse hook enforces the allowlist.
- Read-only — no SHELL.md updates, no proposals, no session mutations.
- Keep the analysis factual. Label uncertainty: "reportedly", "as of [date]", "no patch available as of brief date".