Give it a repo and a task.
It runs the loop, and hands back a reviewed PR.
skharness is the single autocode engine. It builds in a lean, sandboxed context — the repo, the task brief, and repo-grounded facts, nothing else. It never sees your personal graph. One engine, two front doors: skos drives it autonomously, skcode drives it by hand.
$ pip install skharness
Python 3.10+ · skharness on PyPI (v0.3.1) · GPL-3.0.
PyPI ↗ ·
Read the docs ↗
Three names, one crisp boundary. Personal context flows down as a narrow task brief; it never flows up into a build sandbox. skharness is the engine in the middle — the only place the assess/build/grade/gate/merge loop lives.
The single pane of glass: GTD, memory, coordination board, ITIL, scheduler, and the AI-operator seat. It decides what and why to build, distills a card into a narrow brief, and dispatches it to the engine.
skos autopilot delegates to skharness.autocodeThe autocode loop, extracted into one reusable package. Input: a repo and a task. Output: a reviewed PR. It is deliberately context-lean — a build never receives your MCP servers, memory, GTD, calendar, or soul.
The human-facing coding surface. A thin client, not a second engine — when it needs a heavy autonomous build it calls skharness, taking the same engine path skos does, just driven by a human interactively.
A task brief comes in — what to build, the acceptance criteria, and the coherence constraints. skharness assesses the repo, then runs an iterative Ralph loop in a sandbox to produce a diff.
Nothing merges on vibes. Every round is graded 1-5, and the twin-gate is unforgiving: it finalizes only when the grade is exactly 5, CI is green, and coverage holds. Anything short loops back to build.
The output is a reviewed PR plus a verdict — handed back to whichever
front door dispatched it. This is the loop skos autopilot already delegates
to today; it is not re-implemented anywhere else.
skos hands down a narrow brief. skharness assesses, builds in an isolated sandbox, grades, gates on CI and coverage, and returns a reviewed PR. The sandbox never touches the operator's graph.
The skharness package ships two planes of one unified Harness contract. The task plane is the autocode engine — the main story. The session plane is the read-only host daemon that skcode's remote control runs on, hosted here as the engine's thin deployment shell.
The two same-named claude_code harnesses are intentional,
not a bug — a Docker adapter on the task plane and a tmux harness on the session plane, each a
distinct seam of the same contract.
The reason the engine is separate at all. A build sandbox is minimal-privilege by design: smaller blast radius, faster and cheaper (no 40-server load), and more focused — irrelevant context only degrades the model.
grounding.py)skharness is the engine layer of the SKWorld sovereign AI ecosystem. skos drives it, skcode codes with it, and the rest of the family is what it builds on.
Personal context enters a build only as a distilled brief — what to build, the acceptance, the constraints. It never arrives as the whole graph. That one rule is why there is a single engine, why sandboxes are minimal-privilege, and why the operator's data has exactly one home.
The engine that skos and skcode both drive. Context-lean, sandboxed, twin-gated. Install it, or read how it fits the stack.
$ pip install skharness
"staycuriousANDkeepsmilin" 🐧