b2f642a468 chore: auto-close external PRs that skip triage or the PR template (#10866)
## Summary

Tightens the contribution policy for external PRs, modeled on [MLflow's
`auto-close-pr`
workflow](https://github.com/mlflow/mlflow/blob/master/.github/workflows/auto-close-pr.js).
External PRs now need a linked issue that a maintainer has triaged with
a `ready` label, and must keep the PR template. This cuts down on
unsolicited and low-effort AI-generated PRs: work only starts once a
maintainer has agreed the issue is worth doing.

Everything lives in the existing `PR Triage` workflow
(`.github/workflows/pr-triage.yml`).

**New auto-close rules (external contributors only)**

| Rule | Label | Closes when |
|---|---|---|
| No linked issue | `missing-issue-link` | The PR doesn't close any
issue. Previously label-only; now closes regardless of PR size |
| Issue not triaged | `issue-not-ready` | Any linked issue lacks the
`ready` label |
| PR template not followed | `template-not-followed` | More than half of
the template's headings are missing from the body. With the current 5
headings, 3 or more missing closes the PR |
| Duplicate / assigned (existing) | `possible-duplicate`,
`issue-assigned-to-other` | Unchanged, except duplicates now only count
*earlier* open PRs |

The close comment lists every finding, names the reasons, and tells the
contributor to address them and reopen. It also asks them not to delete
or force-push the branch, because a force-pushed branch can't be
reopened.

**Grandfathering**

A `CUTOFF_DATE` constant, set to 7 October 2026
(`2026-10-07T00:00:00Z`), keeps the new rules away from in-flight work:
- The `ready` check only applies to issues created on or after the
cutoff.
- The missing-issue and template closes only apply to PRs created on or
after the cutoff. Older PRs still get the label but stay open.

**Reopen flow**
- The workflow now runs on `reopened` as well as `opened`. When a
maintainer later labels the issue `ready`, the contributor reopens the
PR and it passes. No extra comment is posted when a reopened PR passes.
- If a maintainer reopens a PR, all checks are skipped. A sender with
`admin`, `maintain` or `write` permission can always override an
auto-close.

**Exemptions**

All checks are skipped for:
- bots, e.g. Dependabot, which would otherwise be closed for having no
issue
- authors with `OWNER`, `MEMBER` or `COLLABORATOR` association
- authors with write access, which covers org members with private
membership

**Other changes in `pr-triage.yml`**
- Linked issues come from GraphQL `closingIssuesReferences` instead of
regex. It covers `Fixes/Closes/Resolves #N`, full issue URLs and
sidebar-linked issues. A bare `#123` or `see #5` no longer counts as a
link.
- The assignee check reuses the same GraphQL result, which removes one
REST call per issue.
- Template headings are read from the base branch's
`.github/pull_request_template.md`, so the check stays in sync when the
template changes.
- If the linked-issue lookup or the template fetch fails, that check is
skipped, so a transient API error never closes a PR.

**Docs**
- `.github/pull_request_template.md`: the issue line now says external
contributors must use `Fixes #<issue_number>` and that the issue needs
the `ready` label.
- `CONTRIBUTING.md`: "Link to Issue" became "Link to a Ready Issue",
which explains the triage flow and the reopen steps. Added a "Use the PR
Template" rule.

## Type of change

- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [x] Improvement
- [ ] Model update
- [x] Other: CI / contribution policy

---

## Checklist

- [ ] Code complies with style guidelines
- [ ] Ran format/validation scripts (`./scripts/format.sh` and
`./scripts/validate.sh`)
- [ ] Self-review completed
- [x] Documentation updated (comments, docstrings)
- [ ] Examples and guides: Relevant cookbook examples have been included
or updated (if applicable)
- [ ] Tested in clean environment
- [ ] Tests added/updated (if applicable)

### Duplicate and AI-Generated PR Check

- [x] I have searched existing [open pull
requests](https://github.com/agno-agi/agno/pulls) and confirmed that no
other PR already addresses this issue
- [ ] If a similar PR exists, I have explained below why this PR is a
better approach
- [x] Check if this PR was entirely AI-generated (by Copilot, Claude
Code, Cursor, etc.)

---

## Additional Notes

**Before merging**
1. Create the label: `gh label create ready -R agno-agi/agno -c 0E8A16
-d "Triaged by a maintainer; open for PRs"`. The other labels
(`issue-not-ready`, `template-not-followed`) are created automatically
the first time they're applied.
2. Make sure maintainers know that outside issues now need a `ready`
label before contributors can open PRs for them. If triage falls behind,
good contributions will stall.

**Testing**

`pull_request_target` runs the workflow from the base branch, so this PR
can't test itself. I extracted the script and ran it against mocked
GitHub API calls in 18 scenarios, and all of them behaved as expected:
- External PR with no issue: closed. A pre-cutoff PR reopened with no
issue: label only.
- New issue without `ready`: closed. With `ready`: passes. Pre-cutoff
issue without the label: passes.
- `ready` issue assigned to someone else, or claimed by an earlier open
PR: closed. Claimed by a *later* PR: passes.
- Author reopens while the issue is still not ready: closed again. After
the issue is marked `ready`: passes with no comment.
- Maintainer reopens: all checks skipped.
- Template stripped, or 3 of 5 headings missing: closed. 2 of 5 missing:
passes. Pre-cutoff PR: label only.
- Org member or bot with no issue and no template: passes.

An end-to-end run on a fork before or after merge is still worthwhile.
The format and validate scripts don't apply because no Python files
changed.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Harsh <[email protected]>
Co-authored-by: Yash Pratap Solanky <[email protected]>
2026-10-08 00:02:10 +05:30
2026-08-24 18:19:42 +05:30
2024-02-12 21:05:49 +00:00
2026-08-24 18:19:42 +05:30
2025-09-09 15:39:09 +02:00
2025-01-30 20:50:59 +05:30
2026-07-14 22:55:34 +01:00

Build, run, and manage agent platforms.

Introduction

Agno is a framework and runtime for agent platforms. Build agents, run them as a service, manage your platform using a web UI.

  • Build your agent platform using the Agno SDK.
  • Run your agent platform using the AgentOS runtime.
  • Manage everything using the AgentOS UI.

Agno allows you to own your agent stack. Maintain control of your data, memory, and security posture (JWT-based RBAC), and turn your agent platform into a learning loop with simulations and usage data.

demo-os

Get started

Hand this prompt to your coding agent (Claude Code, Cursor, Codex):

Help me set up my agent platform.

Clone https://github.com/agno-agi/agentos-railway into a folder called
agent-platform, cd in, read the README, and follow the get started guide.

Your coding agent will set up your agent platform and run it locally using Docker, giving you a REST API for serving your agents, a Postgres database for storing your data and traces, an MCP server, and a control plane.

Deploying somewhere else? Use the same prompt but point it to a different repo. The starter templates are identical except for the deploy scripts: swap agentos-railway for agentos-docker, agentos-aws, agentos-gcp, agentos-azure, agentos-fly, agentos-render, agentos-modal, or agentos-helm.

Prefer to code by hand?

Features

  • Production API. 50+ endpoints with SSE and websockets to build a product on top.
  • Storage. Store sessions, memory, knowledge, and traces in your own database.
  • 100+ integrations. Connect to GitHub, Slack, Postgres, and more using pre-built toolkits.
  • Context Providers. Access live data from Slack, Drive, wikis, MCP, and custom sources.
  • Human approval. Pause runs for user confirmation. Block tools that require admin approval.
  • Observability. Monitor with OpenTelemetry tracing, run history, and audit logs.
  • Security. Get JWT-based RBAC and multi-user, multi-tenant isolation out of the box.
  • Interfaces. Expose your agents via Slack, Telegram, WhatsApp, Discord, AG-UI, A2A.
  • Scheduling. Cron-based scheduling and background jobs with no external infrastructure.
  • Deploy anywhere. Run on any cloud platform that runs containers. Docker, Railway, AWS, GCP.

Use Agno with your coding agent

Two options:

  1. Recommended: Add Agno docs as an MCP server. Add docs.agno.com/mcp to your favourite coding agent.
  2. Add Agno docs as an indexed source. In Cursor: Settings → Indexing & Docs → Add https://docs.agno.com/llms-full.txt. Also works in VSCode, Windsurf, and similar tools.

Read the full guide here.

Community

Contributing

See the contributing guide.

License

Agno is distributed under the Apache-2.0 license.

Telemetry

Agno sends a telemetry event per agent run so we know which model providers to prioritize. Prompts, messages, and outputs are never sent. Disable by setting AGNO_TELEMETRY=false.

↑ Back to top

S
Description
Build, run, and manage agent platforms.
Readme Apache-2.0
706 MiB
Languages
Python 99.7%
HTML 0.1%
Shell 0.1%