OpenSpec, GitHub Spec Kit, BMAD and superpowers capture what you meant to build for your AI coding agents. dira and zavet record what happened next: who followed the plan, what it cost in human and agent time, and whether the spec was rewritten to match the code.
A spec says what should be built and how. Once the agents start, the spec has no way to say whether anyone followed it. That is not a flaw in the frameworks: a planning tool is not supposed to audit itself.
A task is ticked off by the same agent that claims to have finished it. The checkbox is a claim, and nothing witnesses the session behind it.
A spec comes with a task list and no hours. Nobody can say how much human supervision, how much agent time and how many tokens a change took.
OpenSpec’s archive step rewrites the canonical spec from a change’s deltas, and any agent can edit a spec in the pull request that implements it. Nothing checks that the rewrite matched what shipped.
A spec without a chronicle is an unaudited promise, and a chronicle without a spec has no unit of intent to hang the hours on. See where this sits next to the other tools in the letopis comparison, or read how the four books fit together in letopis, the whole chain.
zavet resolves each unit of your framework into a living spec. dira joins that spec to the sessions, minutes and tokens behind it. More on zavet spec sources.
zavet detects which frameworks your repo uses and writes one spec-source line for each into .zavet/config. It is committed, and the adoption is recorded as a decision. dira onboard sets it up in the same pass.
A commit names the spec it belongs to with a Spec: trailer. The trailer is the only link between work and spec, so the record never relies on a guess.
dira joins the commit to the session that produced it and attributes human time, agent time and tokens to that spec. Sessions that never produce a cited commit stay unattributed.
The dashboard shows which framework each project uses, each spec’s state, task progress as the framework’s own checkboxes, and the drift facts below.
Each one is observable and re-derivable from your repo. Each one is a fact to look at, not a finding that anything went wrong.
A file a task named that no commit touched.
A file changed under the spec that no task named.
The spec itself changed in the same pull request that implemented it.
A spec nothing has been cited against, so it covers nothing and is not counted as covered.
Each adapter parses structure only: folder names, headings, ids and checkbox state. When a unit cannot be read it is reported as unresolved, with the reason, rather than guessed.
Change folders with proposals, tasks and delta specs, archived when they ship.
1/4 tasks checked in tasks.md
3 sessions · 2h 08m human · 3h 48m agent
Numbered feature folders: a spec, a plan and a task list per feature.
2/5 tasks checked in tasks.md · 1 needs clarification
3 sessions · 2h 08m human · 3h 48m agent
An initiative tree of epics and stories with their own status and plans.
1/4 stories done in tickets
3 sessions · 2h 08m human · 3h 48m agent
Design documents and step-by-step plans written by the agent workflow.
2/3 tasks checked in the plan
3 sessions · 2h 08m human · 3h 48m agent
Names and repositories belong to their owners. They are used here only to say what is read.
No product in letopis states an opinion, only records that can be checked again. “Requirement implemented” reads like a fact and is an opinion, so it is never written. “Tasks done” is the framework’s own checkbox, recorded as the framework’s claim.
No. Keep OpenSpec, GitHub Spec Kit, BMAD or superpowers exactly as you use them. dira and zavet read the files your framework already writes and keep a record beside them. There is no new spec format to adopt and nothing to migrate.
No. Spec sources are read-only. zavet notes which frameworks it found in its own .zavet/ folder, and everything else it learns is derived from your repo and your commits. Your framework’s own commands remain the only thing that writes to its folders.
By default, metadata only: spec ids, states, requirement and task counts, task ids with their done flags, and the paths of files touched. Requirement text, task text and the spec documents themselves are sent only if you explicitly turn on full knowledge sync. With sync off, nothing leaves your machine.
Yes. Spec attribution sits on top of dira capture, which records sessions from Claude Code, Codex CLI, Gemini CLI, Cursor, OpenCode, Grok Build. The harness does not need to know about your framework: the link between work and spec is the Spec: trailer on the commit.
A plan made in an agent’s plan mode is a session artifact: approved, executed and gone. It is not a file with an id, so it is not captured and there is nothing to cite in a commit. Write the plan into your framework’s files and it becomes something the record can follow.
Carry a Spec: trailer naming the spec, such as Spec: openspec:add-csv-import. Several specs go in one comma-separated list. Work without a trailer stays unattributed. It is never guessed from a branch name or a file path.
No. dira and zavet record facts that can be checked again: which spec a commit cited, how many tasks the framework marks done, which files were touched that no task planned, and whether the spec was edited in the same change that implemented it. They never say that a requirement is satisfied, and they never produce a score.
New to the suite? Start with getting started, or read how zavet records decisions and how letopis compares with the tools you use today.
One command, dira onboard, sets up both books in a single pass, and it works offline.
Get started free →