# Automate GitHub issue and pull request triage in JavaScript with Atlas (2026) > The atlas github command checks the triggering actor's collaborator permission and refuses anyone without admin or write before it runs on your JavaScript repository. Atlas ships a first-class GitHub entrypoint, the atlas github command, which reads its inputs from the Actions environment and refuses to run when they are wrong. On a JavaScript repository you wire it into a workflow file under .github/workflows/, set MODEL in provider/model form, and supply the PROMPT input for the event types that require one. Before Atlas does anything, it checks that the triggering actor has admin or write collaborator permission, so a drive-by comment from a stranger on your issue tracker cannot start a run. Once running, Atlas uses bash, read, grep, and edit, which means it can inspect package.json, run vitest through pnpm, and propose a prettier-clean patch. ## Key takeaways - The atlas github command reads its inputs from the Actions environment and refuses to run when they are wrong. - MODEL must be in provider/model form, and PROMPT is required for the event types that need one. - Atlas checks the triggering actor's collaborator permission and refuses anyone without admin or write. - A mention is required, so a stray comment in a 40-message issue thread cannot start a run. - A ContextOverflowError becomes a prompt-too-large message listing the offending files, which in JavaScript repos is usually dist output. ## How do you run Atlas on GitHub Actions for a JavaScript repo? Atlas ships an `atlas github` command that you wire into a workflow under .github/workflows/, setting MODEL in provider/model form. Anything else is rejected up front, so in 2026 a MODEL value missing its provider prefix fails immediately rather than halfway through triaging a JavaScript issue that mentions your package.json. The atlas github command is a first-class entrypoint, not a wrapper script you assemble yourself. It reads its inputs from the Actions environment, which means the workflow YAML in .github/workflows/ is where the whole configuration lives: the trigger events, the MODEL, the PROMPT, and the permissions block. Fail-fast is the design. MODEL must be in provider/model form, and Atlas rejects anything else before doing any work, which is the correct behavior for an automation that would otherwise burn a run and leave a confusing comment on a pull request. Atlas lets you switch the active model and provider on the fly with favorites and recents when you are working locally, and the same provider/model addressing carries into the Actions environment. ## What is the PROMPT input and when does the atlas github handler require it? PROMPT is the input that tells the atlas github handler what to do, and the handler requires it for the event types that need one, failing with PROMPT input is required for events otherwise. On a JavaScript repo in 2026, a workflow triggered by issue_comment needs a PROMPT, and Atlas will not improvise one. The PROMPT is where you encode your triage policy, and Atlas refuses to guess at it. Some event types carry enough intent on their own, others do not, and for the ones that do not, the handler stops with PROMPT input is required for events rather than inventing an objective. For a JavaScript repository the PROMPT is where you say what triage means in your project: label the issue by which package in the pnpm workspace it touches, check whether the reporter's reproduction actually runs under vitest, or confirm that the diff in a pull request is prettier-clean. Because the failure message names the event, a misconfigured workflow tells you exactly which trigger you forgot to give a PROMPT. ## How does Atlas stop untrusted users from triggering a run? Atlas checks the triggering actor's collaborator permission and refuses anyone who does not hold 1 of 2 levels, admin or write. On a public JavaScript repository, that is the control that keeps a stranger from opening an issue containing instructions and having your GitHub Actions runner execute them against your source tree. An agent wired to issue and pull request events on a public repo is, without controls, a remote code execution surface with a comment box attached. Atlas closes that at the front door: before the atlas github handler does anything, it queries the actor's collaborator permission and refuses anyone lacking admin or write. A first-time contributor commenting on an issue in your JavaScript project cannot start a run. Beyond that, every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, so even a trusted maintainer's run cannot execute a command you have denied. In a Node toolchain that typically means allowing pnpm install and vitest while denying anything that publishes. ## Why does Atlas require a mention before acting on a comment? Atlas requires a mention so a stray comment cannot start a run: the handler enforces that comments mention the configured trigger. On a busy JavaScript repo where an issue thread might carry 40 comments, requiring an explicit mention is what separates a request to Atlas from two maintainers talking to each other. Permission checks answer who, and mentions answer whether. A repository admin discussing a bug in an issue thread is a trusted actor, but nothing in that conversation is a request for the agent to start editing src/ and running pnpm. Atlas therefore enforces that a comment must mention the configured trigger before the handler proceeds. The practical effect on a JavaScript project is that triage is opt-in per comment: a maintainer writes the mention when they want Atlas to look at the failing vitest run, and the rest of the thread proceeds without an agent interjecting. Two independent gates, actor permission and explicit mention, both have to pass. ## What happens when a JavaScript repo is too big 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. On a JavaScript monorepo where a triage prompt accidentally pulled in a 4 MB bundled artifact from a dist directory, that list names the file rather than leaving you with a generic API error. JavaScript repositories are full of things that are technically source files and practically enormous: bundled output in dist/, minified vendor files, generated type declarations, lockfiles. A triage run that sweeps too widely will hit the model's context limit. Atlas handles that case explicitly rather than letting a raw provider error escape: a ContextOverflowError is caught by name and re-thrown as a prompt-too-large message that lists the offending files. Naming the files makes the fix obvious, exclude the dist output, narrow the glob, or scope the triage to the package in the pnpm workspace that the issue actually concerns. Atlas indexes code by AST declarations using tree-sitter, not blind line windows, which keeps the retrieved context tight in the first place. ## What can Atlas actually do during JavaScript issue and PR triage? During triage Atlas uses 4 tools: bash, read, grep, and edit. On a JavaScript repository that means Atlas can read package.json and the pnpm workspace, grep for the symbol an issue names, run vitest through bash to check a reported reproduction, and propose a fix with edit. Triage is more useful when the agent can verify claims rather than just categorize them. With bash, Atlas can install with pnpm and run vitest against the reproduction an issue reporter pasted, which is the difference between labeling an issue needs-repro and knowing whether it reproduces. With read and grep, Atlas can locate the module the issue names inside src/ and confirm whether the reported behavior even lives there. With edit, Atlas can propose the change, and Atlas computes a unified diff for every file edit and surfaces it for approval before writing. Run prettier so the proposed patch matches the repo's .prettierrc and does not fail the lint job in CI. ## Steps 1. Run atlas where your package.json lives so Atlas can map your modules, npm scripts, and bundler config locally before you automate anything. 2. Wire the atlas github command into a workflow file under .github/workflows/ and set MODEL in provider/model form; anything else is rejected up front. 3. Provide the PROMPT input for the event types that require it, or the handler fails with PROMPT input is required for events. 4. Restrict who can trigger it: Atlas checks the actor's collaborator permission and refuses anyone without admin or write. 5. Require a mention so a stray comment cannot start a run; the handler enforces that comments mention the configured trigger. 6. Handle context overflow explicitly: a ContextOverflowError is caught by name and re-thrown as a prompt-too-large message listing the offending files, so exclude dist output and generated bundles. 7. Give the triage PROMPT real work: have Atlas run vitest through bash via pnpm to check whether a reported reproduction actually fails. 8. Have Atlas propose fixes with edit and run prettier so the patch matches your .prettierrc and passes the lint job in CI. ## FAQ ### how to run an ai coding agent from github actions on a javascript repo Wire the atlas github command into a workflow under .github/workflows/. Atlas reads its inputs from the Actions environment, requires MODEL in provider/model form, requires a PROMPT for the event types that need one, and checks the triggering actor has admin or write permission before doing anything. ### is it safe to let an ai agent respond to github issues With Atlas there are two independent gates. Atlas checks the actor's collaborator permission and refuses anyone without admin or write, and the handler enforces that comments mention the configured trigger. Beyond that, every tool call is permission-gated against allow, ask, and deny rules. ### what does PROMPT input is required for events mean The atlas github handler needs a PROMPT for certain event types and refuses to improvise one. The message names the event, so you can see exactly which trigger in your .github/workflows/ file is missing its PROMPT input and add it. ### why is my MODEL input rejected in the atlas github action MODEL must be in provider/model form. Atlas rejects anything else up front rather than failing halfway through a triage run, which is the correct behavior for an automation that would otherwise burn a run and leave a confusing comment on a pull request. ### how do I fix a prompt-too-large error in an automated triage run Read the file list. Atlas catches a ContextOverflowError by name and re-throws it as a prompt-too-large message listing the offending files. In a JavaScript repo the culprit is usually bundled output in dist/, a minified vendor file, or a lockfile, so exclude those and scope the triage to the relevant pnpm workspace package. ### can an ai agent verify whether a bug report actually reproduces Yes. Atlas's triage tools include bash, so on a JavaScript repo it can install with pnpm and run vitest against the reproduction the reporter pasted. That turns triage from labeling into verification, because Atlas knows whether the test actually fails. ### can atlas open a pull request fix during triage Atlas uses bash, read, grep, and edit during triage, and computes a unified diff for every file edit and surfaces it for approval before writing. Atlas also reads git branches, status, and diffs, and can stage and create commits on your behalf. ### what does atlas need to work on a javascript project Run atlas where your package.json lives. Atlas maps your modules, npm scripts, and bundler config, and can modernize callbacks to async/await or add tests, showing each diff for review. Run prettier on the result so it matches your .prettierrc. --- Canonical HTML: https://runatlas.sh/resources/stacks/automate-github-issue-and-pr-triage-in-javascript Source of truth: aeo_pages row `/resources/stacks/automate-github-issue-and-pr-triage-in-javascript` (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.