> ## Documentation Index
> Fetch the complete documentation index at: https://atmet.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# GitHub Integration: Automate Your Developer Workflows
> Connect GitHub to Atmet to trigger workflows on issues, pull requests, and commits — and automate issue triage, PR reviews, and repo management.
The GitHub integration connects your repositories to Atmet so that engineering events — a new issue, an opened pull request, a branch change — can kick off automated workflows across your entire tool stack. Use it to route issues to the right team member the moment they're filed, remind reviewers about open PRs that have gone stale, post deployment summaries to Slack, or keep your project management tools in sync with what's happening in code. Atmet treats your GitHub activity as a first-class event stream that your AI agents can act on in real time.
## Prerequisites
Before connecting GitHub, make sure you have:
* A GitHub account (personal or organization)
* Access to the repositories you want to automate (Atmet will only be able to interact with repos your account has access to)
* For organization repositories: organization members may need owner approval to install new OAuth apps, depending on your org's policy
***
## Connecting GitHub
In the Atmet sidebar, navigate to **Integrations** and find **GitHub** in the list.
Click the **Connect** button. You'll be redirected to GitHub's OAuth authorization page.
Review the requested permissions and click **Authorize**. If you're a member of GitHub organizations, you can also grant access to specific org repositories at this step.
GitHub redirects you back to Atmet. A green **Connected** badge confirms your account is linked and ready to use in workflows.
If you need to automate repositories belonging to a GitHub organization, ask your organization owner to approve the OAuth app, or use a personal access token with repo scope if your organization requires it.
***
## Triggers
GitHub supports a rich set of triggers covering the full development lifecycle. Below are the most commonly used trigger categories.
| Trigger | What it fires on |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **New issue created** | Fires when a new issue is opened in a repository. Supports filters for assignee, creator, labels, state, and polling interval. |
| **Issue updated** | Fires when an existing issue's properties change — assignee, labels, state, or title. |
| **Issue state changed** | Fires specifically when an issue is opened or closed. |
| **Issue assigned to me** | Fires when an issue is assigned to the authenticated user. |
| **New issue comment** | Fires when a comment is added to an issue. |
| **Issue comment changed** | Fires when an existing issue comment is edited. |
| **Issue labels changed** | Fires when labels are added or removed from an issue. |
**Use these triggers when** you want to auto-assign, auto-label, or notify a team member every time an issue is filed or updated — especially useful for on-call routing and bug triage.
| Trigger | What it fires on |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- |
| **New pull request created** | Fires when a PR is opened. Supports filters for author, base branch, head branch, draft status, label, assignee, state, and polling interval. |
| **Pull request updated** | Fires when a PR's properties change — title, labels, reviewers, draft status, or branch. |
| **Pull request state changed** | Fires when a PR is merged, closed, or reopened. |
| **New PR review comment** | Fires when a review comment is left on a PR diff. |
| **PR review submitted** | Fires when a pull request review (approve, request changes, comment) is submitted. |
| **PR reviewers changed** | Fires when reviewers are added or removed from a PR. |
| **New commit added to PR** | Fires when a new commit is pushed to an open PR's branch. |
**Use these triggers when** you want to notify reviewers, run a checklist validation, post a summary to Slack, or create a linked task in Jira the moment a PR is opened or updated.
| Trigger | What it fires on |
| ------------------------------ | ----------------------------------------------------------- |
| **Commit event** | Fires on commits to a repository. |
| **New branch created** | Fires when a branch is created in a repository. |
| **Branch changed** | Fires when a branch reference changes (new commits pushed). |
| **New git reference created** | Fires when a new Git ref (branch or tag) is created. |
| **New repository tag created** | Fires when a new tag is pushed to a repository. |
| **Repository content changed** | Fires when the content of a specific file or path changes. |
| **README changed** | Fires when the repository README file is updated. |
| Trigger | What it fires on |
| ---------------------------- | ------------------------------------------------------- |
| **New deployment created** | Fires when a deployment is created for a repository. |
| **Deployment state changed** | Fires when an existing deployment changes state. |
| **New deployment status** | Fires when a deployment status event is created. |
| **Release state changed** | Fires when a release is published, updated, or deleted. |
| **New release asset added** | Fires when a file is uploaded to a release. |
| Trigger | What it fires on |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| **New workflow run created** | Fires when a GitHub Actions workflow run starts. Supports filters for actor, branch, event type, and interval. |
| **Workflow run state changed** | Fires when a workflow run completes, fails, or is cancelled. |
| **New workflow artifact created** | Fires when a workflow run produces a new artifact. |
| **New workflow job added** | Fires when a new job is queued in a workflow run. |
| **Workflow job state changed** | Fires when a workflow job changes state. |
| **New GitHub Actions workflow added** | Fires when a new workflow file is added to a repository. |
***
## Actions
GitHub provides a comprehensive set of actions. Below are the most frequently used categories.
| Action | What it does |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------ |
| **List repositories** | Returns repositories the authenticated user has access to, with filters by type, visibility, and sort order. |
| **Get a repository** | Retrieves metadata for a specific repository. |
| **Create repository** | Creates a new repository under the authenticated account. |
| **Find repositories** | Searches GitHub repositories by query, topic, language, and other filters. |
| **Get repository content** | Reads a file or directory listing from a repository. |
| **Create or update file contents** | Creates or updates a file in a repository with a commit message. |
| **Delete a file** | Deletes a file from a repository. |
| Action | What it does |
| --------------------------- | --------------------------------------------------------------------------------------- |
| **Get an issue** | Retrieves full details of a specific issue — title, body, labels, assignees, and state. |
| **Create an issue** | Opens a new issue with a title, body, labels, milestone, and assignees. |
| **Close issue** | Closes an open issue, optionally setting a state reason (completed, not planned). |
| **Reopen issue** | Reopens a previously closed issue. |
| **Add labels to an issue** | Applies one or more labels to an issue. |
| **Create an issue comment** | Posts a new comment on an issue. |
| **List repository issues** | Returns issues in a repository with filters for state, labels, assignee, and creator. |
| **Lock an issue** | Locks an issue to prevent further comments. |
| Action | What it does |
| --------------------------------------- | ----------------------------------------------------------------------------------- |
| **Get a pull request** | Retrieves full details of a specific pull request. |
| **Create a pull request** | Opens a new pull request between a head branch and base branch. |
| **Close pull request** | Closes an open pull request without merging. |
| **Merge a pull request** | Merges an open pull request with a specified merge method (merge, squash, rebase). |
| **List pull requests** | Returns open or closed pull requests with filters for state, base, and head branch. |
| **Find pull requests** | Searches pull requests across repositories by query and filters. |
| **Create a review for a PR** | Submits an approve, request-changes, or comment review on a pull request. |
| **Request reviewers** | Adds reviewers or team reviewers to a pull request. |
| **Create a reply for a review comment** | Posts a reply to an existing review comment. |
| Action | What it does |
| ------------------------- | --------------------------------------------------------------------------------------- |
| **List commits** | Returns the commit history for a branch or path, with optional date and author filters. |
| **Get a commit** | Retrieves details of a specific commit by SHA. |
| **Create a commit** | Creates a Git commit object. |
| **Commit multiple files** | Creates or updates multiple files in a single commit. |
| **List branches** | Returns branches in a repository. |
| **Get a branch** | Retrieves details of a specific branch. |
| **Create branch** | Creates a new branch from a given SHA. |
| **Rename a branch** | Renames an existing branch. |
| **Merge a branch** | Merges one branch into another. |
| **Compare two commits** | Returns a diff and commit list between two refs. |
| Action | What it does |
| -------------------------- | ------------------------------------------------------------------------- |
| **Create a release** | Creates a new release with a tag, name, body, and draft/prerelease flags. |
| **Get a release** | Retrieves a release by ID or tag name. |
| **List releases** | Returns all releases for a repository. |
| **Generate release notes** | Auto-generates release notes from commits between two tags. |
| **Delete a release** | Deletes a release from a repository. |
| Action | What it does |
| ------------------------------------ | ----------------------------------------------------------------------------------------------- |
| **Create a workflow dispatch event** | Manually triggers a GitHub Actions workflow. |
| **Get a workflow run** | Returns the status and details of a specific workflow run. |
| **List workflow runs** | Returns workflow runs for a repository or workflow, with filters for status, branch, and actor. |
| **Cancel workflow run** | Cancels an in-progress workflow run. |
| **Re-run a workflow** | Retries a failed or cancelled workflow run. |
| **Download workflow run logs** | Retrieves the logs for a completed workflow run. |
***
## Workflow ideas
Trigger on new issues. Use an AI step to classify the issue type (bug, feature request, question) and automatically apply the correct label, assign to the right team, and post a triage summary as a comment.
Trigger on new pull requests. Wait 24 hours, then check if the PR has been reviewed. If not, send a Slack DM to the assigned reviewers with a direct link to the PR.
Trigger on a new release creation. Use the **Generate release notes** action to build a changelog from recent commits, then post the summary to a Slack channel and a Notion page.
Trigger on new issues labeled `customer-reported`. Automatically create a linked Jira ticket or Asana task with the same title and description, then add a comment to the GitHub issue with the ticket link.
***
## Limitations and notes
GitHub's REST API enforces rate limits of **5,000 requests per hour** for authenticated requests. High-frequency workflows that poll or list resources in large repositories may approach this limit. Where possible, use triggers instead of scheduled polling.
When creating issues or PRs programmatically, use the `body` field to include context from upstream workflow steps — for example, a Slack message body, a customer email summary, or an AI-generated description. Rich context makes automated issues much more actionable for your team.
The **Create an issue comment** action works on both issues and pull requests — they share the same comment API in GitHub. Use the issue or PR number as the reference in your workflow step.
Yes. During the OAuth flow, GitHub will show a list of organizations you belong to. Click **Grant** next to any organization to authorize Atmet for that org's repositories. Organization owners may need to approve the OAuth app before access is granted — they'll receive a request notification in their GitHub settings.