Closing Findings While Warm

---
name: closing-findings-while-warm
description:
  "Use whenever you are about to defer a finding, fix, or cleanup instead of
  doing it now - proposing a follow-up bead/issue/ticket, catching a sibling
  defect while wrapping up, feeling something is 'out of scope', or wanting to
  reach DONE faster. Also use on the manager side, when reviewing a completion
  report that proposes a deferral. Illustrative (non-exhaustive) phrasing that
  should trigger this - 'I'll file a follow-up', 'filing this as a P2', 'out of
  scope for now', 'tracked in a new bead', 'we can pick this up later',
  'fast-follow', 'separate PR' - but the trigger is the ACT of deferring, not
  matching one of these exact phrases."
# source: claude-plugin/skills/closing-findings-while-warm/SKILL.md
---

## Closing Findings While Warm

### The defect this skill fixes

An implementer mid-fix notices a sibling defect, or a reviewer flags a finding
during a review cycle. The cheap move is to write it down and move on: file a
bead, note "P2 fast-follow" in the report, close out DONE. That paper trail
looks like closure but frequently isn't — the bead never gets created, the
context that made the fix cheap (the file open, the failure mode fresh in mind)
is gone by the time anyone looks at it again, and "tracked" quietly becomes
"dropped."

**"A deferral's paper trail is not self-verifying."**

### Role-differentiated resolution

The trigger is the same for every role — a finding just surfaced and someone is
about to defer it. The correct response differs by who is speaking.

#### Implementer: surface, don't self-authorize

An implementer who notices a finding should **surface it to whoever dispatched
them, while still warm, with the shape of the fix** — what's broken, why, and
roughly what the fix looks like. Do NOT go fix it unilaterally, and do NOT
unilaterally decide it's out of scope and drop it.

This is not a failure mode to train out. An implementer proposing a follow-up is
**correct subordinate behavior** — implementers do not own scope, the dispatcher
does. The defect this skill targets is never "the implementer proposed a
deferral instead of just fixing it." Surfacing with the fix's shape and stopping
there is the right move.

#### Manager tier: you make the call, default is fix-now

Whoever dispatched the implementer — orchestrator or coordinator, whichever tier
is currently managing that thread — owns the fix-now-vs-defer decision. The
default is: **direct the fix now, while the expert is still warm.**
Re-dispatching later means re-loading context that's about to evaporate, plus a
second review cycle, plus a live bead to track in the meantime.

If you're a manager-tier reader of this skill reaching for "just tell the
implementer to go fix it themselves" as the resolution here — stop. That
phrasing is the exact defect this skill was written to close out. An implementer
does not self-authorize scope expansion; only the dispatcher directs it. Writing
"just go fix it" without you actually making and owning that call is exactly the
anti-pattern this design pass amended. It will fail review.

Only defer when the legitimate-deferral bar below is fully met — and even then,
the deferral isn't done until its bead is verified to exist.

**Recipient duty, not just reporter duty:** before accepting any deferral,
independently run `bd show <id>` yourself — do not trust the reporter's
self-attestation that a bead was filed and confirmed. A cited bead ID is not
evidence until the RECIPIENT, not the reporter, has confirmed it resolves.

### Legitimate-deferral bar (narrow — do not let this become a rubber stamp)

A deferral is legitimate only when **all three** hold:

**(a) Genuine independence.** The finding touches a genuinely different
subsystem with no intersection with the current branch's diff, OR the fix is
blocked on an external dependency (another team's merge, an upstream release, a
design decision not yet made). "I'd rather not right now" is not independence.

**(b) Named assignee and a dispatch date.** Not "someone will pick this up" — a
specific agent or person, and when it will be dispatched. An unowned deferral is
a deferral to nobody.

**(c) The bead exists, verified.** Create the bead, then run `bd show <id>` and
echo the ID back in your report. A deferral is not closed by the intention to
file a bead — it is closed by the bead existing and being confirmed to exist.
"I'll file a follow-up" is a promise; `bd show thrum-xyz` returning the issue is
evidence.

If any of (a)/(b)/(c) is missing, it is not a legitimate deferral — direct the
fix now instead.

### Worked example: the bead that wasn't there

A fix once split off a sibling defect as a "P2 fast-follow"; the report claimed
a bead was filed and a later snapshot carried that as settled fact, but the bead
was never created and nobody ran `bd show` to confirm it. The paper trail read
as closure; it wasn't.

This is the failure mode part (c) exists to close: verify existence with the
tool that can prove it, not by trusting the sentence that claims it.

### Project-specific rules (already loaded)

Load the $thrum:project-rules-protocol skill and follow it.

If you accumulate a new rule mid-session (the user corrects you), capture it via
the Memory section of your role preamble (or `coordinator-maintaining- memory`
if you're operating in a manager tier) — it references the `thrum-memory` skill
for the canonical `thrum memory create` shape.