Integrations
Works across the apps your team already ships with.
GitHub, Jira, Linear, Slack and any MCP-capable editor. Connect once, scope it, and a label starts the line.
Connect once
Connect an app once. Scope it. A label does the rest.
The connection lives in the control plane, not in a repository. Three steps, then the line runs.
- 01
Authorise as the app
GitHub as an App installation, Linear as the application actor, Jira over OAuth with a refresh grant. Nobody's personal token, and the control plane holds every credential — an agent session never sees one.
your engineer - 02
Scope by repository, project or team
GitHub to one repository, Jira by project key, Linear by team and project independently. An empty scope means every project on the site — set it deliberately.
your engineer - 03
A label or a transition starts a change
A labelled GitHub issue starts a change; a Jira transition does too; so does a Linear assignment. The change runs the same line whichever app started it.
agent
What starts work
What starts work, app by app.
The event as it arrives, in the API's own spelling, and the change it becomes.
Turn a labelled issue into a reviewed pull request.
The delivery is verified over its raw body and recorded once, so a replay does nothing. One change per issue, linked once; the automation is pinned when the change starts.
- 01
github.issue.labeleda label is added to a GitHub issue - 02
github.pull_request.readya GitHub pull request is marked ready for review - 03
github.pull_request.commentsomeone mentions @devbyte on a GitHub pull request - 04
github.check_run.faileda GitHub check run fails on a Factory pull request
Every connection
Five connections, and what each one does.
- GitHubA labelled issue starts a change; the pull request lands back with one check run.github.issue.labeled · github.pull_request.ready · @devbyte
- JiraA label or a transition starts a change, scoped by project. It writes back on the issue as the app.jira.issue.labeled · jira.issue.transition · @devbyte
- LinearA label or an assignment starts a change, scoped by team and project. It writes back as the application.linear.issue.labeled · linear.issue.assigned · @devbyte
- SlackA sign-off request arrives with Approve and Request changes. One thread per change.slack.message · Approve · Request changes
- MCP editorsClaude Code, Cursor, JetBrains — any MCP client, over StreamableHTTP. Starts a change; never clears its own sign-off.start_task · file_governance · POST /mcp
- Who may approveroles
- Organisation and project roles decide who may sign off.
- Who did whataudit
- An audit trail records who approved, started, overrode and changed what.
- Where the configuration livesconfig
- Automations, roles, budgets and thresholds live in the platform, versioned and audited — never in a tracked file, so a pull request cannot widen the permissions of the agent that wrote it.
- What a role may touchroles × tools
- Each agent role declares its tools, mount mode and secret scopes.
Admin controls
Decide who may approve, and prove who did.
Four things an organisation admin holds, and none of them lives in a repository where a pull request could change it.
Connect DevByte to the apps you use.
Connect once, scope it, and label the next issue. The pull request arrives with its audit trail.
Can't find an app your team uses? Request a connector →