Fold "Close Stale PRs" into a deterministic pr-triage stale sweep

[JanKrivanek]

What & why

Fixes #915.

The agentic close-stale-prs.agent.md was unreliable at actually closing stale PRs and spent tokens on work that is fully deterministic. This PR extracts and preserves that behavior as a deterministic stale-PR sweep folded into the existing pr-triage workflow family, and deletes the agentic workflow.

Changes

• New .github/scripts/pr-stale-sweep.sh — deterministic port of the stale policy (no model calls, no tokens):
  • Considers every open PR, including drafts.
  • "Last activity" = most recent non-bot comment/review; falls back to created_at. updated_at and all [bot] activity are ignored so the bot's own warning never resets the timer.
  • created ≤ 30 days → skip (too new)
  • 30 < inactivity ≤ 37 days → post a stale warning (once; guarded by a <!-- pr-triage:stale-warning --> marker)
  • inactivity > 37 days → close with a closing comment
  • Exempt: no-stale label; authors dotnet-maestro[bot] / dotnet-maestro
  • DRY_RUN and STALE_MAX (default 25) supported
• .github/workflows/pr-triage-batch.yml — hosts the new stale-sweep job:
  • Weekly cron 17 4 * * 1 (plus the existing hourly triage cron)
  • workflow_dispatch inputs stale_sweep / stale_max for manual runs
  • Job-scoped pull-requests: write + issues: write permissions
• Deleted close-stale-prs.agent.md and its compiled close-stale-prs.agent.lock.yml
• Updated docs/design/pr-triage-workflows.md (new "Stale-PR sweep" section, diagram, no-stale note)

Why fold into pr-triage-batch.yml (not a new workflow)

pr-triage-batch.yml is the scheduled orchestrator and already exists on main with workflow_dispatch, so the sweep can be dispatched against this feature branch before merge for validation. A brand-new workflow file cannot be dispatched until it lands on the default branch.

Validation

• actionlint -shellcheck= -pyflakes= passes on pr-triage-batch.yml.
• bash -n passes on pr-stale-sweep.sh.

A live dry-run/real run against this repo and a sample closed PR will be linked in a follow-up comment.

Note

The stale_sweep / stale_max dispatch inputs are permanent (they're how the sweep is manually run), and they also serve as the trigger used to validate this PR from the branch.

[JanKrivanek]

Live validation (dry-run)

I dispatched the new stale-sweep job against this PR branch to observe the deterministic logic on real repo data, in dry-run mode (no writes):

Run: https://github.com/dotnet/skills/actions/runs/29899244455 — PR triage batch — stale sweep [dry-run], conclusion success.

What it decided (18 open PRs evaluated):

PR	inactivity (non-bot)	decision
#753	33 days	warn (30 < inactivity ≤ 37)
#329	27 days	skip (active, < 30d)
all others	created ≤ 30 days ago	skip (too new)

This exercises the warn threshold and the exemption/too-new filters. Per @JanKrivanek's guidance I did not post to any community PR, so this was dry-run only. No open PR currently exceeds the 37-day close threshold, so the close path had no live target today.

Sample of a real stale close

The close behavior this PR ports is the same one the (now-removed) agentic workflow performed. A recent real example is #244, auto-closed by github-actions[bot] on 2026-07-20 with exactly the closing comment this script reproduces:

• [dotnet-ai] Agent stack (agentic-workflow + copilot-sdk-integration) #244 — "This pull request has been automatically closed because it has been open for more than 30 days with no recent activity."

(Other historical stale closes by the old bot: #263, #610.)

Notes

• The stale_sweep / stale_max workflow_dispatch inputs are permanent — they are the manual entry point for the sweep (and are what enabled this dry-run from the branch). There is no temporary scaffolding to remove.
• actionlint (workflow) and bash -n (script) both pass.

[Copilot]

Pull request overview

This PR replaces the agentic “close stale PRs” workflow with a deterministic stale-PR sweep integrated into the existing pr-triage-batch.yml orchestrator, reducing unreliability and eliminating model/token usage for a fully deterministic policy.

Changes:

• Added a deterministic stale-PR sweep script and a weekly/manual stale-sweep job in pr-triage-batch.yml.
• Removed the legacy agentic stale-PR workflows (close-stale-prs.agent.*).
• Updated PR triage design docs to document the new stale-sweep policy and triggers.

Show a summary per file

File	Description
docs/design/pr-triage-workflows.md	Documents the new stale-sweep job, its policy, and how no-stale is honored.
.github/workflows/pr-triage-batch.yml	Adds a weekly cron + dispatch option and a stale-sweep job to run the deterministic sweep.
.github/workflows/close-stale-prs.agent.md	Deleted legacy agentic stale PR workflow definition.
.github/workflows/close-stale-prs.agent.lock.yml	Deleted compiled lock workflow for the legacy agentic stale PR workflow.
.github/scripts/pr-stale-sweep.sh	New deterministic stale warning/close implementation using GitHub API via gh.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 4/5 changed files
• Comments generated: 2

[github-actions]

👋 @JanKrivanek — this PR has 2 unresolved review thread(s). When you're ready, please address the feedback and push an update; the triage bot will pick up the next state automatically. (Add the no-stale label to silence further pings.)

[Evangelink]

Requesting changes because the destructive path currently fails open when activity reads fail, and the write cap can starve the stalest closures behind newer warnings. I reproduced both cases against this exact script. The existing 500-item enumeration-cap thread is also valid. I separately checked inline review replies on this repository: each reply produced a COMMENTED review with the same submitted_at, so that existing thread does not appear to be a blocker.

[JanKrivanek]

Review round addressed (commit 9f81276)

Reworked .github/scripts/pr-stale-sweep.sh to resolve all four review findings; each inline thread has a reply and is resolved.

• Fail-safe reads (Evangelink, blocking): last_non_bot_activity_epoch now returns non-zero if any of the three activity reads fails; the caller skips that PR (activity read failed — skipping) instead of falling back to created_at and risking a wrongful close.
• Sort-before-cap (Evangelink, blocking): two-phase design — collect every eligible PR, sort by inactivity descending (stalest first), then apply STALE_MAX. Closures can no longer be starved by newer warnings.
• Full pagination (Copilot): enumeration uses gh api --paginate repos/$REPO/pulls?state=open&per_page=100 (no 500 cap).
• Inline review comments (Copilot): pulls/{pr}/comments is now a third non-bot activity source, so a human who only leaves code-review comments isn't treated as inactive.

Verification

• Behavioral test harness (fake gh, real jq): 12/12 assertions pass — fail-safe skip, closure-beats-warning under STALE_MAX=1, review-comment-only PR classified warn, plus no-stale/maestro exemptions, too-new, and already-warned guards.
• Live dry-run on this branch: run 29942733430 → open PRs fetched: 19 (read-error skips: 0); adding scaffolding skill and test #329 → skip(active); dotnet-fsharp: Adding Basic F# Skills #753 → would warn (34d inactive); no wrongful closes.

actionlint is green on pr-triage-batch.yml.

[Copilot]

Copilot's findings

• Files reviewed: 4/5 changed files
• Comments generated: 3

[JanKrivanek]

Re-review round addressed (commit 3a3c9b9)

Three follow-up comments from the Copilot re-review are fixed, replied to, and resolved:

• Numeric input validation (pr-stale-sweep.sh): STALE_MAX/WARN_DAYS/CLOSE_DAYS are now validated as integers with CLOSE_DAYS > WARN_DAYS, failing fast with a clear ::error:: instead of an opaque arithmetic error on a bad manual dispatch.
• Concurrency isolation (pr-triage-batch.yml): the weekly stale sweep now uses its own concurrency group, so it and the hourly orchestrator don't block/queue each other when their crons overlap (Mon 04:17).
• Doc accuracy (pr-triage-workflows.md): corrected — the orchestrator does post a one-time idempotency-marker comment when dispatching the malicious-code scanner.

Verified: bash -n clean, both bad-input cases exit 2, behavioral harness still 12/12, actionlint green, and all CI checks pass on the new head.

All review threads (7/7) are now resolved. @Evangelink — the two blocking items from your review were addressed in the prior round (9f81276); whenever you have a moment, a re-review to clear the changes-requested gate would be appreciated. Thanks!

[Copilot]

Copilot's findings

• Files reviewed: 4/5 changed files
• Comments generated: 0 new