.checkfu outputs are inspectable authoring material; neither is runtime authority.
If the task also includes customer-side Slack, Custom-tool server, or embedded UI code, inspect the bundled integration catalog first:
Project tree
agent/instructions.md is the only file under agent/ that is required. checkfu.json already declares the harness, model routing profile, and environment, so a project with nothing but a page of markdown under agent/ compiles: the name comes from the page’s leading # Title, and everything else takes its default. Add agent/agent.json when the agent needs tools, skills, or a policy that page cannot carry.
agent/agent.json follows the canonical Agent manifest, except name is optional. Tool and skill identity comes from the path: omit a redundant name, or make it exactly match <tool-name> / <skill-name>. checkfu.json owns the Blueprint package, and each file under scenarios/ declares an acceptance scenario that travels with it.
Keep credentials out of every file. A Blueprint declares credential requirements; values enter only through the governed write-only operation for the bound resource.
Inspect before editing
Run inspection before changing source, and keep the JSON result for comparison:blueprint, agent, tool, skill, and scenario authoring capabilities to epoch 1. Declare a different epoch under compatibility in agent/agent.json only when the project genuinely requires it. Never downgrade an epoch merely to make compilation pass.
Compile and inspect the immutable generation
.checkfu/compile/, then updates .checkfu/current.json. Follow that pointer and inspect the canonical package, diagnostics, inspection, and compatibility documents. Do not assume source was accepted because the command produced some output; compilation fails closed on unsupported capabilities, path/name drift, staging problems, or symlinked artifact roots.
A behavior change becomes effective through the next immutable Agent version
and ordinary Session Version pinning. Local source and compiled files never
replace that authority.
Plan and run the declared scenarios
release_hash. Run every planned scenario against the intended Target—for example an authorized local worker or admitted deployment—and read settlement from the Session event log. A failed scenario is a failed evaluation; do not grade from response timing or silently omit a case. Outcomes may supply a platform verdict when a scenario declares one, but the CLI does not create a second grader.
Record exactly one observation per declared scenario. The minimal closed document is:
.checkfu/eval-current.json to the generation holding plan.json and, once observations are bound, evidence.json. That pointer also carries the planned / passed / failed status.
The resulting .checkfu/eval/.../evidence.json is labeled unverified-caller-reported. The CLI validates shape, complete scenario coverage, and release binding, but it does not independently re-read the Target event log or emit promotion-grade ReleaseEvaluation evidence. Treat source_report as a caller assertion.
Agent contract
- Inspect before editing, and compare the compiled generation with your intent.
- Follow path-derived tool and skill names; do not create a second identity in JSON.
- Never weaken compatibility epochs to pass compile.
- A failed or missing scenario is a failed evaluation.
- Never put credentials in source, artifacts, or observations.
- Never run local authoring code in the Checkfu control plane, Runner, or Sandbox.
- Never commit or upload
.checkfuartifacts, observations, or evidence without explicit authorization.
checkfu-agent-authoring skill. Locate the version-matched copies, and the authoring capability epochs your CLI supports, with: