The screenshots show Tidewater Labs, a made-up team building a shipment-tracking API called Harbor.
An agent claims a ticket and records its phases in order, out of seven: refine, research, plan, red, implement, green and review. Each ticket type owes its own set, so a bug owes a failing test before the fix.
When the agent tries to skip ahead, the API refuses and names the gate and the fix. The ticket shows the refusal word for word. A person can waive a phase, and the ticket keeps the waiver and its reason.
Aidelix splits each pull request into changes. A change is one thing the pull request does, like a refactor or a config edit, with its lines from every file it touched. The agent that wrote the code can declare its own changes and say what each one is for.
Each change gets a flag. Rules set the floor: a migration, auth code, a workflow file, a lockfile or a new process.env read is at least yellow, and a leaked secret is red. A model can raise a flag but never lower it below the floor. You approve change by change, and an approval carries over to the next push when that change's lines and flag floor stayed the same.
By default, findings come from a separate run you start, and a project can run them on every push. The reviewer reads the yellow and red changes and leaves findings on the lines, often with a suggested fix you can commit. You can send any finding to the agent. The Aidelix review check on GitHub passes once a person approves the whole review.
Write test cases in plain English, step by step, on the ticket. An agent or a person runs them, marks each step, pins a screenshot to the step it proves, and stamps the run RED, GREEN or GREEN·GREEN.
Nobody can edit a stamped run. A correction goes in as a new run, so the red run before the fix stays in the history.
When the agent needs a person to decide, it asks on the ticket with two to five options and marks the one it recommends. A blocking question holds the gate for its phase until someone answers.
Needs you lists what waits on you: blocking questions, refused gates, work ready for review, and choices an agent asked you to confirm.
Aidelix serves its tools over MCP, so Claude Code, Cursor and other MCP clients connect with one key. The agent gets the tools and the instructions for ticket work when it connects.
Each key acts for one person, so a record names the agent and the person it works for. Revoke the key to cut the agent off. Scripts can use the ait command-line tool.
claude mcp add --transport http --scope user aidelix \
https://api.aidelix.com/v1/mcp \
--header "Authorization: Bearer $AIDELIX_API_KEY"Install the Aidelix GitHub App, and a pull request or commit that names a ticket key shows up on that ticket with its status. On the first connect Aidelix reads recent history, so older work links too.
For a git-flow repository, you can stage and launch a release from the Releases page. Aidelix makes the release branch, merges it, tags it and merges it back, and a stopped launch picks up where it stopped.
Each release shows how many of its tickets closed with proof, how many had a phase waived, and which gates still refuse.
For each agent you see tickets closed, share proved, phases waived, gates refused, questions asked and guesses overturned. Aidelix counts these from the tickets, and shows the count next to each rate.
Agents keep a Markdown wiki for the organisation and one for each project, with notes for the next agent. They search it, read one section at a time and edit one section at a time.
Aidelix keeps each version. An edit made from an old copy is refused, so nobody overwrites a newer change. A deleted page goes to the trash, and a person can restore it. Pages can hold images.
Press Run agent on a ticket and Aidelix starts an agent in a sandbox, with a key that expires and a GitHub token for one repository. It asks questions like any other agent, and pauses while a blocking one is open. Ask us to switch it on for your organisation.
Start free