[v3-2-test] Add pr-triage skill — maintainer-driven first-pass PR triage (#65648)

[github-actions]

• Add pr-triage skill for maintainer-driven PR queue sweep

A skill-based replacement for the triage mode of breeze pr auto-triage.
Scope is triage only — no LLM code review, no approve/request-changes,
no merging, no TUI.

Shape follows the airflow-translations convention:
.github/skills/pr-triage/ holds the canonical content;
.claude/skills/pr-triage is a committed symlink so Claude Code picks
it up without per-developer setup. .gitignore is updated to let the
symlink through, and the agentic-markdown license hook excludes
SKILL.md entry point so YAML frontmatter can stay at the top.

Also refreshes dev/breeze/doc/images/output_pr_auto-triage.{svg,txt}
— upstream's committed image was stale (boring-cyborg.yml added
labels the committed image hadn't regenerated yet), and the pre-commit
hook regenerates it on every touch of the breeze config.

Generated-by: Claude Opus 4.7 (1M context) following the guidelines
in contributing-docs/05_pull_requests.rst

• pr-triage: add Copilot-review staleness + prefer author-pings

Two rule refinements surfaced while running the skill on
apache/airflow:

1. New classification stale_copilot_review. When a PR has an
   unresolved review thread authored by a Copilot-review bot
   (copilot-pull-request-reviewer[bot] and siblings) and the
   comment is >= 14 days old with no author reply, the skill
   classifies it as stale_copilot_review and suggests draft
   with a new "Unaddressed Copilot review" violation. The
   14-day window is deliberately longer than the 24h/96h CI
   grace — review feedback takes longer to address and a
   two-day nudge would be noisy.

2. Strongly prefer pinging the PR author over the reviewer on
   the ping action. Both comment families (review-nudge for
   stale CHANGES_REQUESTED, reviewer-ping for unresolved
   threads) now document an author-primary default body and a
   reviewer-re-review variant. The reviewer-re-review body is
   only used after an explicit inspection of the post-review
   diff + in-thread replies confirms the feedback has been
   addressed in code or explained away. The previous logic
   (which switched on whether the author had @-mentioned the
   reviewer) put the re-review request on the reviewer's desk
   even when the actual work was still on the author's side.

Updates classify.md, suggested-actions.md, actions.md,
comment-templates.md, SKILL.md, and interaction-loop.md so the
group ordering, data requirements, and body-template decision
are consistent across the skill.

• pr-triage: never suggest rebase on CONFLICTING PRs — route to draft

Empirically every rebase attempted on a PR whose mergeable state
is CONFLICTING came back with "Cannot update PR branch due to
conflicts". GitHub's update-branch endpoint does a side-merge
of the base branch into the PR head; when the merge doesn't
apply cleanly, it refuses, and retrying burns round-trips
without progress. The fix is to stop suggesting rebase in that
state at all — those PRs go straight to draft with the
merge-conflicts violation so the author is pointed at the
local-rebase instructions in the comment body.

• suggested-actions.md: the "mergeable == CONFLICTING" rule now
  maps to draft regardless of other signals. An explicit hard
  rule spells out why.
• actions.md#rebase: a mergeable check runs before the
  update-branch call; if the state is CONFLICTING the action
  refuses with a route-to-draft hint. If a non-CONFLICTING call
  still 422s, the skill does not retry — it falls through to
  draft.
• SKILL.md Step 3 table updated to reflect the new mapping.

• pr-triage: tighten untriaged-draft stale threshold from 3 weeks to 2 weeks

Drafts that have had no activity for 14 days (was 21) now fall into
Sweep 1b (untriaged-draft close). The triaged-draft 7-day threshold
for Sweep 1a is unchanged.

Maintainer preference: two weeks is enough signal that a draft has
stalled; waiting the extra week was leaving queue pressure without
adding useful context on author intent.

• pr-triage: stale-Copilot threshold 14 days -> 7 days, soften body

Two related changes for the stale_copilot_review classification:

• Tighten the trigger threshold. Copilot reviews that sit unaddressed
  for a week already signal a stalled PR — waiting two weeks before
  drafting adds queue pressure without useful signal.

• Revise the draft-comment language to explicitly call out that some
  Copilot suggestions may be incorrect or irrelevant, and that it is
  still the author's responsibility to respond — apply the fix, reply
  in-thread explaining why it does not apply, or resolve the thread
  if the feedback is no longer relevant. Previously the wording could
  be read as 'please do everything Copilot said', which is the wrong
  bar.

• pr-triage: make action_required REST check primary for pending_workflow_approval

A PR that has real CI runs held in action_required for approval
can still report statusCheckRollup.state == SUCCESS, because the
rollup aggregates only completed check-runs and fast bot checks
(Mergeable, WIP, DCO, boring-cyborg) succeed unconditionally
before the real CI is even allowed to start. Trusting the rollup
classifies such a PR as passing and leads to premature mark-ready.

Changes:

• classify.md: rewrite C1 (pending_workflow_approval) so the
  repo-level REST call GET /repos/.../actions/runs?status=action_required
  is the primary signal, not a fallback. Index the response by
  head_sha once per page. Call out that the rollup-based check
  alone is not sufficient and explain why.

• classify.md: rewrite 'Verifying real CI ran' from an optional
  note into a mandatory pre-passing guard. Expand the real-CI
  pattern list to include Tests (exact), CodeQL, and
  'Check newsfragment PR number'.

• fetch-and-batch.md: add an 'Mandatory: action_required run
  index per page' section that documents the REST call as part of
  the per-page fetch plan (one extra round-trip per page, well
  inside the budget).

• pr-triage: spell out author responsibility to mark threads resolved

The Unresolved review comments / Unaddressed Copilot review violation
bodies now explicitly state that it is the author's responsibility to
mark a thread as resolved once they believe it has been addressed —
whether that was by pushing a fix or by replying with an explanation
of why the suggestion doesn't apply.

Reviewers do not auto-close their own threads, so a thread that is
addressed but left unresolved reads as 'still waiting on the author'
and blocks the PR from moving forward. Making this explicit in the
draft comment is the difference between first-time contributors
wondering why their PR still looks blocked after a fix vs. knowing
to click 'Resolve conversation' at the bottom of each thread.

• pr-triage: mandatory pre-check against action_required on mark-ready

Sole purpose of this commit is to add an executable guard in
actions.md that the classifier's real-CI-ran check cannot
substitute for. Empirically, the classifier can still green-light
a PR that has pending workflow approvals if the GraphQL batch
fetch was taken before GitHub indexed a freshly-required workflow
run, or if only the bot subset of checks has completed and the
classifier's 30-context sample missed a real-CI entry.

Changes:

• actions.md §mark-ready: add a MUST-DO pre-mutation check —
  GET /repos///actions/runs?head_sha=&status=
  action_required returning any result is a hard refuse. On
  refuse, reclassify the PR as pending_workflow_approval and
  route accordingly instead of silently dropping the mutation.

• SKILL.md Golden rules: add rule 1b elevating the check to the
  top-of-file contract so a skill implementor can't miss it.
  The rationale (fast bot checks finish first while Tests /
  CodeQL / newsfragment sit in action_required) is spelled out
  so nobody thinks this is belt-and-braces redundancy.

• pr-triage: add AI-attribution footer to contributor comments

Every contributor-facing triage comment now ends with a short
footer that (a) notes the comment was drafted by an AI-assisted
tool and may contain mistakes, (b) reassures the contributor
that a human maintainer will take the next look once they
address the feedback, and (c) links to a new section in the
maintainer-triage contributing doc that explains why the first
pass is automated — to free scarce maintainer time for the
conversation with contributors rather than mechanical queue
sweeping.

The footer is defined once in comment-templates.md as
<ai_attribution_footer> and referenced from every
contributor-facing template (draft, comment-only, close,
review-nudge, reviewer-ping, stale-draft-close,
inactive-to-draft, stale-workflow-approval). The
suspicious-changes template is intentionally excluded — it is
terse and already directs the contributor to maintainers on
Slack, and adding the footer would dilute the signal.

SKILL.md carries a new Golden rule 8 capturing the requirement
and the link to the rationale anchor.
(cherry picked from commit 0ed3e73)

Co-authored-by: Jarek Potiuk jarek@potiuk.com

[github-actions]

• Add pr-triage skill for maintainer-driven PR queue sweep

A skill-based replacement for the triage mode of breeze pr auto-triage.
Scope is triage only — no LLM code review, no approve/request-changes,
no merging, no TUI.

Shape follows the airflow-translations convention:
.github/skills/pr-triage/ holds the canonical content;
.claude/skills/pr-triage is a committed symlink so Claude Code picks
it up without per-developer setup. .gitignore is updated to let the
symlink through, and the agentic-markdown license hook excludes
SKILL.md entry point so YAML frontmatter can stay at the top.

Also refreshes dev/breeze/doc/images/output_pr_auto-triage.{svg,txt}
— upstream's committed image was stale (boring-cyborg.yml added
labels the committed image hadn't regenerated yet), and the pre-commit
hook regenerates it on every touch of the breeze config.

Generated-by: Claude Opus 4.7 (1M context) following the guidelines
in contributing-docs/05_pull_requests.rst

• pr-triage: add Copilot-review staleness + prefer author-pings

Two rule refinements surfaced while running the skill on
apache/airflow:

1. New classification stale_copilot_review. When a PR has an
   unresolved review thread authored by a Copilot-review bot
   (copilot-pull-request-reviewer[bot] and siblings) and the
   comment is >= 14 days old with no author reply, the skill
   classifies it as stale_copilot_review and suggests draft
   with a new "Unaddressed Copilot review" violation. The
   14-day window is deliberately longer than the 24h/96h CI
   grace — review feedback takes longer to address and a
   two-day nudge would be noisy.

2. Strongly prefer pinging the PR author over the reviewer on
   the ping action. Both comment families (review-nudge for
   stale CHANGES_REQUESTED, reviewer-ping for unresolved
   threads) now document an author-primary default body and a
   reviewer-re-review variant. The reviewer-re-review body is
   only used after an explicit inspection of the post-review
   diff + in-thread replies confirms the feedback has been
   addressed in code or explained away. The previous logic
   (which switched on whether the author had @-mentioned the
   reviewer) put the re-review request on the reviewer's desk
   even when the actual work was still on the author's side.

Updates classify.md, suggested-actions.md, actions.md,
comment-templates.md, SKILL.md, and interaction-loop.md so the
group ordering, data requirements, and body-template decision
are consistent across the skill.

• pr-triage: never suggest rebase on CONFLICTING PRs — route to draft

Empirically every rebase attempted on a PR whose mergeable state
is CONFLICTING came back with "Cannot update PR branch due to
conflicts". GitHub's update-branch endpoint does a side-merge
of the base branch into the PR head; when the merge doesn't
apply cleanly, it refuses, and retrying burns round-trips
without progress. The fix is to stop suggesting rebase in that
state at all — those PRs go straight to draft with the
merge-conflicts violation so the author is pointed at the
local-rebase instructions in the comment body.

• suggested-actions.md: the "mergeable == CONFLICTING" rule now
  maps to draft regardless of other signals. An explicit hard
  rule spells out why.
• actions.md#rebase: a mergeable check runs before the
  update-branch call; if the state is CONFLICTING the action
  refuses with a route-to-draft hint. If a non-CONFLICTING call
  still 422s, the skill does not retry — it falls through to
  draft.
• SKILL.md Step 3 table updated to reflect the new mapping.

• pr-triage: tighten untriaged-draft stale threshold from 3 weeks to 2 weeks

Drafts that have had no activity for 14 days (was 21) now fall into
Sweep 1b (untriaged-draft close). The triaged-draft 7-day threshold
for Sweep 1a is unchanged.

Maintainer preference: two weeks is enough signal that a draft has
stalled; waiting the extra week was leaving queue pressure without
adding useful context on author intent.

• pr-triage: stale-Copilot threshold 14 days -> 7 days, soften body

Two related changes for the stale_copilot_review classification:

• Tighten the trigger threshold. Copilot reviews that sit unaddressed
  for a week already signal a stalled PR — waiting two weeks before
  drafting adds queue pressure without useful signal.

• Revise the draft-comment language to explicitly call out that some
  Copilot suggestions may be incorrect or irrelevant, and that it is
  still the author's responsibility to respond — apply the fix, reply
  in-thread explaining why it does not apply, or resolve the thread
  if the feedback is no longer relevant. Previously the wording could
  be read as 'please do everything Copilot said', which is the wrong
  bar.

• pr-triage: make action_required REST check primary for pending_workflow_approval

A PR that has real CI runs held in action_required for approval
can still report statusCheckRollup.state == SUCCESS, because the
rollup aggregates only completed check-runs and fast bot checks
(Mergeable, WIP, DCO, boring-cyborg) succeed unconditionally
before the real CI is even allowed to start. Trusting the rollup
classifies such a PR as passing and leads to premature mark-ready.

Changes:

• classify.md: rewrite C1 (pending_workflow_approval) so the
  repo-level REST call GET /repos/.../actions/runs?status=action_required
  is the primary signal, not a fallback. Index the response by
  head_sha once per page. Call out that the rollup-based check
  alone is not sufficient and explain why.

• classify.md: rewrite 'Verifying real CI ran' from an optional
  note into a mandatory pre-passing guard. Expand the real-CI
  pattern list to include Tests (exact), CodeQL, and
  'Check newsfragment PR number'.

• fetch-and-batch.md: add an 'Mandatory: action_required run
  index per page' section that documents the REST call as part of
  the per-page fetch plan (one extra round-trip per page, well
  inside the budget).

• pr-triage: spell out author responsibility to mark threads resolved

The Unresolved review comments / Unaddressed Copilot review violation
bodies now explicitly state that it is the author's responsibility to
mark a thread as resolved once they believe it has been addressed —
whether that was by pushing a fix or by replying with an explanation
of why the suggestion doesn't apply.

Reviewers do not auto-close their own threads, so a thread that is
addressed but left unresolved reads as 'still waiting on the author'
and blocks the PR from moving forward. Making this explicit in the
draft comment is the difference between first-time contributors
wondering why their PR still looks blocked after a fix vs. knowing
to click 'Resolve conversation' at the bottom of each thread.

• pr-triage: mandatory pre-check against action_required on mark-ready

Sole purpose of this commit is to add an executable guard in
actions.md that the classifier's real-CI-ran check cannot
substitute for. Empirically, the classifier can still green-light
a PR that has pending workflow approvals if the GraphQL batch
fetch was taken before GitHub indexed a freshly-required workflow
run, or if only the bot subset of checks has completed and the
classifier's 30-context sample missed a real-CI entry.

Changes:

• actions.md §mark-ready: add a MUST-DO pre-mutation check —
  GET /repos///actions/runs?head_sha=&status=
  action_required returning any result is a hard refuse. On
  refuse, reclassify the PR as pending_workflow_approval and
  route accordingly instead of silently dropping the mutation.

• SKILL.md Golden rules: add rule 1b elevating the check to the
  top-of-file contract so a skill implementor can't miss it.
  The rationale (fast bot checks finish first while Tests /
  CodeQL / newsfragment sit in action_required) is spelled out
  so nobody thinks this is belt-and-braces redundancy.

• pr-triage: add AI-attribution footer to contributor comments

Every contributor-facing triage comment now ends with a short
footer that (a) notes the comment was drafted by an AI-assisted
tool and may contain mistakes, (b) reassures the contributor
that a human maintainer will take the next look once they
address the feedback, and (c) links to a new section in the
maintainer-triage contributing doc that explains why the first
pass is automated — to free scarce maintainer time for the
conversation with contributors rather than mechanical queue
sweeping.

The footer is defined once in comment-templates.md as
<ai_attribution_footer> and referenced from every
contributor-facing template (draft, comment-only, close,
review-nudge, reviewer-ping, stale-draft-close,
inactive-to-draft, stale-workflow-approval). The
suspicious-changes template is intentionally excluded — it is
terse and already directs the contributor to maintainers on
Slack, and adding the footer would dilute the signal.

SKILL.md carries a new Golden rule 8 capturing the requirement
and the link to the rationale anchor.
(cherry picked from commit 0ed3e73)

Co-authored-by: Jarek Potiuk jarek@potiuk.com

[github-actions]

• Add pr-triage skill for maintainer-driven PR queue sweep

A skill-based replacement for the triage mode of breeze pr auto-triage.
Scope is triage only — no LLM code review, no approve/request-changes,
no merging, no TUI.

Shape follows the airflow-translations convention:
.github/skills/pr-triage/ holds the canonical content;
.claude/skills/pr-triage is a committed symlink so Claude Code picks
it up without per-developer setup. .gitignore is updated to let the
symlink through, and the agentic-markdown license hook excludes
SKILL.md entry point so YAML frontmatter can stay at the top.

Also refreshes dev/breeze/doc/images/output_pr_auto-triage.{svg,txt}
— upstream's committed image was stale (boring-cyborg.yml added
labels the committed image hadn't regenerated yet), and the pre-commit
hook regenerates it on every touch of the breeze config.

Generated-by: Claude Opus 4.7 (1M context) following the guidelines
in contributing-docs/05_pull_requests.rst

• pr-triage: add Copilot-review staleness + prefer author-pings

Two rule refinements surfaced while running the skill on
apache/airflow:

1. New classification stale_copilot_review. When a PR has an
   unresolved review thread authored by a Copilot-review bot
   (copilot-pull-request-reviewer[bot] and siblings) and the
   comment is >= 14 days old with no author reply, the skill
   classifies it as stale_copilot_review and suggests draft
   with a new "Unaddressed Copilot review" violation. The
   14-day window is deliberately longer than the 24h/96h CI
   grace — review feedback takes longer to address and a
   two-day nudge would be noisy.

2. Strongly prefer pinging the PR author over the reviewer on
   the ping action. Both comment families (review-nudge for
   stale CHANGES_REQUESTED, reviewer-ping for unresolved
   threads) now document an author-primary default body and a
   reviewer-re-review variant. The reviewer-re-review body is
   only used after an explicit inspection of the post-review
   diff + in-thread replies confirms the feedback has been
   addressed in code or explained away. The previous logic
   (which switched on whether the author had @-mentioned the
   reviewer) put the re-review request on the reviewer's desk
   even when the actual work was still on the author's side.

Updates classify.md, suggested-actions.md, actions.md,
comment-templates.md, SKILL.md, and interaction-loop.md so the
group ordering, data requirements, and body-template decision
are consistent across the skill.

• pr-triage: never suggest rebase on CONFLICTING PRs — route to draft

Empirically every rebase attempted on a PR whose mergeable state
is CONFLICTING came back with "Cannot update PR branch due to
conflicts". GitHub's update-branch endpoint does a side-merge
of the base branch into the PR head; when the merge doesn't
apply cleanly, it refuses, and retrying burns round-trips
without progress. The fix is to stop suggesting rebase in that
state at all — those PRs go straight to draft with the
merge-conflicts violation so the author is pointed at the
local-rebase instructions in the comment body.

• suggested-actions.md: the "mergeable == CONFLICTING" rule now
  maps to draft regardless of other signals. An explicit hard
  rule spells out why.
• actions.md#rebase: a mergeable check runs before the
  update-branch call; if the state is CONFLICTING the action
  refuses with a route-to-draft hint. If a non-CONFLICTING call
  still 422s, the skill does not retry — it falls through to
  draft.
• SKILL.md Step 3 table updated to reflect the new mapping.

• pr-triage: tighten untriaged-draft stale threshold from 3 weeks to 2 weeks

Drafts that have had no activity for 14 days (was 21) now fall into
Sweep 1b (untriaged-draft close). The triaged-draft 7-day threshold
for Sweep 1a is unchanged.

Maintainer preference: two weeks is enough signal that a draft has
stalled; waiting the extra week was leaving queue pressure without
adding useful context on author intent.

• pr-triage: stale-Copilot threshold 14 days -> 7 days, soften body

Two related changes for the stale_copilot_review classification:

• Tighten the trigger threshold. Copilot reviews that sit unaddressed
  for a week already signal a stalled PR — waiting two weeks before
  drafting adds queue pressure without useful signal.

• Revise the draft-comment language to explicitly call out that some
  Copilot suggestions may be incorrect or irrelevant, and that it is
  still the author's responsibility to respond — apply the fix, reply
  in-thread explaining why it does not apply, or resolve the thread
  if the feedback is no longer relevant. Previously the wording could
  be read as 'please do everything Copilot said', which is the wrong
  bar.

• pr-triage: make action_required REST check primary for pending_workflow_approval

A PR that has real CI runs held in action_required for approval
can still report statusCheckRollup.state == SUCCESS, because the
rollup aggregates only completed check-runs and fast bot checks
(Mergeable, WIP, DCO, boring-cyborg) succeed unconditionally
before the real CI is even allowed to start. Trusting the rollup
classifies such a PR as passing and leads to premature mark-ready.

Changes:

• classify.md: rewrite C1 (pending_workflow_approval) so the
  repo-level REST call GET /repos/.../actions/runs?status=action_required
  is the primary signal, not a fallback. Index the response by
  head_sha once per page. Call out that the rollup-based check
  alone is not sufficient and explain why.

• classify.md: rewrite 'Verifying real CI ran' from an optional
  note into a mandatory pre-passing guard. Expand the real-CI
  pattern list to include Tests (exact), CodeQL, and
  'Check newsfragment PR number'.

• fetch-and-batch.md: add an 'Mandatory: action_required run
  index per page' section that documents the REST call as part of
  the per-page fetch plan (one extra round-trip per page, well
  inside the budget).

• pr-triage: spell out author responsibility to mark threads resolved

The Unresolved review comments / Unaddressed Copilot review violation
bodies now explicitly state that it is the author's responsibility to
mark a thread as resolved once they believe it has been addressed —
whether that was by pushing a fix or by replying with an explanation
of why the suggestion doesn't apply.

Reviewers do not auto-close their own threads, so a thread that is
addressed but left unresolved reads as 'still waiting on the author'
and blocks the PR from moving forward. Making this explicit in the
draft comment is the difference between first-time contributors
wondering why their PR still looks blocked after a fix vs. knowing
to click 'Resolve conversation' at the bottom of each thread.

• pr-triage: mandatory pre-check against action_required on mark-ready

Sole purpose of this commit is to add an executable guard in
actions.md that the classifier's real-CI-ran check cannot
substitute for. Empirically, the classifier can still green-light
a PR that has pending workflow approvals if the GraphQL batch
fetch was taken before GitHub indexed a freshly-required workflow
run, or if only the bot subset of checks has completed and the
classifier's 30-context sample missed a real-CI entry.

Changes:

• actions.md §mark-ready: add a MUST-DO pre-mutation check —
  GET /repos///actions/runs?head_sha=&status=
  action_required returning any result is a hard refuse. On
  refuse, reclassify the PR as pending_workflow_approval and
  route accordingly instead of silently dropping the mutation.

• SKILL.md Golden rules: add rule 1b elevating the check to the
  top-of-file contract so a skill implementor can't miss it.
  The rationale (fast bot checks finish first while Tests /
  CodeQL / newsfragment sit in action_required) is spelled out
  so nobody thinks this is belt-and-braces redundancy.

• pr-triage: add AI-attribution footer to contributor comments

Every contributor-facing triage comment now ends with a short
footer that (a) notes the comment was drafted by an AI-assisted
tool and may contain mistakes, (b) reassures the contributor
that a human maintainer will take the next look once they
address the feedback, and (c) links to a new section in the
maintainer-triage contributing doc that explains why the first
pass is automated — to free scarce maintainer time for the
conversation with contributors rather than mechanical queue
sweeping.

The footer is defined once in comment-templates.md as
<ai_attribution_footer> and referenced from every
contributor-facing template (draft, comment-only, close,
review-nudge, reviewer-ping, stale-draft-close,
inactive-to-draft, stale-workflow-approval). The
suspicious-changes template is intentionally excluded — it is
terse and already directs the contributor to maintainers on
Slack, and adding the footer would dilute the signal.

SKILL.md carries a new Golden rule 8 capturing the requirement
and the link to the rationale anchor.
(cherry picked from commit 0ed3e73)

Co-authored-by: Jarek Potiuk jarek@potiuk.com

[github-actions]

• Add pr-triage skill for maintainer-driven PR queue sweep

A skill-based replacement for the triage mode of breeze pr auto-triage.
Scope is triage only — no LLM code review, no approve/request-changes,
no merging, no TUI.

Shape follows the airflow-translations convention:
.github/skills/pr-triage/ holds the canonical content;
.claude/skills/pr-triage is a committed symlink so Claude Code picks
it up without per-developer setup. .gitignore is updated to let the
symlink through, and the agentic-markdown license hook excludes
SKILL.md entry point so YAML frontmatter can stay at the top.

Also refreshes dev/breeze/doc/images/output_pr_auto-triage.{svg,txt}
— upstream's committed image was stale (boring-cyborg.yml added
labels the committed image hadn't regenerated yet), and the pre-commit
hook regenerates it on every touch of the breeze config.

Generated-by: Claude Opus 4.7 (1M context) following the guidelines
in contributing-docs/05_pull_requests.rst

• pr-triage: add Copilot-review staleness + prefer author-pings

Two rule refinements surfaced while running the skill on
apache/airflow:

1. New classification stale_copilot_review. When a PR has an
   unresolved review thread authored by a Copilot-review bot
   (copilot-pull-request-reviewer[bot] and siblings) and the
   comment is >= 14 days old with no author reply, the skill
   classifies it as stale_copilot_review and suggests draft
   with a new "Unaddressed Copilot review" violation. The
   14-day window is deliberately longer than the 24h/96h CI
   grace — review feedback takes longer to address and a
   two-day nudge would be noisy.

2. Strongly prefer pinging the PR author over the reviewer on
   the ping action. Both comment families (review-nudge for
   stale CHANGES_REQUESTED, reviewer-ping for unresolved
   threads) now document an author-primary default body and a
   reviewer-re-review variant. The reviewer-re-review body is
   only used after an explicit inspection of the post-review
   diff + in-thread replies confirms the feedback has been
   addressed in code or explained away. The previous logic
   (which switched on whether the author had @-mentioned the
   reviewer) put the re-review request on the reviewer's desk
   even when the actual work was still on the author's side.

Updates classify.md, suggested-actions.md, actions.md,
comment-templates.md, SKILL.md, and interaction-loop.md so the
group ordering, data requirements, and body-template decision
are consistent across the skill.

• pr-triage: never suggest rebase on CONFLICTING PRs — route to draft

Empirically every rebase attempted on a PR whose mergeable state
is CONFLICTING came back with "Cannot update PR branch due to
conflicts". GitHub's update-branch endpoint does a side-merge
of the base branch into the PR head; when the merge doesn't
apply cleanly, it refuses, and retrying burns round-trips
without progress. The fix is to stop suggesting rebase in that
state at all — those PRs go straight to draft with the
merge-conflicts violation so the author is pointed at the
local-rebase instructions in the comment body.

• suggested-actions.md: the "mergeable == CONFLICTING" rule now
  maps to draft regardless of other signals. An explicit hard
  rule spells out why.
• actions.md#rebase: a mergeable check runs before the
  update-branch call; if the state is CONFLICTING the action
  refuses with a route-to-draft hint. If a non-CONFLICTING call
  still 422s, the skill does not retry — it falls through to
  draft.
• SKILL.md Step 3 table updated to reflect the new mapping.

• pr-triage: tighten untriaged-draft stale threshold from 3 weeks to 2 weeks

Drafts that have had no activity for 14 days (was 21) now fall into
Sweep 1b (untriaged-draft close). The triaged-draft 7-day threshold
for Sweep 1a is unchanged.

Maintainer preference: two weeks is enough signal that a draft has
stalled; waiting the extra week was leaving queue pressure without
adding useful context on author intent.

• pr-triage: stale-Copilot threshold 14 days -> 7 days, soften body

Two related changes for the stale_copilot_review classification:

• Tighten the trigger threshold. Copilot reviews that sit unaddressed
  for a week already signal a stalled PR — waiting two weeks before
  drafting adds queue pressure without useful signal.

• Revise the draft-comment language to explicitly call out that some
  Copilot suggestions may be incorrect or irrelevant, and that it is
  still the author's responsibility to respond — apply the fix, reply
  in-thread explaining why it does not apply, or resolve the thread
  if the feedback is no longer relevant. Previously the wording could
  be read as 'please do everything Copilot said', which is the wrong
  bar.

• pr-triage: make action_required REST check primary for pending_workflow_approval

A PR that has real CI runs held in action_required for approval
can still report statusCheckRollup.state == SUCCESS, because the
rollup aggregates only completed check-runs and fast bot checks
(Mergeable, WIP, DCO, boring-cyborg) succeed unconditionally
before the real CI is even allowed to start. Trusting the rollup
classifies such a PR as passing and leads to premature mark-ready.

Changes:

• classify.md: rewrite C1 (pending_workflow_approval) so the
  repo-level REST call GET /repos/.../actions/runs?status=action_required
  is the primary signal, not a fallback. Index the response by
  head_sha once per page. Call out that the rollup-based check
  alone is not sufficient and explain why.

• classify.md: rewrite 'Verifying real CI ran' from an optional
  note into a mandatory pre-passing guard. Expand the real-CI
  pattern list to include Tests (exact), CodeQL, and
  'Check newsfragment PR number'.

• fetch-and-batch.md: add an 'Mandatory: action_required run
  index per page' section that documents the REST call as part of
  the per-page fetch plan (one extra round-trip per page, well
  inside the budget).

• pr-triage: spell out author responsibility to mark threads resolved

The Unresolved review comments / Unaddressed Copilot review violation
bodies now explicitly state that it is the author's responsibility to
mark a thread as resolved once they believe it has been addressed —
whether that was by pushing a fix or by replying with an explanation
of why the suggestion doesn't apply.

Reviewers do not auto-close their own threads, so a thread that is
addressed but left unresolved reads as 'still waiting on the author'
and blocks the PR from moving forward. Making this explicit in the
draft comment is the difference between first-time contributors
wondering why their PR still looks blocked after a fix vs. knowing
to click 'Resolve conversation' at the bottom of each thread.

• pr-triage: mandatory pre-check against action_required on mark-ready

Sole purpose of this commit is to add an executable guard in
actions.md that the classifier's real-CI-ran check cannot
substitute for. Empirically, the classifier can still green-light
a PR that has pending workflow approvals if the GraphQL batch
fetch was taken before GitHub indexed a freshly-required workflow
run, or if only the bot subset of checks has completed and the
classifier's 30-context sample missed a real-CI entry.

Changes:

• actions.md §mark-ready: add a MUST-DO pre-mutation check —
  GET /repos///actions/runs?head_sha=&status=
  action_required returning any result is a hard refuse. On
  refuse, reclassify the PR as pending_workflow_approval and
  route accordingly instead of silently dropping the mutation.

• SKILL.md Golden rules: add rule 1b elevating the check to the
  top-of-file contract so a skill implementor can't miss it.
  The rationale (fast bot checks finish first while Tests /
  CodeQL / newsfragment sit in action_required) is spelled out
  so nobody thinks this is belt-and-braces redundancy.

• pr-triage: add AI-attribution footer to contributor comments

Every contributor-facing triage comment now ends with a short
footer that (a) notes the comment was drafted by an AI-assisted
tool and may contain mistakes, (b) reassures the contributor
that a human maintainer will take the next look once they
address the feedback, and (c) links to a new section in the
maintainer-triage contributing doc that explains why the first
pass is automated — to free scarce maintainer time for the
conversation with contributors rather than mechanical queue
sweeping.

The footer is defined once in comment-templates.md as
<ai_attribution_footer> and referenced from every
contributor-facing template (draft, comment-only, close,
review-nudge, reviewer-ping, stale-draft-close,
inactive-to-draft, stale-workflow-approval). The
suspicious-changes template is intentionally excluded — it is
terse and already directs the contributor to maintainers on
Slack, and adding the footer would dilute the signal.

SKILL.md carries a new Golden rule 8 capturing the requirement
and the link to the rationale anchor.
(cherry picked from commit 0ed3e73)

Co-authored-by: Jarek Potiuk jarek@potiuk.com

[github-actions]

• Add pr-triage skill for maintainer-driven PR queue sweep

A skill-based replacement for the triage mode of breeze pr auto-triage.
Scope is triage only — no LLM code review, no approve/request-changes,
no merging, no TUI.

Shape follows the airflow-translations convention:
.github/skills/pr-triage/ holds the canonical content;
.claude/skills/pr-triage is a committed symlink so Claude Code picks
it up without per-developer setup. .gitignore is updated to let the
symlink through, and the agentic-markdown license hook excludes
SKILL.md entry point so YAML frontmatter can stay at the top.

Also refreshes dev/breeze/doc/images/output_pr_auto-triage.{svg,txt}
— upstream's committed image was stale (boring-cyborg.yml added
labels the committed image hadn't regenerated yet), and the pre-commit
hook regenerates it on every touch of the breeze config.

Generated-by: Claude Opus 4.7 (1M context) following the guidelines
in contributing-docs/05_pull_requests.rst

• pr-triage: add Copilot-review staleness + prefer author-pings

Two rule refinements surfaced while running the skill on
apache/airflow:

1. New classification stale_copilot_review. When a PR has an
   unresolved review thread authored by a Copilot-review bot
   (copilot-pull-request-reviewer[bot] and siblings) and the
   comment is >= 14 days old with no author reply, the skill
   classifies it as stale_copilot_review and suggests draft
   with a new "Unaddressed Copilot review" violation. The
   14-day window is deliberately longer than the 24h/96h CI
   grace — review feedback takes longer to address and a
   two-day nudge would be noisy.

2. Strongly prefer pinging the PR author over the reviewer on
   the ping action. Both comment families (review-nudge for
   stale CHANGES_REQUESTED, reviewer-ping for unresolved
   threads) now document an author-primary default body and a
   reviewer-re-review variant. The reviewer-re-review body is
   only used after an explicit inspection of the post-review
   diff + in-thread replies confirms the feedback has been
   addressed in code or explained away. The previous logic
   (which switched on whether the author had @-mentioned the
   reviewer) put the re-review request on the reviewer's desk
   even when the actual work was still on the author's side.

Updates classify.md, suggested-actions.md, actions.md,
comment-templates.md, SKILL.md, and interaction-loop.md so the
group ordering, data requirements, and body-template decision
are consistent across the skill.

• pr-triage: never suggest rebase on CONFLICTING PRs — route to draft

Empirically every rebase attempted on a PR whose mergeable state
is CONFLICTING came back with "Cannot update PR branch due to
conflicts". GitHub's update-branch endpoint does a side-merge
of the base branch into the PR head; when the merge doesn't
apply cleanly, it refuses, and retrying burns round-trips
without progress. The fix is to stop suggesting rebase in that
state at all — those PRs go straight to draft with the
merge-conflicts violation so the author is pointed at the
local-rebase instructions in the comment body.

• suggested-actions.md: the "mergeable == CONFLICTING" rule now
  maps to draft regardless of other signals. An explicit hard
  rule spells out why.
• actions.md#rebase: a mergeable check runs before the
  update-branch call; if the state is CONFLICTING the action
  refuses with a route-to-draft hint. If a non-CONFLICTING call
  still 422s, the skill does not retry — it falls through to
  draft.
• SKILL.md Step 3 table updated to reflect the new mapping.

• pr-triage: tighten untriaged-draft stale threshold from 3 weeks to 2 weeks

Drafts that have had no activity for 14 days (was 21) now fall into
Sweep 1b (untriaged-draft close). The triaged-draft 7-day threshold
for Sweep 1a is unchanged.

Maintainer preference: two weeks is enough signal that a draft has
stalled; waiting the extra week was leaving queue pressure without
adding useful context on author intent.

• pr-triage: stale-Copilot threshold 14 days -> 7 days, soften body

Two related changes for the stale_copilot_review classification:

• Tighten the trigger threshold. Copilot reviews that sit unaddressed
  for a week already signal a stalled PR — waiting two weeks before
  drafting adds queue pressure without useful signal.

• Revise the draft-comment language to explicitly call out that some
  Copilot suggestions may be incorrect or irrelevant, and that it is
  still the author's responsibility to respond — apply the fix, reply
  in-thread explaining why it does not apply, or resolve the thread
  if the feedback is no longer relevant. Previously the wording could
  be read as 'please do everything Copilot said', which is the wrong
  bar.

• pr-triage: make action_required REST check primary for pending_workflow_approval

A PR that has real CI runs held in action_required for approval
can still report statusCheckRollup.state == SUCCESS, because the
rollup aggregates only completed check-runs and fast bot checks
(Mergeable, WIP, DCO, boring-cyborg) succeed unconditionally
before the real CI is even allowed to start. Trusting the rollup
classifies such a PR as passing and leads to premature mark-ready.

Changes:

• classify.md: rewrite C1 (pending_workflow_approval) so the
  repo-level REST call GET /repos/.../actions/runs?status=action_required
  is the primary signal, not a fallback. Index the response by
  head_sha once per page. Call out that the rollup-based check
  alone is not sufficient and explain why.

• classify.md: rewrite 'Verifying real CI ran' from an optional
  note into a mandatory pre-passing guard. Expand the real-CI
  pattern list to include Tests (exact), CodeQL, and
  'Check newsfragment PR number'.

• fetch-and-batch.md: add an 'Mandatory: action_required run
  index per page' section that documents the REST call as part of
  the per-page fetch plan (one extra round-trip per page, well
  inside the budget).

• pr-triage: spell out author responsibility to mark threads resolved

The Unresolved review comments / Unaddressed Copilot review violation
bodies now explicitly state that it is the author's responsibility to
mark a thread as resolved once they believe it has been addressed —
whether that was by pushing a fix or by replying with an explanation
of why the suggestion doesn't apply.

Reviewers do not auto-close their own threads, so a thread that is
addressed but left unresolved reads as 'still waiting on the author'
and blocks the PR from moving forward. Making this explicit in the
draft comment is the difference between first-time contributors
wondering why their PR still looks blocked after a fix vs. knowing
to click 'Resolve conversation' at the bottom of each thread.

• pr-triage: mandatory pre-check against action_required on mark-ready

Sole purpose of this commit is to add an executable guard in
actions.md that the classifier's real-CI-ran check cannot
substitute for. Empirically, the classifier can still green-light
a PR that has pending workflow approvals if the GraphQL batch
fetch was taken before GitHub indexed a freshly-required workflow
run, or if only the bot subset of checks has completed and the
classifier's 30-context sample missed a real-CI entry.

Changes:

• actions.md §mark-ready: add a MUST-DO pre-mutation check —
  GET /repos///actions/runs?head_sha=&status=
  action_required returning any result is a hard refuse. On
  refuse, reclassify the PR as pending_workflow_approval and
  route accordingly instead of silently dropping the mutation.

• SKILL.md Golden rules: add rule 1b elevating the check to the
  top-of-file contract so a skill implementor can't miss it.
  The rationale (fast bot checks finish first while Tests /
  CodeQL / newsfragment sit in action_required) is spelled out
  so nobody thinks this is belt-and-braces redundancy.

• pr-triage: add AI-attribution footer to contributor comments

Every contributor-facing triage comment now ends with a short
footer that (a) notes the comment was drafted by an AI-assisted
tool and may contain mistakes, (b) reassures the contributor
that a human maintainer will take the next look once they
address the feedback, and (c) links to a new section in the
maintainer-triage contributing doc that explains why the first
pass is automated — to free scarce maintainer time for the
conversation with contributors rather than mechanical queue
sweeping.

The footer is defined once in comment-templates.md as
<ai_attribution_footer> and referenced from every
contributor-facing template (draft, comment-only, close,
review-nudge, reviewer-ping, stale-draft-close,
inactive-to-draft, stale-workflow-approval). The
suspicious-changes template is intentionally excluded — it is
terse and already directs the contributor to maintainers on
Slack, and adding the footer would dilute the signal.

SKILL.md carries a new Golden rule 8 capturing the requirement
and the link to the rationale anchor.
(cherry picked from commit 0ed3e73)

Co-authored-by: Jarek Potiuk jarek@potiuk.com

[github-actions]

• Add pr-triage skill for maintainer-driven PR queue sweep

A skill-based replacement for the triage mode of breeze pr auto-triage.
Scope is triage only — no LLM code review, no approve/request-changes,
no merging, no TUI.

Shape follows the airflow-translations convention:
.github/skills/pr-triage/ holds the canonical content;
.claude/skills/pr-triage is a committed symlink so Claude Code picks
it up without per-developer setup. .gitignore is updated to let the
symlink through, and the agentic-markdown license hook excludes
SKILL.md entry point so YAML frontmatter can stay at the top.

Also refreshes dev/breeze/doc/images/output_pr_auto-triage.{svg,txt}
— upstream's committed image was stale (boring-cyborg.yml added
labels the committed image hadn't regenerated yet), and the pre-commit
hook regenerates it on every touch of the breeze config.

Generated-by: Claude Opus 4.7 (1M context) following the guidelines
in contributing-docs/05_pull_requests.rst

• pr-triage: add Copilot-review staleness + prefer author-pings

Two rule refinements surfaced while running the skill on
apache/airflow:

1. New classification stale_copilot_review. When a PR has an
   unresolved review thread authored by a Copilot-review bot
   (copilot-pull-request-reviewer[bot] and siblings) and the
   comment is >= 14 days old with no author reply, the skill
   classifies it as stale_copilot_review and suggests draft
   with a new "Unaddressed Copilot review" violation. The
   14-day window is deliberately longer than the 24h/96h CI
   grace — review feedback takes longer to address and a
   two-day nudge would be noisy.

2. Strongly prefer pinging the PR author over the reviewer on
   the ping action. Both comment families (review-nudge for
   stale CHANGES_REQUESTED, reviewer-ping for unresolved
   threads) now document an author-primary default body and a
   reviewer-re-review variant. The reviewer-re-review body is
   only used after an explicit inspection of the post-review
   diff + in-thread replies confirms the feedback has been
   addressed in code or explained away. The previous logic
   (which switched on whether the author had @-mentioned the
   reviewer) put the re-review request on the reviewer's desk
   even when the actual work was still on the author's side.

Updates classify.md, suggested-actions.md, actions.md,
comment-templates.md, SKILL.md, and interaction-loop.md so the
group ordering, data requirements, and body-template decision
are consistent across the skill.

• pr-triage: never suggest rebase on CONFLICTING PRs — route to draft

Empirically every rebase attempted on a PR whose mergeable state
is CONFLICTING came back with "Cannot update PR branch due to
conflicts". GitHub's update-branch endpoint does a side-merge
of the base branch into the PR head; when the merge doesn't
apply cleanly, it refuses, and retrying burns round-trips
without progress. The fix is to stop suggesting rebase in that
state at all — those PRs go straight to draft with the
merge-conflicts violation so the author is pointed at the
local-rebase instructions in the comment body.

• suggested-actions.md: the "mergeable == CONFLICTING" rule now
  maps to draft regardless of other signals. An explicit hard
  rule spells out why.
• actions.md#rebase: a mergeable check runs before the
  update-branch call; if the state is CONFLICTING the action
  refuses with a route-to-draft hint. If a non-CONFLICTING call
  still 422s, the skill does not retry — it falls through to
  draft.
• SKILL.md Step 3 table updated to reflect the new mapping.

• pr-triage: tighten untriaged-draft stale threshold from 3 weeks to 2 weeks

Drafts that have had no activity for 14 days (was 21) now fall into
Sweep 1b (untriaged-draft close). The triaged-draft 7-day threshold
for Sweep 1a is unchanged.

Maintainer preference: two weeks is enough signal that a draft has
stalled; waiting the extra week was leaving queue pressure without
adding useful context on author intent.

• pr-triage: stale-Copilot threshold 14 days -> 7 days, soften body

Two related changes for the stale_copilot_review classification:

• Tighten the trigger threshold. Copilot reviews that sit unaddressed
  for a week already signal a stalled PR — waiting two weeks before
  drafting adds queue pressure without useful signal.

• Revise the draft-comment language to explicitly call out that some
  Copilot suggestions may be incorrect or irrelevant, and that it is
  still the author's responsibility to respond — apply the fix, reply
  in-thread explaining why it does not apply, or resolve the thread
  if the feedback is no longer relevant. Previously the wording could
  be read as 'please do everything Copilot said', which is the wrong
  bar.

• pr-triage: make action_required REST check primary for pending_workflow_approval

A PR that has real CI runs held in action_required for approval
can still report statusCheckRollup.state == SUCCESS, because the
rollup aggregates only completed check-runs and fast bot checks
(Mergeable, WIP, DCO, boring-cyborg) succeed unconditionally
before the real CI is even allowed to start. Trusting the rollup
classifies such a PR as passing and leads to premature mark-ready.

Changes:

• classify.md: rewrite C1 (pending_workflow_approval) so the
  repo-level REST call GET /repos/.../actions/runs?status=action_required
  is the primary signal, not a fallback. Index the response by
  head_sha once per page. Call out that the rollup-based check
  alone is not sufficient and explain why.

• classify.md: rewrite 'Verifying real CI ran' from an optional
  note into a mandatory pre-passing guard. Expand the real-CI
  pattern list to include Tests (exact), CodeQL, and
  'Check newsfragment PR number'.

• fetch-and-batch.md: add an 'Mandatory: action_required run
  index per page' section that documents the REST call as part of
  the per-page fetch plan (one extra round-trip per page, well
  inside the budget).

• pr-triage: spell out author responsibility to mark threads resolved

The Unresolved review comments / Unaddressed Copilot review violation
bodies now explicitly state that it is the author's responsibility to
mark a thread as resolved once they believe it has been addressed —
whether that was by pushing a fix or by replying with an explanation
of why the suggestion doesn't apply.

Reviewers do not auto-close their own threads, so a thread that is
addressed but left unresolved reads as 'still waiting on the author'
and blocks the PR from moving forward. Making this explicit in the
draft comment is the difference between first-time contributors
wondering why their PR still looks blocked after a fix vs. knowing
to click 'Resolve conversation' at the bottom of each thread.

• pr-triage: mandatory pre-check against action_required on mark-ready

Sole purpose of this commit is to add an executable guard in
actions.md that the classifier's real-CI-ran check cannot
substitute for. Empirically, the classifier can still green-light
a PR that has pending workflow approvals if the GraphQL batch
fetch was taken before GitHub indexed a freshly-required workflow
run, or if only the bot subset of checks has completed and the
classifier's 30-context sample missed a real-CI entry.

Changes:

• actions.md §mark-ready: add a MUST-DO pre-mutation check —
  GET /repos///actions/runs?head_sha=&status=
  action_required returning any result is a hard refuse. On
  refuse, reclassify the PR as pending_workflow_approval and
  route accordingly instead of silently dropping the mutation.

• SKILL.md Golden rules: add rule 1b elevating the check to the
  top-of-file contract so a skill implementor can't miss it.
  The rationale (fast bot checks finish first while Tests /
  CodeQL / newsfragment sit in action_required) is spelled out
  so nobody thinks this is belt-and-braces redundancy.

• pr-triage: add AI-attribution footer to contributor comments

Every contributor-facing triage comment now ends with a short
footer that (a) notes the comment was drafted by an AI-assisted
tool and may contain mistakes, (b) reassures the contributor
that a human maintainer will take the next look once they
address the feedback, and (c) links to a new section in the
maintainer-triage contributing doc that explains why the first
pass is automated — to free scarce maintainer time for the
conversation with contributors rather than mechanical queue
sweeping.

The footer is defined once in comment-templates.md as
<ai_attribution_footer> and referenced from every
contributor-facing template (draft, comment-only, close,
review-nudge, reviewer-ping, stale-draft-close,
inactive-to-draft, stale-workflow-approval). The
suspicious-changes template is intentionally excluded — it is
terse and already directs the contributor to maintainers on
Slack, and adding the footer would dilute the signal.

SKILL.md carries a new Golden rule 8 capturing the requirement
and the link to the rationale anchor.
(cherry picked from commit 0ed3e73)

Co-authored-by: Jarek Potiuk jarek@potiuk.com

[github-actions]

• Add pr-triage skill for maintainer-driven PR queue sweep

A skill-based replacement for the triage mode of breeze pr auto-triage.
Scope is triage only — no LLM code review, no approve/request-changes,
no merging, no TUI.

Shape follows the airflow-translations convention:
.github/skills/pr-triage/ holds the canonical content;
.claude/skills/pr-triage is a committed symlink so Claude Code picks
it up without per-developer setup. .gitignore is updated to let the
symlink through, and the agentic-markdown license hook excludes
SKILL.md entry point so YAML frontmatter can stay at the top.

Also refreshes dev/breeze/doc/images/output_pr_auto-triage.{svg,txt}
— upstream's committed image was stale (boring-cyborg.yml added
labels the committed image hadn't regenerated yet), and the pre-commit
hook regenerates it on every touch of the breeze config.

Generated-by: Claude Opus 4.7 (1M context) following the guidelines
in contributing-docs/05_pull_requests.rst

• pr-triage: add Copilot-review staleness + prefer author-pings

Two rule refinements surfaced while running the skill on
apache/airflow:

1. New classification stale_copilot_review. When a PR has an
   unresolved review thread authored by a Copilot-review bot
   (copilot-pull-request-reviewer[bot] and siblings) and the
   comment is >= 14 days old with no author reply, the skill
   classifies it as stale_copilot_review and suggests draft
   with a new "Unaddressed Copilot review" violation. The
   14-day window is deliberately longer than the 24h/96h CI
   grace — review feedback takes longer to address and a
   two-day nudge would be noisy.

2. Strongly prefer pinging the PR author over the reviewer on
   the ping action. Both comment families (review-nudge for
   stale CHANGES_REQUESTED, reviewer-ping for unresolved
   threads) now document an author-primary default body and a
   reviewer-re-review variant. The reviewer-re-review body is
   only used after an explicit inspection of the post-review
   diff + in-thread replies confirms the feedback has been
   addressed in code or explained away. The previous logic
   (which switched on whether the author had @-mentioned the
   reviewer) put the re-review request on the reviewer's desk
   even when the actual work was still on the author's side.

Updates classify.md, suggested-actions.md, actions.md,
comment-templates.md, SKILL.md, and interaction-loop.md so the
group ordering, data requirements, and body-template decision
are consistent across the skill.

• pr-triage: never suggest rebase on CONFLICTING PRs — route to draft

Empirically every rebase attempted on a PR whose mergeable state
is CONFLICTING came back with "Cannot update PR branch due to
conflicts". GitHub's update-branch endpoint does a side-merge
of the base branch into the PR head; when the merge doesn't
apply cleanly, it refuses, and retrying burns round-trips
without progress. The fix is to stop suggesting rebase in that
state at all — those PRs go straight to draft with the
merge-conflicts violation so the author is pointed at the
local-rebase instructions in the comment body.

• suggested-actions.md: the "mergeable == CONFLICTING" rule now
  maps to draft regardless of other signals. An explicit hard
  rule spells out why.
• actions.md#rebase: a mergeable check runs before the
  update-branch call; if the state is CONFLICTING the action
  refuses with a route-to-draft hint. If a non-CONFLICTING call
  still 422s, the skill does not retry — it falls through to
  draft.
• SKILL.md Step 3 table updated to reflect the new mapping.

• pr-triage: tighten untriaged-draft stale threshold from 3 weeks to 2 weeks

Drafts that have had no activity for 14 days (was 21) now fall into
Sweep 1b (untriaged-draft close). The triaged-draft 7-day threshold
for Sweep 1a is unchanged.

Maintainer preference: two weeks is enough signal that a draft has
stalled; waiting the extra week was leaving queue pressure without
adding useful context on author intent.

• pr-triage: stale-Copilot threshold 14 days -> 7 days, soften body

Two related changes for the stale_copilot_review classification:

• Tighten the trigger threshold. Copilot reviews that sit unaddressed
  for a week already signal a stalled PR — waiting two weeks before
  drafting adds queue pressure without useful signal.

• Revise the draft-comment language to explicitly call out that some
  Copilot suggestions may be incorrect or irrelevant, and that it is
  still the author's responsibility to respond — apply the fix, reply
  in-thread explaining why it does not apply, or resolve the thread
  if the feedback is no longer relevant. Previously the wording could
  be read as 'please do everything Copilot said', which is the wrong
  bar.

• pr-triage: make action_required REST check primary for pending_workflow_approval

A PR that has real CI runs held in action_required for approval
can still report statusCheckRollup.state == SUCCESS, because the
rollup aggregates only completed check-runs and fast bot checks
(Mergeable, WIP, DCO, boring-cyborg) succeed unconditionally
before the real CI is even allowed to start. Trusting the rollup
classifies such a PR as passing and leads to premature mark-ready.

Changes:

• classify.md: rewrite C1 (pending_workflow_approval) so the
  repo-level REST call GET /repos/.../actions/runs?status=action_required
  is the primary signal, not a fallback. Index the response by
  head_sha once per page. Call out that the rollup-based check
  alone is not sufficient and explain why.

• classify.md: rewrite 'Verifying real CI ran' from an optional
  note into a mandatory pre-passing guard. Expand the real-CI
  pattern list to include Tests (exact), CodeQL, and
  'Check newsfragment PR number'.

• fetch-and-batch.md: add an 'Mandatory: action_required run
  index per page' section that documents the REST call as part of
  the per-page fetch plan (one extra round-trip per page, well
  inside the budget).

• pr-triage: spell out author responsibility to mark threads resolved

The Unresolved review comments / Unaddressed Copilot review violation
bodies now explicitly state that it is the author's responsibility to
mark a thread as resolved once they believe it has been addressed —
whether that was by pushing a fix or by replying with an explanation
of why the suggestion doesn't apply.

Reviewers do not auto-close their own threads, so a thread that is
addressed but left unresolved reads as 'still waiting on the author'
and blocks the PR from moving forward. Making this explicit in the
draft comment is the difference between first-time contributors
wondering why their PR still looks blocked after a fix vs. knowing
to click 'Resolve conversation' at the bottom of each thread.

• pr-triage: mandatory pre-check against action_required on mark-ready

Sole purpose of this commit is to add an executable guard in
actions.md that the classifier's real-CI-ran check cannot
substitute for. Empirically, the classifier can still green-light
a PR that has pending workflow approvals if the GraphQL batch
fetch was taken before GitHub indexed a freshly-required workflow
run, or if only the bot subset of checks has completed and the
classifier's 30-context sample missed a real-CI entry.

Changes:

• actions.md §mark-ready: add a MUST-DO pre-mutation check —
  GET /repos///actions/runs?head_sha=&status=
  action_required returning any result is a hard refuse. On
  refuse, reclassify the PR as pending_workflow_approval and
  route accordingly instead of silently dropping the mutation.

• SKILL.md Golden rules: add rule 1b elevating the check to the
  top-of-file contract so a skill implementor can't miss it.
  The rationale (fast bot checks finish first while Tests /
  CodeQL / newsfragment sit in action_required) is spelled out
  so nobody thinks this is belt-and-braces redundancy.

• pr-triage: add AI-attribution footer to contributor comments

Every contributor-facing triage comment now ends with a short
footer that (a) notes the comment was drafted by an AI-assisted
tool and may contain mistakes, (b) reassures the contributor
that a human maintainer will take the next look once they
address the feedback, and (c) links to a new section in the
maintainer-triage contributing doc that explains why the first
pass is automated — to free scarce maintainer time for the
conversation with contributors rather than mechanical queue
sweeping.

The footer is defined once in comment-templates.md as
<ai_attribution_footer> and referenced from every
contributor-facing template (draft, comment-only, close,
review-nudge, reviewer-ping, stale-draft-close,
inactive-to-draft, stale-workflow-approval). The
suspicious-changes template is intentionally excluded — it is
terse and already directs the contributor to maintainers on
Slack, and adding the footer would dilute the signal.

SKILL.md carries a new Golden rule 8 capturing the requirement
and the link to the rationale anchor.
(cherry picked from commit 0ed3e73)

Co-authored-by: Jarek Potiuk jarek@potiuk.com

[github-actions]

• Add pr-triage skill for maintainer-driven PR queue sweep

A skill-based replacement for the triage mode of breeze pr auto-triage.
Scope is triage only — no LLM code review, no approve/request-changes,
no merging, no TUI.

Shape follows the airflow-translations convention:
.github/skills/pr-triage/ holds the canonical content;
.claude/skills/pr-triage is a committed symlink so Claude Code picks
it up without per-developer setup. .gitignore is updated to let the
symlink through, and the agentic-markdown license hook excludes
SKILL.md entry point so YAML frontmatter can stay at the top.

Also refreshes dev/breeze/doc/images/output_pr_auto-triage.{svg,txt}
— upstream's committed image was stale (boring-cyborg.yml added
labels the committed image hadn't regenerated yet), and the pre-commit
hook regenerates it on every touch of the breeze config.

Generated-by: Claude Opus 4.7 (1M context) following the guidelines
in contributing-docs/05_pull_requests.rst

• pr-triage: add Copilot-review staleness + prefer author-pings

Two rule refinements surfaced while running the skill on
apache/airflow:

1. New classification stale_copilot_review. When a PR has an
   unresolved review thread authored by a Copilot-review bot
   (copilot-pull-request-reviewer[bot] and siblings) and the
   comment is >= 14 days old with no author reply, the skill
   classifies it as stale_copilot_review and suggests draft
   with a new "Unaddressed Copilot review" violation. The
   14-day window is deliberately longer than the 24h/96h CI
   grace — review feedback takes longer to address and a
   two-day nudge would be noisy.

2. Strongly prefer pinging the PR author over the reviewer on
   the ping action. Both comment families (review-nudge for
   stale CHANGES_REQUESTED, reviewer-ping for unresolved
   threads) now document an author-primary default body and a
   reviewer-re-review variant. The reviewer-re-review body is
   only used after an explicit inspection of the post-review
   diff + in-thread replies confirms the feedback has been
   addressed in code or explained away. The previous logic
   (which switched on whether the author had @-mentioned the
   reviewer) put the re-review request on the reviewer's desk
   even when the actual work was still on the author's side.

Updates classify.md, suggested-actions.md, actions.md,
comment-templates.md, SKILL.md, and interaction-loop.md so the
group ordering, data requirements, and body-template decision
are consistent across the skill.

• pr-triage: never suggest rebase on CONFLICTING PRs — route to draft

Empirically every rebase attempted on a PR whose mergeable state
is CONFLICTING came back with "Cannot update PR branch due to
conflicts". GitHub's update-branch endpoint does a side-merge
of the base branch into the PR head; when the merge doesn't
apply cleanly, it refuses, and retrying burns round-trips
without progress. The fix is to stop suggesting rebase in that
state at all — those PRs go straight to draft with the
merge-conflicts violation so the author is pointed at the
local-rebase instructions in the comment body.

• suggested-actions.md: the "mergeable == CONFLICTING" rule now
  maps to draft regardless of other signals. An explicit hard
  rule spells out why.
• actions.md#rebase: a mergeable check runs before the
  update-branch call; if the state is CONFLICTING the action
  refuses with a route-to-draft hint. If a non-CONFLICTING call
  still 422s, the skill does not retry — it falls through to
  draft.
• SKILL.md Step 3 table updated to reflect the new mapping.

• pr-triage: tighten untriaged-draft stale threshold from 3 weeks to 2 weeks

Drafts that have had no activity for 14 days (was 21) now fall into
Sweep 1b (untriaged-draft close). The triaged-draft 7-day threshold
for Sweep 1a is unchanged.

Maintainer preference: two weeks is enough signal that a draft has
stalled; waiting the extra week was leaving queue pressure without
adding useful context on author intent.

• pr-triage: stale-Copilot threshold 14 days -> 7 days, soften body

Two related changes for the stale_copilot_review classification:

• Tighten the trigger threshold. Copilot reviews that sit unaddressed
  for a week already signal a stalled PR — waiting two weeks before
  drafting adds queue pressure without useful signal.

• Revise the draft-comment language to explicitly call out that some
  Copilot suggestions may be incorrect or irrelevant, and that it is
  still the author's responsibility to respond — apply the fix, reply
  in-thread explaining why it does not apply, or resolve the thread
  if the feedback is no longer relevant. Previously the wording could
  be read as 'please do everything Copilot said', which is the wrong
  bar.

• pr-triage: make action_required REST check primary for pending_workflow_approval

A PR that has real CI runs held in action_required for approval
can still report statusCheckRollup.state == SUCCESS, because the
rollup aggregates only completed check-runs and fast bot checks
(Mergeable, WIP, DCO, boring-cyborg) succeed unconditionally
before the real CI is even allowed to start. Trusting the rollup
classifies such a PR as passing and leads to premature mark-ready.

Changes:

• classify.md: rewrite C1 (pending_workflow_approval) so the
  repo-level REST call GET /repos/.../actions/runs?status=action_required
  is the primary signal, not a fallback. Index the response by
  head_sha once per page. Call out that the rollup-based check
  alone is not sufficient and explain why.

• classify.md: rewrite 'Verifying real CI ran' from an optional
  note into a mandatory pre-passing guard. Expand the real-CI
  pattern list to include Tests (exact), CodeQL, and
  'Check newsfragment PR number'.

• fetch-and-batch.md: add an 'Mandatory: action_required run
  index per page' section that documents the REST call as part of
  the per-page fetch plan (one extra round-trip per page, well
  inside the budget).

• pr-triage: spell out author responsibility to mark threads resolved

The Unresolved review comments / Unaddressed Copilot review violation
bodies now explicitly state that it is the author's responsibility to
mark a thread as resolved once they believe it has been addressed —
whether that was by pushing a fix or by replying with an explanation
of why the suggestion doesn't apply.

Reviewers do not auto-close their own threads, so a thread that is
addressed but left unresolved reads as 'still waiting on the author'
and blocks the PR from moving forward. Making this explicit in the
draft comment is the difference between first-time contributors
wondering why their PR still looks blocked after a fix vs. knowing
to click 'Resolve conversation' at the bottom of each thread.

• pr-triage: mandatory pre-check against action_required on mark-ready

Sole purpose of this commit is to add an executable guard in
actions.md that the classifier's real-CI-ran check cannot
substitute for. Empirically, the classifier can still green-light
a PR that has pending workflow approvals if the GraphQL batch
fetch was taken before GitHub indexed a freshly-required workflow
run, or if only the bot subset of checks has completed and the
classifier's 30-context sample missed a real-CI entry.

Changes:

• actions.md §mark-ready: add a MUST-DO pre-mutation check —
  GET /repos///actions/runs?head_sha=&status=
  action_required returning any result is a hard refuse. On
  refuse, reclassify the PR as pending_workflow_approval and
  route accordingly instead of silently dropping the mutation.

• SKILL.md Golden rules: add rule 1b elevating the check to the
  top-of-file contract so a skill implementor can't miss it.
  The rationale (fast bot checks finish first while Tests /
  CodeQL / newsfragment sit in action_required) is spelled out
  so nobody thinks this is belt-and-braces redundancy.

• pr-triage: add AI-attribution footer to contributor comments

Every contributor-facing triage comment now ends with a short
footer that (a) notes the comment was drafted by an AI-assisted
tool and may contain mistakes, (b) reassures the contributor
that a human maintainer will take the next look once they
address the feedback, and (c) links to a new section in the
maintainer-triage contributing doc that explains why the first
pass is automated — to free scarce maintainer time for the
conversation with contributors rather than mechanical queue
sweeping.

The footer is defined once in comment-templates.md as
<ai_attribution_footer> and referenced from every
contributor-facing template (draft, comment-only, close,
review-nudge, reviewer-ping, stale-draft-close,
inactive-to-draft, stale-workflow-approval). The
suspicious-changes template is intentionally excluded — it is
terse and already directs the contributor to maintainers on
Slack, and adding the footer would dilute the signal.

SKILL.md carries a new Golden rule 8 capturing the requirement
and the link to the rationale anchor.
(cherry picked from commit 0ed3e73)

Co-authored-by: Jarek Potiuk jarek@potiuk.com