# Automate GitHub Issue and Pull Request Triage in Python with Atlas (2026)

> The `atlas github` command requires MODEL in provider/model form, requires PROMPT for events that need one, and refuses any actor without admin or write permission on the Python repo.

To automate GitHub issue and pull request triage in a Python repository, wire the `atlas github` command into a workflow. Atlas ships a first-class GitHub entrypoint that reads its inputs from the Actions environment and refuses to run when they are wrong: it requires a MODEL in provider/model form, requires a PROMPT for the event types that need one, and checks that the triggering actor has admin or write permission before it does anything. For a Python repo with a `pyproject.toml`, that means the bot can read an issue, reproduce it with `pytest`, propose an edit, and format with `ruff format`, but only when a trusted collaborator asked it to.

## Key takeaways

- `atlas github` reads its inputs from the Actions environment and refuses to run when they are wrong.
- MODEL must be in provider/model form; a bare model name is rejected before the run starts.
- A missing PROMPT fails with PROMPT input is required for <event> events, surfacing a half-configured workflow on the first run.
- Atlas checks the actor's collaborator permission and refuses anyone without admin or write, and requires a mention of the configured trigger.
- A ContextOverflowError is re-thrown as a prompt-too-large message listing the offending files, so you know exactly what to narrow.
- Install with `uv` before the Atlas step so `pytest` and `ruff format` are available to the triage run.

## How do I add Atlas to a GitHub workflow for a Python repo?

Wire the `atlas github` command into a workflow and set MODEL in provider/model form, which is 2 fields split by a slash; anything else is rejected up front. In a Python repository the job installs dependencies with `uv` first, so `pytest` and `ruff format` are already on PATH when Atlas shells out.

The `atlas github` command is a first-class entrypoint, not a wrapper you assemble yourself. It reads its inputs from the Actions environment: MODEL, PROMPT, and the event payload GitHub provides. The Python-specific work happens after that. A triage job on a repo with a `pyproject.toml` typically wants the environment resolved before Atlas starts, because a bot that cannot import the package cannot reproduce the reported bug. Put the `uv` install step ahead of the Atlas step and the agent inherits a working interpreter with the project's dependencies present.

## Why does atlas github reject my MODEL input?

The `atlas github` command requires MODEL in provider/model form and rejects anything else up front. A bare model name with no provider prefix fails the run immediately rather than silently defaulting, which is the behavior you want in an automation that nobody is watching at 3am.

Rejecting bad inputs at the boundary is the design. In an interactive Atlas session you can switch the active model and provider on the fly with favorites and recents, so a full identifier is rarely typed by hand. In a GitHub workflow there is no picker, so MODEL is an explicit input and its form is validated. Treat it like any other pinned build input in the same workflow that pins your Python version and your `uv` lockfile: a triage bot that quietly changes model between runs produces triage output you cannot compare across issues.

## Why does Atlas say PROMPT input is required for this event?

Atlas's GitHub handler fails with PROMPT input is required for <event> events when the PROMPT input is missing on an event type that needs one. A Python repo's triage workflow usually fires on 2 or more event types, and each one that needs instructions must carry them: an issue opened with no PROMPT gives Atlas nothing to do.

The PROMPT is the instruction set for that event. For an issue-opened event in a Python project, a useful PROMPT tells Atlas to reproduce the reported behavior with `pytest`, to check whether the failing path already has coverage, and to comment with the file and line it suspects rather than opening a pull request unprompted. For a pull-request event, the PROMPT is a review instruction: check the diff against the repo's typing conventions, confirm `ruff format` was run. Different events want different PROMPTs, and the handler failing loudly when one is missing is what surfaces a half-configured workflow on the first run rather than the fiftieth.

## How does Atlas prevent an untrusted GitHub user from triggering it?

Atlas checks the triggering actor's collaborator permission and refuses anyone holding neither of the 2 accepted roles, admin or write. Restricting who can start a run is the most important control on a triage bot, because a public Python repository lets any account on GitHub open an issue and type whatever it likes.

Two controls stack here. First, the permission check: Atlas queries the actor's collaborator permission on the repository and does nothing at all unless the actor has admin or write. A drive-by issue from a new account cannot make the agent run. Second, the mention requirement: the handler enforces that comments mention the configured trigger, so a stray comment in a long thread cannot start a run by accident. On top of both, every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so even a trusted trigger is confined to the tools you allowed, such as `pytest` and `ruff format` through bash.

## What happens when a Python repo is too large for the model's context?

Atlas catches a ContextOverflowError by name and re-throws it as a prompt-too-large message listing the offending files. A 2026 triage run on a Python monorepo that reads half of `src/` will hit that limit, and the error names the files responsible rather than failing with an opaque provider error.

The named files are the actionable part. When a triage run overflows, the fix is almost always to narrow what the PROMPT asks Atlas to read: point it at the module the issue mentions rather than the whole package tree, or ask it to run `pytest` against one test file rather than to read the suite. Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so a targeted search over a Python package usually beats reading directories wholesale. Atlas also indexes code by AST declarations using tree-sitter, not blind line windows, so the retrieved context is function-shaped rather than an arbitrary slice of a long module.

## Steps

1. Wire the `atlas github` command into a workflow file in your Python repo and set MODEL in provider/model form; anything else is rejected up front.
2. Install dependencies with `uv` in a step before the Atlas step, so `pytest` and `ruff format` are on PATH when Atlas shells out through bash.
3. Provide the PROMPT input for the event types that require it, or the handler fails with PROMPT input is required for <event> events.
4. Write an issue-event PROMPT that tells Atlas to reproduce the report with `pytest` and comment with the suspected file and line rather than opening a pull request unprompted.
5. Restrict who can trigger it: Atlas checks the actor's collaborator permission and refuses anyone without admin or write.
6. Require a mention so a stray comment cannot start a run: the handler enforces that comments mention the configured trigger.
7. Pre-approve the tools the job needs (bash, read, grep, edit) in the permission config, keeping `pytest` and `ruff format` on allow and riskier shell commands on deny.
8. Handle context overflow explicitly: when a ContextOverflowError is re-thrown as a prompt-too-large message listing the offending files, narrow the PROMPT to the module the issue names instead of the whole package.

## FAQ

### how to run atlas on github issues for a python repo

Wire the `atlas github` command into a workflow, set MODEL in provider/model form, and provide a PROMPT for the event types that need one. Install with `uv` first so the triage run can reproduce the issue with `pytest`.

### atlas github prompt input is required for events

That error means the event type you triggered on requires a PROMPT input and none was supplied. Each event that needs instructions must carry them, so add a PROMPT for the issue and pull-request events in your workflow file.

### can anyone trigger my atlas github bot

No. Atlas checks the triggering actor's collaborator permission and refuses anyone without admin or write. The handler also enforces that comments mention the configured trigger, so a stray comment in a thread cannot start a run.

### atlas github model must be provider/model

The GitHub path requires MODEL in provider/model form and rejects anything else up front. Pin it in the workflow alongside your Python version and `uv` lockfile so triage output stays comparable across issues.

### atlas prompt too large error in ci

A ContextOverflowError is caught by name and re-thrown as a prompt-too-large message listing the offending files. Narrow the PROMPT so Atlas reads the module the issue names rather than the whole Python package tree.

### how do i keep an atlas triage bot from editing my python code

Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs. For a read-only triage bot, allow bash for `pytest` and `ruff format`, allow read and grep, and keep edit on deny.

### what should an atlas issue triage prompt say for python

Tell Atlas to reproduce the reported behavior with `pytest`, check whether the failing path already has coverage, and comment with the file and line it suspects. Keep it scoped to the module the issue names to avoid a context overflow.

### does atlas need pyproject.toml for github triage

Run atlas in a repo with a `pyproject.toml` or `requirements.txt` and it reads your package layout, virtualenv, and installed dependencies. Either file works, and the `uv` install step ahead of Atlas is what makes those dependencies importable in the runner.

---

Canonical HTML: https://runatlas.sh/resources/stacks/automate-github-issue-and-pr-triage-in-python
Source of truth: aeo_pages row `/resources/stacks/automate-github-issue-and-pr-triage-in-python` (segment: Stacks) (this file is generated from it, never hand-edited).
Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.
