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.
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.
Step by step
- 01Wire 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.
- 02Install dependencies with `uv` in a step before the Atlas step, so `pytest` and `ruff format` are on PATH when Atlas shells out through bash.
- 03Provide the PROMPT input for the event types that require it, or the handler fails with PROMPT input is required for <event> events.
- 04Write 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.
- 05Restrict who can trigger it: Atlas checks the actor's collaborator permission and refuses anyone without admin or write.
- 06Require a mention so a stray comment cannot start a run: the handler enforces that comments mention the configured trigger.
- 07Pre-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.
- 08Handle 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.
Frequently asked questions
- 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.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Automate GitHub Issue and Pull Request Triage with Atlas (2026 Workflow)
How to automate GitHub issue and pull request triage with Atlas in 2026: the atlas github command checks the actor has admin or write permission before it does anything.
Atlas for Python in 2026
Atlas is a terminal-native AI coding agent for Python in 2026. Run it in a repo with a pyproject.toml or requirements.txt and review every diff before it lands.
Upgrade Python Dependencies and Fix Breakage with Atlas in 2026
In 2026, Python developers use Atlas to upgrade dependencies like Django or FastAPI, automatically fixing compile and test failures with `uv`, `pytest`, and `ruff format`.
Audit a Python Repo with Parallel Subagents in Atlas (2026)
Audit a Python repo with parallel Atlas subagents in 2026. Slice by package, launch read-only explore tasks, and merge findings without flooding your context.
Run Atlas Headless in CI in a Python Repo: The 2026 Guide to atlas run
Run Atlas headless in CI on a Python repo in 2026. Use atlas run with --format json, pre-approve tools, and gate the pipeline on pytest, uv, and ruff format.
Review a pull request in Python with Atlas (2026)
Review a Python pull request in 2026 with Atlas: read the changed .py files in full, check callers with findReferences, and run pytest before you approve the diff.
Extract a Shared Helper From Duplicated Code in Python with Atlas (2026)
Duplication in Python is semantic, not textual. Atlas finds near-duplicate logic with codebase_search in 2026, collapses it with apply_patch, and proves it with pytest.
Run the Test Suite and Triage the Failures in Python with Atlas (2026)
How Atlas runs pytest and triages a wall of Python failures in 2026: bash truncates at 2000 lines, saves the full log, and grep groups failures into a todowrite list.