follow-the-threadlisted
Install: claude install-skill serhiy-bzhezytskyy/contrib-receipts
# Follow the thread
## Purpose
The most productive way to find work worth doing is not triage or a good-first-issue
scan — it's to **follow a thread you already touched**. One red CI test, followed
honestly instead of waved off as "not my bug," root-causes to an upstream issue;
fixing that means reading the subsystem around it, where adjacent open issues are
already filed; searching near that one surfaces a third. The signal is in the code
you're already standing in. Etiquette skills stop you from being noise; this one
finds where the signal is.
The discipline is one question at every hop: **"why does THIS happen?"** instead of
"not mine." Each honest answer either ends the thread or hands you the next issue.
## When to use
- A red CI or a flake appears on your own PR, or on a repo you're already in.
- You've root-caused one bug and want to know whether it's isolated or a nest.
- You're standing in an unfamiliar subsystem and want to read outward, not just fix
the one line you came for.
## When NOT to use
You already have a scoped, agreed task to land — don't let thread-following become scope creep that stalls the PR in front of you; source the next thread after this one ships.
## The practice (checklist)
- [ ] **Red CI on your own PR → follow it, don't dismiss it.** A flake on your PR is
a seam. Triage it honestly first: is it actually flaky, or deterministic?
- [ ] **Map the failing test to its existing issue, then to the UPSTREAM cause.** A
downstrea