It reads, within your scopes
Steelax requests the narrowest permission that makes the integration useful, and you choose which projects, spaces and repositories are in range. Anything outside that range is invisible to it.
Integrations
Steelax is only as good as what it can see.
Connect the systems your team already runs on. Steelax reads them to build a working picture of your product, and writes back only into the places you explicitly allow it to.
Grounding
Three things happen when you connect a system.
It builds a product model
Issues, documents and source are indexed into one structure that links them: this spec describes that flow, which lives in these files, and was last changed by that pull request.
It reports the gaps
After the first index you get a plain list of what Steelax can and cannot see. No silent blind spots, because an answer built on a missing system is worse than no answer.
Nothing is written back until you say so
Every integration starts read-only. Creating issues in your tracker and pushing branches to your repository are separate permissions, requested later, and either can be declined without affecting the rest of the product.
Issue trackers
Where your work already lives.
Steelax reads your backlog to understand what has been tried, what was abandoned and what is in flight. With write access granted, generated tasks are published straight into it.
| Tool | What Steelax reads | What it can write |
|---|---|---|
| Linear | Issues, sub-issues, projects, cycles, labels, comments, status history | New issues and sub-issues, labels, project assignment, links |
| Jira | Issues, epics, sprints, components, custom fields, comments | New issues and sub-tasks, epic links, components, labels |
| GitHub Issues | Issues, milestones, labels, linked pull requests, discussions | New issues, labels, milestone assignment, cross-references |
| Asana | Tasks, subtasks, projects, sections, custom fields | New tasks and subtasks, section placement, links |
| Azure Boards | Work items, area and iteration paths, states, links | New work items, parent links, area and iteration assignment |
Documents and specs
The intent you wrote down.
Documents are treated as the record of what was intended, not the record of what exists. Where a document and the code disagree, Steelax reports the conflict instead of choosing a side.
| Tool | What Steelax reads | Notes |
|---|---|---|
| Notion | Pages, databases, properties and comments in the spaces you share | Read-only. Database properties are used to date and group specs. |
| Confluence | Spaces, pages, page history and labels | Read-only. Page history is used to judge how current a spec is. |
| Google Docs | Documents in the folders you share, including revision dates | Read-only, through a shared drive or explicit folder grant. |
| Markdown in repository | Any markdown in the connected repository, including decision records | Picked up with the code. Often the most accurate source you have. |
Code repositories
The authority on how the product behaves.
Source is the only artefact that cannot drift from reality. Steelax reads the connected repositories to answer questions about behaviour, to scope tasks against files that actually exist, and to give the coding agent somewhere to work.
Connect a monorepo scoped to the directories your team owns, or several repositories at once. Steelax links work across them, which is how a problem in checkout gets traced to a deploy in a payments service.
- Default branch and open pull requests, within the scopes you grant
- Commit history for the files relevant to a question
- Test files, so coverage gaps show up in scoping
- Build and CI configuration, so the agent runs your checks and not its own
| Host | Read | Agent branches |
|---|---|---|
| GitHub | Cloud and Enterprise Server | |
| GitLab | SaaS and self-managed | |
| Bitbucket | Cloud | |
| Azure Repos | Cloud |
On Azure Repos Steelax reads code and scopes tasks against it, but the coding agent does not yet push branches there.
Design
Flows as they were drawn.
Connect Figma and Steelax reads file structure, frame names and prototype links from the projects you share. That is enough for it to tell which states were designed, and more usefully, which states exist in the code but were never drawn.
It does not read pixels or produce design work. The value is in the comparison: a redesign that starts from how the flow is actually implemented is a shorter redesign.
- FI Figma projectsFrames, flows and prototype links Read only
- CO Implemented statesFound in the connected repository Compared
- DO Written specsMatched against both Compared
Permissions
Exactly what each permission is for.
Three tiers, granted separately. Most teams spend their first weeks entirely in the first one.
- Tier one: read
- Required to use Steelax at all. Lets it answer questions, trace features, compare specs against the build and shape work. Nothing in your systems changes. This is where every account starts.
- Tier two: publish tasks
- Lets Steelax create issues in the tracker projects you nominate. It creates and links issues. It does not close, reassign, reprioritise or delete anything that already exists.
- Tier three: agent branches
- Lets the coding agent push branches and open pull requests in the repositories you nominate. It never commits to a default or protected branch, and it cannot merge, approve or alter branch protection rules.
- Revoking access
- Any tier can be withdrawn from the workspace settings or from the connected tool itself. Access stops immediately. Issues and branches already created are yours and stay exactly where they are.
Running something we do not list yet?
Tell us what your team runs on and what you need Steelax to read from it. Integration work is prioritised by what customers actually ask for, and we will tell you honestly whether it is weeks away or not planned.
Questions
About connecting your systems.
How current is the index?
Trackers and repositories update through webhooks, so changes land within a minute or two of happening. Document tools are polled on a schedule, typically a few times an hour. When an answer depends on something that changed very recently, Steelax says when it last saw the source.
Can we limit it to one team's projects?
Yes, and it is the usual way to start. Scope the tracker to specific projects, the docs tool to specific spaces, and the repository to specific directories. Steelax works from what it has and tells you where its picture is incomplete.
Does it need access to production systems or customer data?
No. Steelax connects to development artefacts: issues, documents, source code and design files. It does not connect to production databases, customer records or live traffic, and it has no mechanism for doing so.
What about self-hosted GitHub or GitLab?
Both are supported. Self-managed instances need network access from our environment to yours, which is normally handled with an allowlist on your side. It is a short conversation during onboarding rather than a project.
Connect one tracker and one repository.
That is genuinely enough for a first session. Everything else can follow once you have seen what it does with the systems you already have.
Read-only to beginWrite access is a separate decision you make later.
Scoped to your choiceSpecific projects, spaces and directories, not the whole account.
Revocable at any timeFrom our settings or from the connected tool itself.