The GitHub integration runs 100xprompt inside your repository’s GitHub Actions. Mention it on an issue or a pull request, and 100xprompt reads the full context, edits your codebase, and pushes its work back as a commit or a new pull request. This is the same agent you use in your terminal, wired into GitHub’s events. It respects your repository’s permissions, replies inline, and links every run so you can inspect exactly what it did.

​
What the GitHub integration does

Suppose a teammate files an issue and you want a fix drafted before you even open your editor. Mention 100xprompt in a comment and it goes to work. Depending on where the mention happens, it either amends an existing pull request or opens a new one.

Answers on issues

Mention it in an issue comment and it investigates, then either replies with an analysis or turns the issue into a pull request that closes it.

Works on pull requests

Mention it on a pull request - including a review comment on a specific line - and it commits changes directly to that PR’s branch.

Opens pull requests

When its work produces code changes, it pushes a branch and opens a pull request for you to review and merge.

Runs on your terms

Every run happens in GitHub Actions with your secrets, checks the commenter’s write access first, and shares a link to the full session.

​
How it works

The integration runs as a GitHub Actions workflow. An event in your repository triggers the workflow. The workflow runs 100xprompt with the context of that issue or pull request. 100xprompt proposes its changes back through the same PR or a new one.
Because it runs in GitHub Actions, 100xprompt uses your repository or organization secrets for model access and never needs credentials stored anywhere else. Each run leaves a link back to the Actions log and, for public repositories, a shareable session.

​
Install it into a repository

Suppose you want to automate a specific repository. Run the guided, one-time installer from that repository. It connects the GitHub app, lets you pick a provider and model, and writes a workflow file for you to commit.
1

Run the installer from your repo

From the root of your git repository, run:
100xprompt github install
The command detects your GitHub repository from its origin remote, so run it inside a checked-out clone.
2

Authorize the GitHub app

The installer opens GitHub in your browser so you can install the 100xprompt app on the target repository (or your whole organization). It waits until the installation is detected, then continues automatically.
3

Choose a provider and model

Pick the provider and model the agent should use for this repository. This choice is written into the generated workflow so every run uses it by default.
4

Commit the generated workflow

The installer writes a workflow file into .github/workflows/. Commit and push it so GitHub starts listening for events:
git add .github/workflows
git commit -m "Add 100xprompt GitHub workflow"
git push
5

Add your provider secret

In your repository or organization Settings → Secrets, add the API key(s) for the provider you chose. The installer prints the exact secret names to add. The workflow reads them at runtime.
Add secrets at the organization level to reuse the same key across every repository that installs the integration.
6

Try it

Open an issue or pull request and mention the agent in a comment - for example, /oc summarize. Within moments you’ll see the 👀 reaction appear, and shortly after, a reply or a new pull request.
The generated workflow only listens for the events written into it. Everyone with write access to the repository can invoke the agent by mentioning it - 100xprompt verifies the commenter has write or admin access before doing any work, and refuses otherwise.

​
Trigger the agent

Mention the agent in a comment to invoke it. Out of the box it responds to /100xprompt or the shorthand /oc, and you can customize the trigger phrase (see Configure the workflow below). Matching is case-insensitive. How 100xprompt responds depends on where you mention it and what you say.
Where you mention itWhat you writeWhat 100xprompt does
Issue commentJust the trigger (e.g. /100xprompt)Summarizes the issue thread as a reply.
Issue commentA request after the triggerWorks on the request, opens a pull request that closes the issue, and comments back.
Pull request commentJust the triggerSummarizes the pull request thread.
Pull request commentA request after the triggerMakes the change and commits it to the PR’s branch, then replies.
PR review comment (on a line)Just the triggerReviews the commented lines and suggests improvements for them.
PR review comment (on a line)A request after the triggerApplies your request with the file and diff as context, then commits.
When 100xprompt works on an issue, it creates a fresh branch and opens a new pull request that closes the issue. When it works on a pull request, it commits back to that PR’s existing branch - including pull requests opened from forks, where it pushes to the contributor’s fork branch.

​
What it can see

100xprompt reads the surrounding context before it starts. On a pull request, that includes the title and description, the changed files, prior comments, and review threads. On an issue, it reads the title, body, and comment history. Images and file attachments in the triggering comment are downloaded and made available to the agent too.

​
Review the proposed change

When 100xprompt’s work results in code changes, it turns that work into something you can review - never a silent push to your default branch.
Every change the agent commits credits the person who triggered it as a co-author, so authorship stays with your team. When it opens a new pull request from an issue, the PR body links the originating issue and closes it on merge. When there’s nothing to change - for example, you only asked a question - it replies with its answer and commits nothing.
Every reply includes a link back to the GitHub Actions run, and for public repositories, a link to the full 100xprompt session - so you can always trace how a change was produced.

​
Bring a PR into your terminal

Suppose the agent opened a pull request and you want to keep working on it locally. Check it out and open an interactive session in one step: 
100xprompt pr 42
This fetches and checks out pull request #42 (handling fork branches automatically), then launches 100xprompt in that working tree. If the pull request was created by the GitHub integration and links a shared session, that session is imported so you continue with full history and context.

​
Configure the workflow

The workflow the installer generates works out of the box. When you want to tune behavior, adjust the inputs on the workflow step:
InputWhat it controls
modelThe provider and model the agent uses, in provider/model form. Set during install; required.
agentRun a specific primary agent instead of the default.
promptProvide a fixed instruction for the run instead of reading it from the comment.
mentionsCustomize the trigger phrase(s) - a comma-separated list, matched case-insensitively.
shareControl whether the run’s session is shared. Sessions are shared by default for public repositories.
Yes. Set the mentions input on the workflow step to a comma-separated list of phrases. Anyone who includes one of those phrases in a comment invokes the agent. Matching is case-insensitive.
Yes. When a mentioned pull request comes from a fork, 100xprompt checks out the contributor’s fork branch, makes the change, and pushes back to that same fork branch so the update appears on the existing pull request.
Only users with write or admin access to the repository. On every user-triggered run, 100xprompt checks the commenter’s permission level first and refuses to act for anyone without write access.
The agent runs with the permissions granted to the workflow and the GitHub app on your repository. Pair it with your repository’s branch protection and reviews so nothing merges without human approval, and scope the model provider’s secrets to only the repositories that need them.

​
Tips and limits

Keep your AGENTS.md and repository rules current. The GitHub agent reads the same project context as your terminal sessions, so good rules make its pull requests match your conventions.
The agent proposes changes; it does not merge them. Treat every pull request it opens like one from a teammate - review the diff and run your checks before merging. Combine it with required reviews and branch protection for safety.
  • Automation workflows: reusable agents, models, and non-interactive runs.
  • SDK: drive 100xprompt programmatically to build your own integrations.
  • Permissions: the same guardrails that apply on GitHub.

Automation workflows

Recipes and building blocks - agents, models, and non-interactive runs you can reuse anywhere.

SDK

Drive 100xprompt programmatically to build your own automations and integrations.

Permissions

Control what the agent is allowed to do - the same guardrails apply on GitHub.