Deltz for coding agents

Your agent writes. Deltz checks. Run supported checks inside your repository, inspect the findings and coverage, make an edit, and check again. The local CLI and stdio MCP path is deterministic and needs no model key or cloud credentials. Application tests and builds remain in your own harness and CI.

Choose the matching build

Set up Deltz with our team. We supply a reviewed build and agree the repository, base and supported checks with you. The commands below start after that binary is installed on your PATH:

garboard version
garboard gate --help
garboard init --help

This guide’s current source checkpoint is backend 4faf6d36f6abe47b98e93a519649e84568a2122b, reviewed on 27 October 2026. The private v0.2.10 release predates the opt-in verification contract and local MCP application parity described below. Use the supplied build identity to confirm those capabilities; the docs footer version is not an assertion that an older binary implements them. This guide does not provide a public package or marketplace installer.

Init per harness

Run the appropriate setup inside your Git repository:

# Claude Code
garboard init --harness claude-code
# Restart Claude Code and approve the local garboard MCP server.

# Codex
garboard init --harness codex
codex mcp add garboard -- garboard mcp

# Cursor
garboard init --harness cursor
# Reload Cursor to load its MCP configuration and repository rules.

Confirm that the selected harness can list and call the local tools before relying on the workflow. Configuration paths are not a claim that every harness version has been qualified. The executable retains its compatible garboard name even though the product is Deltz.

init derives .garboard/rcd.json if absent, adds a managed workflow block to CLAUDE.md, AGENTS.md or .cursor/rules/garboard.mdc, and merges the local MCP entry into .mcp.json (plus .cursor/mcp.json for Cursor). It preserves existing content outside its managed blocks and other MCP servers. Codex reads its own configuration, so its additional codex mcp add command is necessary.

Preview changes or add optional local hooks:

garboard init --harness all --hooks --dry-run
garboard init --harness claude-code --hooks

Running the same initialization again is idempotent. Review the generated repository instructions and commit the intended configuration with your team.

Before the first line

For infrastructure work, read the repository’s derived conventions and exemplars through get_conventions and get_exemplars. Their evidence points to the source file and line. MCP reads the local RCD; keep that context current by rescanning and restarting the MCP server when appropriate. A local file is not a hosted configuration or approval record.

Without MCP, export the context as instructions:

garboard export --format claude-md --stdout

The MCP server is a local process:

garboard mcp
garboard mcp --rcd .garboard/rcd.json

It speaks stdio, not hosted HTTP. Its tools are read-only. The other tools are check_diff and search_episodes; recorded episodes provide context, not proof of independent CI, acceptance or deployment.

Before the push

Choose the actual base for your repository; it must exist locally:

garboard gate --changed --base origin/main --format json
# Optional: restrict the selected change scope further.
garboard gate --changed --base origin/main --format json infra/

--changed includes committed changes since the selected merge-base plus staged, unstaged and untracked files, narrowed to supported frontend ownership and any pathspec. meta.base records the resolved comparison commit; meta.changed records the selected paths. This is a scoped check, not a full repository change manifest. Outside a Git worktree, the command exits 3.

Supported Terraform changes can be compared with their selected HCL baseline. An unreadable or malformed selected HCL base stops the run rather than treating it as empty. The CLI reads .garboard/rcd.json when present and reports its identity or absence. Repository policy comes from the selected immutable base; a proposed edit cannot silently replace the policy used for that comparison. The offline path does not read the hosted organization’s store or approval state.

TypeScript and JavaScript

Changed .ts, .tsx, .js and .jsx files use a two-sided, line-level integrity reader. It can flag supported patterns such as deleted/skipped tests, removed assertions and new suppressions. These findings are advisory by default. Generated, bundled and dependency paths are excluded. The reader does not parse TypeScript, execute tests or establish whether a behavior is correct.

Use --changed for application integrity: a whole-tree garboard gate <path> has no application baseline and does not evaluate these rules. For equivalent supported inputs, local MCP reuses the same findings and coverage logic. Missing or truncated sides remain explicit; they do not become empty added files.

What an agent gets

garboard gate --format json returns one JSON envelope on stdout. This illustrative excerpt shows a blocking infrastructure finding; actual output also carries the run’s coverage details and metadata:

{
  "status": "blocked",
  "clean": false,
  "findings": [{
    "rule_id": "secops.rds_unencrypted",
    "severity": "critical",
    "enforcement": "block",
    "title": "RDS instance is not encrypted at rest",
    "file": "infra/main.tf",
    "line": 1
  }]
}

• Findings name the rule, source line and enforcement. Warnings are not automatically blocking.
• Coverage distinguishes evaluated, unsupported and failed inputs and names missing context. Read it even when the finding list is empty.
• Metadata identifies the binary, selected base/changed paths, and local RCD or why none was read. --via my-skill@1.0.0 adds a caller label only; it cannot grant authority or change checks.

Do not turn incomplete, unsupported or failed evidence into a pass. --advisory-errors explicitly makes advisories fail the CLI. Avoid --allow-incomplete in a workflow that requires complete selected coverage. Even a clean local check does not prove runtime behavior, customer-CI success or protected approval.

MCP change input

For a supported change, provide full candidate contents and the local base ref:

{
  "files": {"src/example.ts": "export const value: any = 1;\n"},
  "base_ref": "origin/main"
}

For application deletions or explicit two-sided input, use changes with base and head sides. Each side is present with content, or confirmed absent; an empty existing file is not the same as an absent file. Represent a rename as delete plus add. Supplied baseline bytes must match the resolved base when base_ref is also given. The current application adapter bounds submissions to 512 paths, 1 MiB per side and 4 MiB combined path/content bytes.

Optional verification: true adds a local plan, outcome, controls and issues. It binds supplied bytes and records the coverage actually observed. Its fixed profile retains unresolved protected requirements and never returns complete. It cannot authenticate customer CI or prove full repository scope. Legacy status and the separate verification outcome answer different questions.

The hook

With --hooks, initialization adds a pre-commit entry and, for Claude Code, a PreToolUse hook before git push, gh pr create and glab mr create.

The generated Claude Code entry includes onFailure: block, requiring a harness version that honors it (Claude Code 2.1.295 or later). Older versions can ignore that field. The Codex plugin has no equivalent documented fail-closed switch; its hooks require user trust, and a hook failure can let the command proceed. Confirm actual behavior in the installed harness during setup.

Local hooks are feedback, not a protected organization boundary. A user or agent with write access can remove a hook, and pre-commit can be bypassed. A required hosted GitHub check also needs the expected App, repository ownership and branch/ruleset configuration; a local hook does not establish those controls.

In the pull request

Configured hosted review exposes structured findings and coverage in the GitHub Check Run for the reviewed commit. An agent that can read that check can inspect its result and re-check after an edit. Findings retain identity across pushes; “fixed” requires an applicable evaluation, not merely an empty finding list.

The authenticated GET /api/reviews/{id}/verdict route provides the full result when the Check Run cannot hold every finding. Use a token scoped to the authorized repository and keep it out of prompts, screenshots and repository files. Human dismissals and approvals do not repair missing or stale required evidence.

Hosted setup is agreed separately with the team. A clean local check, signed receipt or generated plugin does not activate a required App check or establish customer approval. Signing establishes the integrity/origin of its payload, not that every application requirement passed.

The plugin

Render local bundles from the supplied binary:

garboard plugin build ./deltz-plugins
claude --plugin-dir ./deltz-plugins/claude-code

Each generated bundle includes instructions, skills, hooks and a local MCP entry. The binary must remain on PATH. The Claude Code and Codex bundles share generated workflow content, but their hook failure policies differ as described above. Codex uses a local plugin entry in its marketplace configuration and skips hooks until they are reviewed and trusted. These commands create local bundles; they do not install from a public marketplace.

What was tested, exactly

The supplied build’s evidence records its actual binary, source, platform and supported scope. Source/protocol tests exercise the real CLI and stdio MCP entry points and fixture hook events. These establish bounded interface behavior, not an installed session in every coding harness. Actual clean installation and live harness qualification are separate setup checks. Do not infer newer feature coverage from the old v0.2.0 documentation or the v0.2.10 release label.

What the local lane does not see

• Runtime application behavior, customer tests and builds need their own execution.
• Local policy/context does not establish hosted organization settings, live App authority, human approval or protected independent evidence.
• A path outside the selected or supported scope remains outside the observation.
• Artifact-only checks need the specific artifact your own trusted workflow produces. Never supply cloud credentials, Terraform state or artifacts with secrets.

After source, base, policy, rules or relevant configuration changes, re-check the supported scope. When impact is unknown, widen the review rather than reusing a result for different inputs.