Work with the agent you prefer

Use the coding agent you already have. Skep governs the rest.

Skep supervises workers through one local contract. Pick an engine with skep project setup --engine or point a run at any adapter with --worker-cmd — Skep handles isolation, verification, and approvals.

Bring your favorite agent

Run it in a safe, isolated workspace

Independently verify every result

Read the worker setup guide

Claude Code

Recommended

A thin adapter around the local claude CLI. Claude Code edits the disposable worktree; Skep owns everything else.

Complex, multi-file refactors Patch captured via git diff --binary Expects claude on PATH

skep project setup --engine claude_code

Codex

CLI adapter

A thin AdapterSpec on the shared CLI adapter. Same contract body, same evidence capture.

Coding tasks and debugging Runs inside the worker sandbox Landing is the only commit

skep project setup --engine codex

Aider

Git-native

Terminal pair programming with Git superpowers — pinned to --no-auto-commit so it can never slip a commit past the gate.

Focused edits and Git workflows Works with many LLMs Auto-commit disabled by contract

skep project setup --engine aider

Ollama

Fully local

The first-party LLM-planning worker pointed at a local Ollama model. Your code and your model both stay on your machine.

100% local, no API costs Reuses your assistant config by default SKEP_OLLAMA_MODEL to differ

python -m skep.workers.ollama

Built-in worker

Default

Skep's in-repo deterministic coding worker. No adapter, no external CLI — the fastest way to see the whole lifecycle work.

Deterministic local runs Many model providers Tool and MCP support

(no --worker-cmd needed)

Custom worker

Extensible

Any command that reads Skep task JSON and writes Skep result JSON. Or wrap a local CLI agent with the generic shell worker.

Simple worker contract Structured progress events Open interfaces, contract 0.3.5

skep run … --worker-cmd "your-agent"

Compare adapters

Every worker runs inside Skep's boundary and follows your policy.

Yes Partial No

Capability	Claude Code	Codex	Aider	Ollama	Built-in	Custom
Runs fully local	Partial	Partial	Partial	Yes	Yes	Depends
External API required	Yes	Yes	Optional	No	Optional	No
Patch captured by Skep	Yes	Yes	Yes	Yes	Yes	Yes
Requires a pinned verify command	Yes — forced sandbox	Yes — forced sandbox	Yes — forced sandbox	Contract-native	Contract-native	Contract-native
Best for	Large refactors	Coding & debugging	Focused Git edits	Privacy-first work	Deterministic runs	Your own agent
Requires approval to land	Yes	Yes	Yes	Yes	Yes	Yes

External CLI agents don't pass Skep's capability layer command-by-command — the sandbox confines them instead, so they require a project-pinned verify command and are forced into sandbox execution. skep doctor probes each binary.

The worker contract

Build your own worker.

The contract is small on purpose: read task JSON, emit NDJSON events, write result JSON. Skep supplies the worktree, the sandbox, the budget, and the approval gates.

Simple JSON interface

Full control over execution

Stream events in real time

Works with any coding agent

Read the contract spec

the contract, in one glance

# stdin: the task
{ "task_id": "7d31f9c2",
  "worktree": "~/.skep/worktrees/7d31f9c2",
  "instructions": "fix the failing test",
  "permissions": { …network, env, shell… } }

# stdout: NDJSON events while working
{ "type": "progress", "message": "editing session.py" }
{ "type": "verify.result", "commands": ["uv run pytest"],
  "outcome": "passed" }

# result: the claim skep re-checks
{ "state": "completed",
  "patch": "artifacts/7d31f9c2.patch" }

Any agent. Every workflow. Zero compromises.

Pick an agent, connect it, and let Skep protect your code.

Install skep View documentation