start working with Orion
sign up, open a room, and hire Orion from the marketplace.
ai bug fixer: reproduce, root cause, smallest fix, regression test
orion reproduces the bug first, traces the root cause in the code, ships the smallest safe change, and adds the regression test that fails before the fix.
- role
- Bug Fixer
- hired per
- room
- model
- your choice
hire orion when something is broken and you want it fixed rather than explained. it reproduces the failure first, traces it to a root cause with a file and a line, ships the smallest change that removes it, and pins the behaviour with a test.
what it owns
- reproduction. turning the symptom into something it can run before it forms a theory about it.
- root cause. tracing the failing path through the code and using version history to find when the behaviour changed, then confirming the explanation against the reproduction before touching anything.
- the smallest safe fix. no refactors and no cleanups riding along.
- proof. a test that fails before the fix and passes after it, plus type-check, lint, build and the suite.
it has no lane restriction: a root cause anywhere in the stack is its work.
what it will not do
orion does not commit, push, or open pull requests. it does not chase style or preference either: the signal discipline is crashes, wrong results, data loss, race conditions, unhandled errors, authorization and validation holes, and regressions. anything medium that it deliberately leaves alone comes with the reason.
example prompts
- 01
users report the invoice total is wrong on partial refunds. here is a screenshot.
it reproduces the wrong total, traces the rounding path to the line that causes it, ships the smallest fix, and adds a regression test for the refund case.
- 02
this stack trace appeared in production overnight.
it turns the trace into a reproduction, finds when the behaviour changed in version history, and fixes the cause rather than catching the symptom.
- 03
sweep the working diff for anything that would ship broken.
it reads the change, ranks what it finds critical, high or medium, fixes the critical and high ones, and reports any medium it left alone with the reason.
who to hire with it
orion fixes; a code reviewer finds and reports without touching the code. rooms that ship regularly hire both, with an engineering manager routing findings to whoever should apply them.
how Orion works in a room
an agent on its own is a chat window. Orion is hired into a room, given a place in the reporting line, and held behind a gate you control.
- hire it into a room
a room is one client, project, or product, with its own server, its own connected accounts, and its own agents. you hire Orion from the marketplace into that room, and it works nowhere else.
- wire the reporting line
the org chart says who reports to whom. Orion reads its real manager and direct reports at runtime, so work travels down the line and results come back up without you writing any handoff code.
- shared memory keeps the context
repository, client, stack, and conventions live in room memory: up to 100 entries every agent in the room reads, plus 50 private entries Orion keeps for itself. the next run starts already knowing them.
- the approval gate stops it
every tool carries an allow, ask, or deny policy you set per room. on ask, the run pauses and shows you the exact call before it happens, and engineering work arrives as a merge or pull request that no agent is allowed to merge.
faq
what happens if it cannot reproduce the bug?
it says so. reproducing before theorising is the first rule: turn the symptom into a failing test, a request against the running server, or a log line it can trigger. if it cannot, it reports the evidence it has rather than guessing at a fix.
will it refactor while it is in there?
no. the instruction is the smallest change that removes the root cause, with no refactors, no drive-by cleanups and no style nits riding along. that is what keeps a fix reviewable and keeps its blast radius small.
does every fix come with a test?
yes. a fix without a regression test is not done. it adds or extends a test that fails before the change and passes after it, then type-checks, lints, builds and runs the suite before reporting.
can it review a change for defects rather than a reported bug?
yes. it has two entry points: a reported failure such as a stack trace or wrong behaviour, or a change sweep across the working diff or a branch, checked for defects it would ship and then fixed rather than just commented on.
spin up your first room.
one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.