Recursive Spine Nudge

---
name: recursive-spine-nudge
description: Use after a recursive-spine-digest sweep to select and deliver system-initiated nudges — 0–3 conversation-starters pushed to the owner about what is unblocked, aging, stalled, or newly connected. Every nudge ends in a question; the skill proposes conversations, never executes work.
---

# recursive-spine: nudge

The digest reports; the nudge starts a conversation. This skill is the
initiative organ of the collaborative loop (#47): it may only propose,
shaped so that autonomy is structurally impossible — a nudge that cannot
end in a question to a human is dropped, whatever its rank.

## Configuration (read, never assume)

From the invoking context or the private hive's `nudges/config.md`:
delivery destination (Slack DM, issue comment, or file), tracking issue,
ledger location, age thresholds. From the dialect note of the invoking
repo: board owner, repo set. Never hardcode any of these. Nudge state is
private-scope: ledger and config live in the private hive, never in a
public repo.

## Inputs

1. **The sweep** — run or receive a recursive-spine-digest sweep
   (aging deferrals, stalled milestones, in-flight by lane,
   assigned-but-untouched, honest denominators).
2. **Dependency reading** (new sensing) — per repo, find items that became
   unblocked, by two readings:
   - **Query (preferred):** for issues with sub-issues (mechanics in
     `${CLAUDE_PLUGIN_ROOT}/reference/sub-issues.md`, Read a tree), the
     sequence head is the first open child in sub-issue order whose
     earlier siblings are all closed. Verifiable structure.
   - **Prose (fallback):** issues whose recorded sequencing ("sequenced
     after…", "blocked by…", milestone ordering, lane position) names
     predecessors that are now all closed — for sequences not yet
     converted to sub-issues.
   Cite the predecessor state in the nudge, and say which reading
   produced the candidate.
3. **Pollen reading** (new sensing) — pollen records that plausibly relate
   to an open deferral. Every pair must cite *why* (shared mechanism,
   named skill, same moment). No citation, no candidate.
4. **The ledger** — `nudges/ledger.md` in the private hive: every prior
   nudge, its trigger, and its outcome.

## Candidate shape — the safety gate

Every candidate is *observation → why now → question*:

> #68 is next in the flagship lane (obs); the watches-itself milestone
> opened and its roadmap predecessors closed this week (why now); want to
> brainstorm it this week? (question)

Drop any candidate that cannot honestly take this shape.

## Discipline rules (ledger-enforced)

- **Never re-send an unanswered nudge** unless its underlying state
  changed since (issue edited, commented, relabeled, or a predecessor
  closed after the nudge date).
- **Declined stays declined** unless the issue changed after the decline.
- **Max 3 nudges per delivery.** When candidates exceed 3, say so
  ("3 of N candidates").
- **Empty week is stated, not padded:** "no nudges this week — nothing
  newly unblocked, nothing aged past threshold." The heartbeat stays
  visible even when the content is empty.

## Ranking

1. Unblocked-and-next (concrete, actionable now; within this trigger,
   query-derived heads outrank prose-derived ones — verifiable beats
   inferred)
2. Aging deferrals (oldest first)
3. Stalled milestones
4. Pollen↔deferral connections (fuzziest; earns rank as it proves precision)

Within a trigger, older first.

## Delivery

Send the selected nudges to the configured destination. Footer always
carries the honest denominator ("swept N/M; X failed: reason") when any
repo failed. If the primary channel send fails, post the nudges as a
comment on the tracking issue prefixed `nudge-delivery-failed:` — the
heartbeat must stay observable when the channel isn't.

Delivery is two-part. A channel send made as the owner's own identity
notifies no one — Slack never alerts you to your own posts — so the
channel message is the record half and an **attention ping** is the push
half: one line, under 200 characters, no markdown, leading with count and
top nudge headline (e.g. "spine: 3 nudges — top: plumb-line v0.8.0 next;
see the delivery channel"). The ping mechanism is whatever the invoking runner provides
(push notification, routine completion notice) — never hardcode one. If
the runner has no ping mechanism, say so in the delivery footer rather
than failing. Empty weeks send no ping: the heartbeat stays visible in
the thread and ledger, but an empty week is not worth an interruption.

## Ledger append (always, even on empty weeks)

Append to `nudges/ledger.md`: run timestamp, swept N/M, one line per nudge
sent (`date | repo#issue | trigger | outcome: pending`). If the previous
run's timestamp is more than one interval old, open the delivery with
"missed N scheduled runs."

## Never

- Never execute, file, close, or edit work a nudge proposes — the owner's
  reply starts that conversation elsewhere.
- Never auto-file pollen matches as issues in target repos (that is #38,
  deliberately deferred).
- Never write nudge state to a public repo.
- Never depend on a Claude Code hook having fired (#71 is an adapter,
  never the method).