Nisi
A workflow for AI-assisted coding
CLI and library, v0.3.0. A bounded workflow for proposed changes, checks, tests, review and a recorded outcome, with optional Jev analysis for local models.
CLI and library · Node.js 22+v0.3.0
- draft
- check
- test
- review
- repair
A coding workflow
with an inspectable outcome.
Your application supplies a task and its drafting, validation and review adapters. Nisi coordinates the stages within a deadline and repair limit, then returns proposed files and a report. Applying a change remains the application's decision.
A proposed change, a recorded decision,
and a host that stays in control.
How a run works.
An application sets the task and supplies its own authorization, author, check, test, and reviewer adapters. Nisi coordinates them and returns proposed file contents with a report.
Bound the task
Set allowed files, criteria, deadline, and repair budget.
Authorize context
Host policy decides whether the task's context may be used; a refusal stops the run.
Draft a candidate
The author proposes file snapshots without applying them.
Check, then test
Static checks pass before tests run on that candidate.
Review separately
Declared reviewer IDs differ from the author ID.
Return a report
Passing evidence returns proposed files and a run report.
Return to the author for repair. Failed checks, tests, or review can return to author repair when available and within budget. A repaired candidate repeats checks, tests, and review.
Stop path: Refused context, no valid candidate, missing evidence, unavailable repair, a repair that changes nothing or repeats an earlier candidate, exhausted budget, cancellation, or deadline ends without completion; the report records the outcome.
COMPLETED result does not apply files. Sources: Nisi v0.3.0 README ↗ (opens in a new tab) and workflow API ↗ (opens in a new tab).What a run leaves behind.
A report you can inspect
The report shows the proposed files, check results, and why a run stopped. The host decides whether to apply any change.
A journal you can reopen
The optional append-only journal uses a hash chain. A host can store it, reopen it after a restart, and check its internal consistency (not authenticity).
What a run returns.
Nisi coordinates adapters supplied by your application and returns proposed file contents with evidence for each stage.
node bin/nisi.mjs demo intentionally starts with an incorrect JavaScript module, repairs it once, reruns its checks, obtains a separate review result, and writes, verifies and removes a report. Its documented output includes:{
"outcome": "COMPLETED",
"repairAttempts": 1,
"reportStored": true
}Bind the task before drafting
Allowed relative files, acceptance criteria, protected snapshots, deadline, repair budget, and reviewer count become part of a task fingerprint. A candidate is a proposed file snapshot, not an applied patch.
Task contract ↗ (opens in a new tab)Keep stage evidence separate
Checks, tests, and reviews report their own status and evidence against the current candidate fingerprint. Malformed or mismatched records block completion; a repaired candidate goes through fresh checks, tests, and review.
Evidence schema ↗ (opens in a new tab)Reopen the journal after a restart
The optional hash-chained journal distinguishes a fresh run from stale, expired, or revoked records. Its disk store reports whether a write committed and whether durability was confirmed.
Journal and store ↗ (opens in a new tab)Measured on 16 harder tasks
New in v0.3.0, both optional: a reasoningEffort setting for local chat models, and an advisor that asks Jev, TypeSafe’s hosted model, to pick reasoning settings per task. You supply the call and the key, and your call decides what is sent: the task’s id, mode, language, allowed files and criteria, and for the optional Jev reviewer also the candidate’s files and whether the tests passed. With one 27B model, the adapter defaults solved 14 of 16, as did a single unchecked draft and the Jev plan. The plan’s shorter time came almost entirely from one task both runs got wrong, so these single runs show no accuracy or speed gain.
Try a configured local-model example
The separate local-model command sends one fixed JSON task to a loopback chat server using two differently named author and reviewer models. It checks four assertions and treats the JSON as data; the server and models are supplied separately.
Run the demo.
Needs Node.js 22 or newer. The demo repairs its example once and verifies a report it writes to a temporary folder, then removes. Clone the tagged source and run:
git clone --branch v0.3.0 --depth 1 https://github.com/louiscalata/nisi.git
cd nisi
node bin/nisi.mjs demoThe demo makes no model calls.
