You provide
- The result you want.
- Behavior that must not change.
- How you'll know it worked.
- Anything that needs your judgment.
Learn
You describe the change. The agent runs the workflow.
After ait init, ask for what you want in plain language.
The repository instructions tell an AIT-aware coding agent how to plan
the work, isolate it, check it, record it, and complete it.
- The outcome is yours
- The work is the agent’s
- The record is AIT’s
Responsibility
Your part is the request and what counts as done.
You don't have to drive
- Writing the sprint card.
- Starting the Task or entering its worktree.
- Remembering which workflow command comes next.
- Closing the sprint item after the Task finishes.
Agent execution
One request becomes one record you can read.
- Write the sprint card. The agent notes the outcome, the scope, what counts as done, and one exact checklist reference.
- Start the Task. AIT binds that checklist item and creates an isolated worktree for it.
- Change the code. The agent edits only inside that worktree, so unrelated work stays untouched.
- Run the checks. Your project's own tests, build, lint, or whatever else it declares — that's the evidence.
- Create a Snapshot. AIT records the exact revision that passed those checks.
- Finish the Task. The change goes in, the target line moves forward, and the sprint item that asked for it closes.
The Interactive Demo runs the whole password-control example: sprint item, Task receipt, diff, test output, Snapshot, and closeout receipt.
A real one
This is what an actual session left behind.
$ ait task start … --intent '…' --local --json
{
"ok": true,
"task_id": "LT-0001",
"line_name": "feature/lt-0001",
"next_action": { "code": "enter_worktree", "command": "cd …/workspace/lt-0001" }
}
$ npm test
AssertionError [ERR_ASSERTION]: cooldown must block rapid fire
2 !== 1
# the agent edits src/game.js inside the worktree, then reruns the checks
$ npm test
{"contract":"ait-plane-shooter-self-test/v1","status":"pass"}
$ ait task finish LT-0001 --message 'Restore the 180 ms projectile cooldown
and add exact boundary regression coverage; npm test passes.' --local --json
{
"ok": true,
"command": "task.finish",
"task_id": "LT-0001",
"target_line": "main",
"closeout": { "task_status": "completed", "worktree_status": "removed", … }
}
Abridged but verbatim: these lines come from admitted session
b001-gd-01 of the published
200-session benchmark (2026-08-26).
Long runtime paths are shortened and elided fields sit under the
… marks; every line shown is as recorded.
What AIT leaves you to look at
Why this change exists
The Task stays tied to the sprint item that asked for it.
Where the work happened
The Task gets its own worktree instead of mixing into unrelated edits.
Which revision passed
The Snapshot pins the exact code that went with those check results.
What was completed
The Task, the target line, and the sprint item all end up saying the same thing.
Try it with your own request
Install the current stable release, initialize one repository, and let the agent carry your first change through verified closeout.