GitHub integration
Install the Awk GitHub App on the repositories you choose; AI developers branch, commit and open pull requests, and a person approves every merge.
Awks (agentic workers): AI developers and testers that build and test your work items. In GitHub they work the way a developer and a tester do: the developer awk writes code on a branch and opens a pull request; the tester awk tests the build when you ask for independent QA; a person approves the merge, and the developer awk carries it out.
Connecting GitHub
You need organization admin access to install the Awk GitHub App. It is installed at the organization level — no personal access tokens — and requests permission to:
- →Read repository contents, issues, and pull requests
- →Create branches, commits, and pull requests
- →Post comments on pull requests and issues
Permissions are scoped per-repository: during the console's Integrations step you choose which repositories the agentic workers can work in, and you can install or modify access at any time from your GitHub organization settings. Private repositories work the same way — agentic workers can access a private repository if the app is installed on it.
What each agentic worker does in GitHub
| Agentic worker | In GitHub |
|---|---|
| OG (the engineer) | Creates branches, writes code, runs tests, reviews the change, comments on issues. Opens the pull request and merges it, with your approval: a merge asks every time, and opening one asks unless you've chosen to approve them all in that thread. |
| QA (the tester) | Tests the build against the work item, reads diffs, runs checks. Reviews a pull request's code when you ask, with inline comments. Commits test code where needed. Fixes to the feature go back to OG. |
| Oracle (context) | Searches across your repos and traces what changed. Does not write code or open PRs. |
See Meet the crew for the full list of what each agentic worker does and doesn't do.
What happens on a work item
When OG picks up a work item (from Jira or from a Slack message):
- →Writes code in a new branch
- →Runs tests and iterates until green, then puts the change through a code review
- →Opens a pull request — this waits for your approval in Slack, unless a person on your team in the thread has chosen to approve them all
- →Hands off to QA, when independent QA is requested, to check the build against the work item
QA checks the build does what the work item asked. If it finds issues — the build doesn't meet the requirement, a regression, a security risk — it sends the work back to OG with its findings. OG fixes and resubmits. When QA passes it, OG finishes the work: it makes sure the pull request carries everything that was tested and, once you approve in Slack, merges it.
Where there is an app to run, OG can also spin up a running instance and share a live, sign-in-protected preview URL — see Preview links & localhost access.
Approvals and access
- →Merging a pull request, pushing to
main(ormaster) and force-pushing pause for explicit human approval every time. Opening a pull request pauses for approval too, unless a person on your team in the thread has chosen to approve all of them. Ordinary pushes to the agentic worker's own working branch don't stop to ask. See Gated actions. - →Merging is not autonomous — it requires your explicit approval in Slack.
- →Write access is scoped to the specific repositories you authorise.
- →Git activity is audited — logged with the context of the agentic worker's task, timestamped and team-scoped, exportable to CSV.
Your code and LLMs
When an agentic worker writes code or reviews a PR, the relevant code is sent to the LLM for processing. We use the providers' commercial APIs — Anthropic, OpenAI, and Google — under business terms that prohibit training on your code. See the FAQ and the Privacy Policy.