routine-anti-noise

name	routine-anti-noise
description	ALWAYS load when a routine is about to act on a GitHub issue or post a comment. Enforces the skip-on-label gate, the don't-re-state-known-blockers rule, and the consolidation pin format for inherited duplicate blockers.
triggers	["ALWAYS load alongside `implement-from-issue`.","ALWAYS load before posting any comment on an issue or PR from a routine.","ALWAYS load when a session inherits a backlog of prior `_Generated by Claude Code_`-signed comments on the issue."]

routine-anti-noise

A routine that fires on every issues.opened event will, over time, accumulate comments on the same issues across runs. Without an anti-noise discipline it will:

• Implement issues a human has already labeled as out-of-scope.
• Re-post the same blocker comment every run, drowning the human's reply.
• Create a wall of duplicate blocker pins instead of a single readable one.

This skill is the discipline. Apply it before doing any real work on an issue and again before posting any comment.

1. Skip-on-label gate

Before any other work on the resolved issue, fetch the labels (you likely already have them from [[routine-event-resolve]]):

gh issue view <N> --repo <slug> --json labels

Exit silently (no comment, no commit, no PR) if labels include any of:

• needs-decision — a Claude-signed pin is already awaiting a human reply.
• needs-you — explicit "human required" marker.
• awaiting-human — same intent, alternative name.
• impl-blocked — implementation hit a wall a routine cannot resolve.
• discussion — the human has marked this as conversation, not implementation.
• question — open question to the maintainer, not an implementation request.
• wontfix — closed-in-spirit; do not implement.
• duplicate — covered elsewhere; do not implement.

These labels mean a human has already routed the issue away from autonomous implementation. Re-engaging with a comment, label, or PR is noise, not signal.

2. Don't re-state known blockers

Before posting any comment on the issue, fetch the recent comment thread:

gh issue view <N> --repo <slug> --comments

Scan the last ~10 comments for _Generated by Claude Code_-signed entries.

• Skip-and-label. If a prior Claude-signed comment already raised the same blocker (same decision, same proposed options) and the owner has not replied since: do NOT re-post. Apply needs-decision if it isn't already on the issue. Exit.
• First-time blocker. If no prior Claude-signed comment raises this blocker, post the comment, apply needs-decision, exit.

Re-posting the same blocker resets nothing on the human's side — they already saw it. Adding the label and exiting is louder than another comment.

3. Consolidation pin (only when inheriting ≥3 duplicates)

If you find ≥3 duplicate Claude-signed blocker comments on the issue and there's no needs-decision label yet: the prior routine runs failed to apply the label, and the thread is now hard to read. Post ONE consolidation pin, apply the label, exit. Do not delete prior comments.

Pin format

**BLOCKING ON:** <one-sentence decision needed>

Proposed options:
A) <one-line summary of option A and what would ship>
B) <one-line summary of option B and what would ship>
C) <one-line summary of option C and what would ship> _(omit if only two)_

Reply `approve A` (etc.) or redirect — this routine will resume on the next fire.

_Generated by Claude Code._

One pin per inherited blocker decision. If two unrelated decisions are blocked, that's two pins, not one combined pin.

Hard constraints

• Never delete or edit prior comments — Claude-signed or otherwise. Add a pin, apply a label, exit. The thread history is the audit trail.
• Never invoke a user-question tool. Routines have no user to answer. The pin comment IS the question; the label IS the wait state.
• Pass --repo <slug> to every gh call.