Artifactize
The AI-native collaboration layer for one-of-a-kind teammates and their agents.
Artifactize splits a project into Artifacts (code, docs, designs, images), each with its own evals: tests, LLM reviews, human sign-offs and derived dependency checks. Every teammate, human or agent, works their own way on their part, and integrating that work reuses each review while its eval definition, covered Artifact kinds and fingerprints match. Earlier GREEN or RED results are reused. Artifactize is open source under the Apache License 2.0 and runs on Linux, macOS and Windows.
Why I built it
Building games with AI, working alone got fast, but working with others still felt like hitting a wall. There had to be a sweet spot between traditional development and AI-native work. So I looked for a way for every teammate, human or agent, to keep their own style and still add up to one coherent result, and I structured the project around evaluation.
Artifactize is that collaboration layer: it splits a project into modules that each carry their own evaluation criteria, so everyone can work their way, and it cuts the evaluation cost wasted during integration.
See it in your terminal
Change one file: status predicts one execution and names the file, and verify
re-reviews only that Artifact.
How it helps a team
- Each part carries its own bar. An Artifact declares the evals that judge it: runtime evals run commands; Agent evals ask one exact model (OpenAI or Anthropic API key, or a ChatGPT/Codex sign-in) with the read-only tools you declare; Human evals wait for a sign-off; dependency evals derive readiness from other Artifacts' required evals without executing anything. RED blocks what depends on it. Whoever works on a part, in whatever style, meets the same bar.
- Integration reuses every review that still holds. You define each Artifact's
fingerprint; by default, artifactsum hashes the Artifact's own files.
fingerprint = falsedisables reuse. While the eval and the kinds and fingerprints of the Artifacts it depends on are unchanged,verifyreuses the earlier verdict, from any profile, and reports what it executed, what it reused and the tokens reuse saved. Review cost follows the size of a change. - Centralize the reviews, not the repo. One
artifactize servershares verdicts across teammates' checkouts and CI, so a branch's reviews carry over to the merge and a person signs off a change once. - Know what a change will cost before you run it.
statuspredicts whatverifywill execute, reuse or wait for, and names the files and dependencies that changed. - Human review in the terminal.
artifactize monitordrills down from Scope to Runs, the Run tree and Detail: explicitly claim a sign-off, run tools and submit without leaving the terminal.
Install
Every install provides artifactize, including its current-directory tools as
artifactize tools. Non-Store channels also put artifactize-tools, the same
built-in tools as a standalone CLI, on your PATH. No Rust toolchain is needed.
Linux (x86_64 or aarch64): the script installs the static binaries from the latest
GitHub release into ~/.local/bin. It checks their SHA-256 and needs no sudo:
|
With a Rust toolchain, use cargo binstall artifactize artifactize-tools for the
prebuilt binaries, or build from crates.io
with cargo install artifactize artifactize-tools --locked.
macOS (Apple silicon or Intel): use Homebrew, or the same install script.
Windows (x64): use winget, the
Microsoft Store or
irm https://artifactize.dev/install.ps1 | iex in PowerShell. With Smart App Control
on, use the Store version. In WSL 2, follow the Linux steps.
winget install lhj6102.Artifactize
To update, use the same channel again (brew upgrade, winget upgrade, or run the
script again); the Store updates by itself. Your state is kept.
Install covers every
channel, updating and uninstalling, the prerequisites and the Agent backends.
A tiny example
A folder with an index.artf is an Artifact. A sidecar such as page.md.artf declares
the neighboring file. Both use TOML and require a name. This folder Artifact,
from examples/runtime-relations, checks that a page has a heading. Omitting fingerprint uses
artifactsum, so the result is reusable while the inputs are unchanged:
= "usage"
[]
= "The page has a top-level heading"
= { = "runtime", = "grep", = ["-m", "1", "^# ", "page.md"], = 5000 }
= "Check that {usage} starts with a top-level heading."
No model or API key is needed to try it:
# keep the tour's state apart
The Quick start continues with status, file Artifacts, dependency evals and a
Human sign-off.
A dependency eval can collect readiness without another review:
# player/index.artf
= "player"
= ["scope:player"]
[]
= "Movement and art are ready"
= { = "dependency", = ["player-movement", "hero-art"] }
artifactize verify player/ready includes the required dependency evals without --recursive. The result is
derived from current evidence, not cached or published to the team store. Tags
appear in status, graph and monitor output; they do not change reuse keys. See
Declarations (.artf).
Upgrading to 0.9
Declarations move to TOML index.artf and <file>.artf, with snake_case keys; the
ignore file becomes .artfignore. There is no converter: have an agent rewrite the
declarations and commit them. Families are removed; projects that want templates
generate and commit their own .artf files.
State schema 6 requires a new state directory; there is no migration. Reuse-key v2
matches no earlier result, including in a team review store or with a script
fingerprint. The first full verify reviews every executable eval once, Human
sign-offs included; dependency evals derive their current verdicts.
The terminal UIs share Human Detail and require an explicit c claim. In standalone
review, s no longer opens a verdict popup and Enter no longer submits: use
g/r, then Ctrl-S. Esc stops editing before leaving Detail and never quits.
See Upgrading to 0.9
for the removed keys and state/declaration changes.
Reuse
verify reviews once; the next verify reuses every result whose eval and
Artifact kinds and fingerprints are unchanged and says where each came from.
Fingerprints and reuse · Runs, status and validation
Human review in the terminal
verify waits by default while a Human eval needs a sign-off. The monitor drills
down through Scope → Runs → Run tree → Detail. Its immediate context and preview
panes remain at every width, except at the ends of the drill-down. Side panes take
16, 28 or 36 columns at widths below 100, 100–139 or 140 and above; the focused pane
fills the rest, with sides clipped on extremely small terminals. j/k selects an
eval and reveals its outcome in the peek; Enter or o opens Detail. Press c to
claim a waiting Human request, run the tools its owner declared, choose GREEN or
RED with g/r, and submit the schema-backed form with Ctrl-S. Standalone
artifactize review uses the same Human Detail and keys. i expands the
instruction and t opens Technical while not editing. Esc first stops editing,
keeping the draft, then leaves Detail. A submission resumes the waiting Run's
dependents.
? shows help and ! finds the next error, RED or waiting Human eval. Esc steps
back and never quits; q quits from idle views. Ctrl-C quits or cancels a running
Human tool first. The tree names what an eval waits for; b jumps upstream and
Backspace returns. Validation stays at Run
end in the headline; a dim * marks rows changed by later request updates.
The monitor follows local state changes without a permanent daemon. Reads run in
background jobs, so navigation and cancellation remain available during a refresh;
unchanged selected evidence keeps its tree and Detail. The Run list holds one bounded
page plus an older selected Run when newer entries push it off the page. j/k at
a page edge moves to the next/previous page without retaining the earlier pages.
Agent Detail shows live local sessions with scrolling and expandable tool activity
groups;
reused results keep their original evidence when it is available.
Team review store
Each machine keeps its own checkout and state. One artifactize server keeps the
verdicts by reuse key and returns the latest, so a review done on one laptop is
reused on the next and in CI. A read-only CI token reuses but never publishes.
Team review store · CI · Walkthrough
Documentation
Everything else is at artifactize.dev/docs:
- Concepts: Artifacts, evals, fingerprints, Runs and status.
- Guides: Agent evals and backends, Human reviews, the team review store and CI.
- Reference: every command and flag,
index.artf, tools, state, limits and the review store protocol. - Examples: runtime relations, Agent and Human tools, file Artifacts and dependency evals.
The recordings above are reproducible: their VHS tapes and demo projects are in
website/demo (how to record).
License
Licensed under the Apache License, Version 2.0.