Run locally
contractforge init
contractforge audit
contractforge compile
contractforge eval-gen
contractforge eval
contractforge report
No source upload by default. The audit works from a clean local clone or worktree.
Agent Contract Readiness
Coding agents can move quickly across code, tests, config, and CI. ContractForge gives the team a local audit packet for one repeated workflow: expected scope, validation commands, approval-sensitive changes, final-response evidence, preflight notes, and clear limits.
What actually happens
contractforge init
contractforge audit
contractforge compile
contractforge eval-gen
contractforge eval
contractforge report
No source upload by default. The audit works from a clean local clone or worktree.
agent.contract.yaml for scope, commands, approvals, failure limits, and evidence rules.AGENTS.md guidance compiled from the contract for team review..contractforge/eval_tasks.yaml for deterministic review-task skeletons..contractforge/report.md with traces, policy notes, check output, and limits.Why teams care
The first friction with coding agents is rarely whether they can edit code. It is whether the team can see the rules that governed the edit, inspect the evidence, and decide what still needs human judgment.
The PR includes CI, config, generated files, package metadata, or release-adjacent edits alongside the intended code change.
Dependency, migration, auth, billing, security, or production-facing changes arrive without a clear owner record.
The final answer says tests passed, but the exact commands, skipped checks, changed files, and residual risks are hard to inspect.
Agent expectations live across README text, AGENTS.md, tool-specific instructions, old PR comments, and reviewer memory.
Concrete scenarios
Each scenario shows a PR moment that normally becomes debate, then the audit artifact that makes the next review easier to inspect.
Review moment: A coding agent updates a billing handler and adds a package in the same PR. The reviewer cannot tell whether dependency work was approved.
agent.contract.yaml marks dependency, package metadata, billing, and release-adjacent work as approval-required for this workflow.
Run path: contractforge eval --agent-command checks the task prompt first. If it sees dependency work, the run is blocked unless --approve-gated, approver, reason, and scope are supplied.
Reviewer sees: the blocked preflight note in run evidence and the approval requirement in the contract packet.
Review moment: An agent changes a route handler, type definitions, and tests. API compatibility expectations exist, but they are spread across docs and past reviewer comments.
AGENTS.md lists allowed files, expected validation commands, API-compatibility notes, skipped-check disclosure, and final-response evidence.
Run path: contractforge compile reads agent.contract.yaml and renders the AGENTS.md guidance the team reviews before use.
Reviewer sees: the exact paths, commands, and final-response evidence expected for the API-change workflow.
Review moment: A failing test is fixed, but the PR also changes package scripts or CI configuration. The reviewer needs a clean separation between the code fix and workflow changes.
Eval tasks and reports flag expected paths, forbidden paths, command results, policy notes, and owner-review requirements for script or CI changes.
Run path: contractforge eval checks commands, diff scope, forbidden paths, and policy notes. contractforge report writes the review packet.
Reviewer sees: whether the PR stayed inside the expected workflow and which CI or script changes need owner review.
What comes back
The audit is deliberately narrow. It gives the team files and notes that can sit next to the next agent-created PR, with limits stated plainly.
agent.contract.yaml with commands, paths, approval-required categories, failure limits, and evidence rules.AGENTS.md section generated from the contract for reviewer inspection.How it plugs in
ContractForge is used around your existing repository and agent command. It does not require source upload by default.
contractforge init and contractforge audit identify project signals and instruction surfaces.
The audit edits the scaffold into rules for one workflow: allowed paths, commands, approval-sensitive work, stop rules, and final evidence.
contractforge compile, eval-gen, eval --plan, eval, and report create guidance, tasks, traces, and report output.
Reviewers compare the agent-created PR against the compiled guidance, contract scope, command evidence, preflight notes, and stated limits.
Best fit
The first rollout is built for founders, CTOs, heads of engineering, DevEx leads, and senior engineering owners at AI-native devtool, infrastructure, and SaaS teams. The buyer has one repo where agent-review friction is visible enough to justify a focused audit.
Getting started
The first step is not a platform rollout. It is a focused fit check around one agent-created change that already creates review friction.
Name the agent-created change that keeps raising scope, approval, command, or evidence questions.
Share the repo name or safe public URL, agent used today, expected commands, current instruction files, and the recurring review question.
The first reply confirms timing, authorization, local inspection path, and whether the $750 audit scope is a good fit.
ContractForge runs in a clean local clone or worktree and produces the contract scaffold, compiled guidance, eval tasks, checks, traces, and report.
Your team inspects the artifacts, memo, and limitations before adopting any generated guidance into the repo.
Start here
The first reply confirms fit, timing, and how the repository can be inspected by someone authorized to review it.