artifact chain
intake -> spec -> task -> review -> finding
Intent becomes a requirement.
The task bounds what may change.
The run pastes evidence.
The review routes exceptions.
The finding preserves what the next task should know.
What is corpus
A lightweight spec-and-review workflow for teams using coding agents. corpus turns intent into files an agent can run and a human can verify.
pwrcheckevidence
diagnostics$ cat what-is-corpus.md
corpus is a spec-and-review workflow for teams using coding agents. Turn tickets into clear specs, specs into agent-ready tasks, and agent output into evidence a human can review.
✓ agent does the typing
✓ human makes the call
✓ every claim needs evidence
✓ plain markdown, any agent, no runtime
$ _
example
what it is
What corpus is
- a spec format humans write and agents work from
- a task-packet format that bounds agent work
- a review-packet format that shows where human attention goes
- a findings convention so lessons survive the session
- a starter kit of markdown templates
- a workspace convention
what it is not
What corpus is not
- an agent or agent runtime
- a compiler
- a programming language
- a Jira/Linear replacement
- a code generator
- a replacement for PRs and CI
- a docs portal
- a complete SDLC platform
- a formal verification system
- a guarantee that agent output is correct
- permission to skip review
- a way to treat plausible output as proof
- a way to remove humans from decisions
nearby tools
Where corpus sits
Coding agents
Claude Code, Cursor, Copilot, …
Does: write the code
corpus ships no agent. It shapes the inputs any agent works from and the output you review. Bring whichever agent you have.
Spec-driven workflows
Does: turn a written spec into an implementation
Same family, different job. They help author the spec and generate code; corpus focuses on the review side — every requirement carries a verification method, and the packet shows the evidence per requirement.
Issue trackers
Jira, Linear, GitHub Issues
Does: hold the backlog and the conversation
The ticket stays where it is. corpus snapshots it into an intake file and interprets it into a spec an agent can act on.
Docs portals
wikis, Notion, docs sites
Does: describe the system after the fact
A corpus spec is a working document — acceptance criteria, verification methods, open questions. It drives the change rather than documenting it later.
Review tooling
PRs, CI, review bots
Does: check the merge
corpus does not replace the PR. The review packet rides alongside it and tells the reviewer where to look; CI output is the evidence the packet cites.
Refactoring tooling
codemods, OpenRewrite, …
Does: execute mechanical change
corpus's change plan states what must survive the change and how to check it; a codemod is one way a task executes a step of that plan.
common failure modes
Failure modes you are already seeing
Drift
the agent solves a problem, not the problem
> the task packet: an explicit scope and a 'Do not change' list
Ambiguous input
ambiguity degrades generated code, and models do not reliably flag it
> requirements written one per ID, each with its own verification method
Lost handoff
the plan-to-implementation handoff is a leading failure surface (on preliminary evidence)
> the handoff is a written, bounded task packet — not a chat message
Hallucinated completion
'done,' but nothing was checked
> a Pass needs pasted output, a CI link, or a named human's recorded observation
No resumable trail
the session ends mid-stride; the next one starts from zero
> work externalized to files — intake, spec, task, review
Repeated mistakes
the same class of bug returns every few sessions
> findings saved at Close, kept where the next task will look
See how it actually runs
Six steps, each producing a file the next one reads. That is the whole framework: no runtime, no automatic decision.
Source: docs/01-what-is-corpus.md