The DidWork CLI. Three jobs: configure an agent to verify its own claims, gate a merge on outcomes that are actually true, and say what an agent tool can actually affect.

`didwork init` — make verification the default

Writes the editor configuration that gives an agent did_verify and the rule that makes it reach for one. No marketplace, no plugin approval.

npx @didwork/inspect init            # detects Cursor or Claude Code
npx @didwork/inspect init --dry-run  # show the plan, write nothing

For Cursor it writes .cursor/mcp.json and .cursor/rules/verify-outcomes.mdc; for Claude Code, .mcp.json and a block in CLAUDE.md. Existing config is merged rather than replaced, a second run changes nothing, and a config file that will not parse is left alone and reported.

Your key is never written into those files — they are project files you commit. The config references DIDWORK_API_KEY, and the server also reads ~/.didwork/api_key, which lives outside the repo and works for editors launched from a Dock or Start menu that never see a shell environment.

`didwork verify` — the merge gate

Runs the claims in a repo's .didwork.yml against the systems that can prove them, and exits non-zero when a required outcome is not verified. Because it fails the build, it can be a required status check.

npx @didwork/inspect verify            # run the gate
npx @didwork/inspect verify --comment  # ...and post it on the pull request

version: 1
claims:
  - name: Production health
    type: http.ok
    expected:
      url: https://example.com/health

  - name: Canary (reported, cannot block)
    type: http.ok
    required: false
    expected:
      url: https://canary.example.com/health

A required claim passes the gate only on verified. failed, unknown, and a check that could not run all block: a check that never reached its evidence has not shown anything to be true. Set DIDWORK_API_KEY for provider-backed claims and stored receipts — without it only http.ok verifies, keyless, storing nothing.

Exit codes: 0 gate passed · 1 a required claim is not verified · 2 usage or config error. In GitHub Actions, use didworksh/verify-action.

Capability Trust

What can this tool actually affect, and what evidence does DidWork have for saying so?

import { inspectProject } from "@didwork/inspect";

const { tools, summary } = inspectProject({ root: "." });

Each tool gets a CapabilityProfile (types in @didwork/sdk) with three blocks kept apart on purpose: declared (from did.tool({ effects })), evidenced (source-level evidence and the gaps analysis could not close), and observed (runtime; always null in this release).

risk is the highest evidenced consequence; confidence is the strength of the evidence. They are separate. unknown never degrades to low.
status is failed when evidence exceeds the declaration (DECLARATION_MISMATCH), unknown when analysis could not establish the profile (INSUFFICIENT_EVIDENCE, IMPLEMENTATION_UNAVAILABLE), and verified only when the profile is established.

Supported today: TypeScript/JavaScript projects registering tools with @modelcontextprotocol/sdk (server.tool, server.registerTool) or declaring them with did.tool(...). Other languages produce no tools rather than guesses. Analysis runs locally and reads source; nothing is uploaded.

The evidence table lives in src/signatures.ts. Add a row per package call; catch-all rows take the riskier reading.