It will not merge anything
The agent opens pull requests and stops. Merging, deploying and releasing stay with your team and your existing checks. Steelax has no write access to your default branch at any point.
Platform
One workspace for the whole path, from a sentence in standup to a merged branch.
Steelax is organised around four stages that mirror how product work actually happens. Each one inherits everything the stage before it learned, which is the whole point: context moves forward instead of being rebuilt at every handoff.
Stage 01
Understand the product you already have.
Before Steelax writes anything, it reads. Connect your issue tracker, your documents and your repositories, and it builds a working model of the product as it stands: which flows exist, which decisions were recorded, which parts of the code handle what.
Ask a question in plain language and the answer comes back with its sources attached. Not a summary of what products like yours usually do, but what yours does, in the files that do it.
- Trace a feature across tickets, specs and source in one place
- Every claim is backed by a file path, a document or an issue
- Conflicts between the spec and the code are reported, not smoothed over
- Gaps are stated plainly when Steelax cannot see a system
PM
How does password reset work today, and what happens if the link expires?
SX
Reset tokens are issued in auth/reset.ts with a 30 minute expiry and are single use. An expired link lands on a generic error page with no way to request a new one, so most users start over from the login screen.
The spec from March describes a resend option. It was never built. That is the gap worth deciding on.
- CO auth/reset.tsToken issue and expiry
- DO Account recovery specWritten March, partly implemented
Stage 02
Shape half-formed intent into work you can build.
Bring a rough idea, a vague complaint or a wouldn't-it-be-nice. Steelax works it into shape the way a good staff engineer would: by asking what problem this actually solves, checking the idea against how the system behaves, and naming the assumption that will cause trouble in week three.
It holds your stated strategy in view while it does it, so the version that survives is the one that fits where the product is going, not just the one that is easiest to describe.
- Pressure-test an idea before it ever becomes a ticket
- Validate a written spec against the behaviour in the build
- Narrow a fuzzy goal into a scope the system can support
- Keep the rejected options and the reason they were rejected
PM
Checkout conversion dropped about twelve percent last week. Can we add a retry button on the failure screen?
SX
A retry button treats the symptom. In CheckoutForm.tsx the form remounts on a declined charge, so card details are cleared before the user ever sees the screen. They are not choosing to abandon, they are being asked to type it all again.
There is a second issue underneath: the charge endpoint is not idempotent, so a retry can double-charge.
Proposed scope. Preserve form state on failure, make retries idempotent, surface the real decline reason. Retry button follows for free.
Stage 03
Turn the agreed scope into structured tasks.
When the shape is right, Steelax writes the work. Tasks come out linked, grouped by the layer they touch, and carrying everything a developer or an agent needs to begin: the reasoning, the files, the edge cases, and the decisions still open.
Push them into the tracker your team already uses. They arrive formatted for that tracker, with the labels and the project you chose, and a link back to the session that produced them.
4 linked tasks1 blocked on a decision
UIPreserve card details through a validation errorCheckoutForm.tsx
LOGICMake charge retries idempotent by request keypayments/
APIPass gateway decline reasons through to the client3 files
DATASplit drop-off metrics by failure typeevents
Held back. Decline reason wording is shown to customers and may need legal review. Steelax flagged it instead of writing copy.
What is inside a generated task
Every task Steelax writes has the same six parts. This is the difference between a ticket somebody can start and a ticket somebody has to chase.
- The problem
- What is actually wrong or missing, in terms of the user and the system, separate from the proposed fix.
- The approach, and the ones rejected
- The route chosen, plus the alternatives considered and why they were set aside. This is the part that usually dies in the handoff.
- Files and surfaces in scope
- The modules, components and endpoints the change is expected to touch, drawn from the connected repository rather than guessed.
- Edge cases and failure states
- What happens on error, on an empty state, on a slow network, and anywhere the existing code already handles something unusual.
- How to tell it worked
- A plain description of the expected behaviour after the change, written so a reviewer can check it without reading the diff first.
- Open questions
- Anything Steelax is not confident about, named explicitly, assigned to a person rather than quietly resolved.
Stage 04
Hand the task to an agent that knows the codebase.
Delivery is where most tools stop and a person starts again from zero. Steelax includes a coding agent that takes a generated task, clones the connected repository into an isolated environment, reads the code around the change, implements it and runs your test suite.
You decide which tasks are worth handing over. The agent works on a branch, never on your default branch, and stops to ask when the work turns out to be bigger than the task described.
- Short-lived, scoped credentials issued per run and revoked after
- Every command and file touched is recorded in a run log
- Output arrives as a pull request, linked back to the task
- Take it over by hand at any point with the context intact
started task LOGIC: idempotent charge retries
clone payments-service into isolated sandbox
read src/payments/charge.ts, src/payments/gateway.ts
found retry path reuses no request key
+ const key = idempotencyKey(order.id, attempt)
+ return gateway.charge(payload, { key })
- return gateway.charge(payload)
tests 86 passed, 2 added, lint clean
open question: expiry window for stored keys
Pull request opened
Awaiting review
Capabilities
What the workspace does, stage by stage.
The full list, so you can tell at a glance whether Steelax covers the part of the process you care about.
| Stage | Capability | What it produces |
|---|---|---|
| Understand | Grounded product questions | An answer with the files, issues and documents it came from |
| Understand | Feature tracing | The path of one feature across spec, tickets and source |
| Understand | Spec and build comparison | A list of differences between a document and the running code |
| Understand | Behaviour diagnosis | A likely root cause for a metric or bug, with evidence |
| Shape | Assumption checking | The assumptions behind an idea, and which ones the system breaks |
| Shape | Scope proposals | A scope that fits the current architecture, with the cut lines marked |
| Shape | Strategy alignment | A note where the proposal pulls against your stated direction |
| Generate | Linked task sets | Tasks across interface, logic, integration and data |
| Generate | Tracker publishing | Issues created in your tracker with labels, project and links |
| Generate | Decision flags | Work held back until a named person resolves the question |
| Deliver | Agent implementation | A branch with commits, in an isolated environment |
| Deliver | Test and lint runs | Your own suite, run before anything is offered for review |
| Deliver | Pull request handoff | A pull request linked to the task and the session behind it |
| Deliver | Run logs | Every command, file read and file written during the run |
Boundaries
What Steelax will not do.
A tool that claims everything is useful for nothing. These are deliberate limits, and we would rather you knew them before you connect anything.
It will not decide for you
Questions involving pricing, legal exposure, customer-facing wording, security posture or product direction are flagged and routed to a person. Steelax states the options and the trade-offs, then waits.
It will not invent context it does not have
If a system is not connected or a question cannot be answered from the evidence, Steelax says so. It does not fill the gap with a confident guess, and it never presents an inference as a finding.
It will not replace your tracker or your repository
Steelax writes into the tools you already run on. There is no second backlog to maintain and no migration to perform. If you stop using Steelax tomorrow, the work stays where it already lives.
See it run against your own product.
The fastest way to judge Steelax is to point it at something your team is already arguing about and watch what it says.
Bring a real problemA stalled spec, a metric that moved, a flow nobody fully understands.
Connect read-only firstOne tracker and one repository is enough for a useful first session.
Keep the outputAnything created during the session stays in your tracker.