Mention @atmos-pro where the work is happening
Infrastructure work already happens in GitHub: issue threads, pull request conversations, and inline review comments. Atmos Pro now meets you there. Mention
@atmos-pro in a GitHub issue or pull request and Atmos Pro can respond with the same workspace-aware context available in Atmos AI.This is ChatOps for infrastructure reviews. You do not need to switch tabs, copy run IDs, or paste workflow logs into another tool. Ask from the thread where the question came up, and the answer stays attached to the work.
ostermancommented 2 minutes ago
@atmos-pro what's the blast radius of these changes?
atmos-probotcommented 1 minute ago
👋 Hey @osterman — I checked the affected stacks and recent plans. Here's the likely blast radius:
PR #25 — Bump dev cluster environment
Branch: osterman/bump-environment-pr → main
Status: Open, not a draft
⚠️ Blast radius for plat-use2-dev
The direct change is the cluster component. It upgrades the dev cluster from v1.29 to v1.30, which can affect components that depend on cluster outputs, add-ons, or provider behavior.
| Component | Stack | Impact |
|---|---|---|
cluster | plat-use2-dev | Direct upgrade target |
api | plat-use2-dev | May replan after cluster outputs change |
monitoring | plat-use2-dev | May pick up add-on/provider drift |
frontend | plat-use2-dev | Likely indirect dependency only |
cdn | plat-use2-dev | No direct cluster dependency found |
Current plans show 1 directly affected stack and 5 components to watch. We won't know the full downstream impact until after the cluster is upgraded and dependency plans are re-run against the new cluster outputs. You can view the full event details in the Atmos Pro dashboard.
Ask it to summarize, investigate, triage, or review
Summaries are one use case, but the workflow is broader than summarization. You can ask
@atmos-pro to explain what changed, triage a failing plan, inspect workflow failures, review operational risk, or turn an investigation into a handoff for the next engineer.Mention
@atmos-pro and ask it to summarize blast radius, explain failed applies, review risky replacements, triage failed checks, or draft a handoff for the on-call engineer.The response is posted back to GitHub, so reviewers and operators can keep the conversation in the same issue or PR thread.
Backed by Atmos Pro workspace context and permissions
@atmos-pro is not a generic chatbot dropped into a repository. It runs with Atmos Pro workspace context: repositories, stacks, components, workflow runs, cached logs, drift state, pull request metadata, AI summaries, deployment history, and the MCP tools your team already uses.Workspace membership, seat assignment, and role permissions still apply. The bot only responds for authorized Atmos Pro users, filters the generated tool set to read-only Atmos Pro scopes, and hides GitHub comment-posting tools from the model while it generates the answer. The workflow, not the model, posts the single controlled reply back to GitHub.
Each accepted GitHub mention also becomes an Atmos AI chat session for the workspace, so your team can review the GitHub prompt, the generated answer, and the saved conversation later from the Atmos AI chat page.
Works in issues, PR conversations, and review threads
GitHub ChatOps works across the places teams already discuss infrastructure changes:
- Issue comments for triage, incidents, follow-ups, and operational questions.
- Pull request conversation comments for broad review and merge-readiness checks.
- Inline PR review threads for code-adjacent plan review and failure investigation.
That means
@atmos-pro can join the conversation whether the question starts as an issue, a PR-level review comment, or a specific line of code. Shorter aliases, including @atmos, are available for teams that prefer a compact mention.