chore: add workflow for stale prs and issue type bug

[MatteoGabriele]

🧭 Context

We need an automated system to manage stale issues and PRs to keep the project clean. ✨
We have decided to focus only on "Bug" issues, as they typically have a shorter lifespan, along with all PRs. These will be tagged and then automatically closed.

📚 Description

These changes add the built-in GitHub stale action to automate the entire stale-tagging process and auto-close.
Issues of type "Bug" and PRs will be tagged after 30 days of inactivity and then automatically closed 7 days later.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Apr 19, 2026 0:13am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Apr 19, 2026 0:13am
npmx-lunaria	Ignored		Apr 19, 2026 0:13am

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Chores
  • Implemented automated workflow to manage inactive issues and pull requests, marking them after 30 days of inactivity and closing them after a further 7 days of no updates.

Walkthrough

Adds a new GitHub Actions workflow "Stale Issues and PRs" that runs daily (02:00 UTC) or manually, marking issues and pull requests stale after 30 days and closing them after a further 7 days, with separate jobs for bug issues and PRs and an operations cap of 500 per job.

Changes

Cohort / File(s)	Summary
Stale workflow automation \.github/workflows/stale.yml	Adds Stale Issues and PRs workflow (scheduled + workflow_dispatch) with repository issues: write and pull-requests: write permissions. Defines two jobs: stale-bugs (targets issues with bug type) and stale-prs (targets pull requests); both use actions/stale with 30-day stale, 7-day close, and operations-per-run: 500.

Possibly related PRs

• chore: remove stale bot #2566 — Directly related: removes a previous stale workflow file that implemented similar stale-marking/closing behaviour.
• chore: increase operation per run in stale workflow #2564 — Related: adjusts the operations-per-run setting for the same actions/stale workflow.
• feat: add stale workflow #2555 — Related: adds a stale workflow using actions/stale with similar triggers and goals but different structure/parameters.

Suggested reviewers

• patak-cat
• graphieros
• 43081j

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarises the main change: adding a workflow for managing stale PRs and bug-type issues.
Description check	✅ Passed	The description is directly related to the changeset, providing clear context, objectives, and implementation details about the stale workflow automation.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/stale.yml:
- Around line 17-37: The stale workflow is unintentionally processing the
opposite item type because the action defaults unset PR/issue params to 60 days;
update the job that targets issues to disable PR handling by setting
days-before-pr-stale: -1 and days-before-pr-close: -1, and update the stale-prs
job to disable issue handling by setting days-before-issue-stale: -1 and
days-before-issue-close: -1 so each job only processes its intended item type
(refer to the input names days-before-pr-stale, days-before-pr-close,
days-before-issue-stale, days-before-issue-close and the job identifier
stale-prs).

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 93b28aff-d8ef-4837-80ed-03bfa49e2d76

📥 Commits

Reviewing files that changed from the base of the PR and between 5f30d25 and 2ac53f2.

📒 Files selected for processing (1)

• .github/workflows/stale.yml

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/stale.yml (1)

25-26: Using the same label for stale-*-label and close-*-label is unusual.

Both stale-issue-label and close-issue-label (and likewise for PRs) are set to 'stale'. The close-*-label is applied when the item is closed by the action, so reusing the stale label makes it impossible to distinguish items that were auto-closed from those merely marked stale. Consider a distinct label such as 'closed-stale', or omit close-*-label entirely if no close-time label is desired.

Also applies to: 39-40

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/stale.yml around lines 25 - 26, The workflow currently
sets the same label for stale and closed items (stale-issue-label and
close-issue-label, and likewise stale-pr-label and close-pr-label), which
prevents distinguishing auto-closed items from merely marked stale; update the
action config by giving close-issue-label and close-pr-label a distinct label
(e.g., 'closed-stale') or remove the close-*-label entries entirely if you don't
want a close-time label, making sure to update the values for stale-issue-label,
close-issue-label, stale-pr-label, and close-pr-label accordingly.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In @.github/workflows/stale.yml:
- Around line 25-26: The workflow currently sets the same label for stale and
closed items (stale-issue-label and close-issue-label, and likewise
stale-pr-label and close-pr-label), which prevents distinguishing auto-closed
items from merely marked stale; update the action config by giving
close-issue-label and close-pr-label a distinct label (e.g., 'closed-stale') or
remove the close-*-label entries entirely if you don't want a close-time label,
making sure to update the values for stale-issue-label, close-issue-label,
stale-pr-label, and close-pr-label accordingly.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: bad684d4-53e1-4144-a3b5-031a50905922

📥 Commits

Reviewing files that changed from the base of the PR and between 2ac53f2 and 3c12eee.

📒 Files selected for processing (1)

• .github/workflows/stale.yml

[patak-cat]

Leaving trace here of what I said in the chat, too, that my personal preference is to only do this for PRs (I would probably have 3 months instead of 1), and in the case of bugs only add the stale label but avoid the comment and auto-close.

But I'm not doing a lot in the repo side, so I'll let you decide what works best for you. Thanks for modifying the previous version @MatteoGabriele! It is great that features are left untouched 🙏🏼

[MatteoGabriele]

@patak-cat We're not going to leave any comments at any stage: this is just a stale tag after 1 month, then it closes after another 7 days, and it's always possible to reopen, obviously.
All that's needed to unstale is a comment or actual work being done. A healthy PR or an urgent bug cannot be left untouched for 37 days and still be considered relevant, at least for the time being. Later on, perhaps we could increase the days if we think we're slowing down.