sd0x-dev-flow

sd0x-dev-flow

Language: English | 繁體中文 | 简体中文 | 日本語 | 한국어 | Español

The harness layer for Claude Code.

Let the model choose the path. Keep "done" verifiable.

Claude has discretion inside a closed, test-pinned anchor set. Since v5 only a small rule core loads at launch, and the detailed procedures load when their situation arises. Hooks are digest-bound reminders that survive compaction, and Codex reviews independently.

Full control plane on Claude Code. Skills-only distribution for Codex CLI and other compatible agents.

102 bundled · 102 public skills · 16 agents — procedures load on demand

Quick Start

# Claude Code — full control plane
/plugin marketplace add sd0xdev/sd0x-harness
/plugin install sd0x-dev-flow@sd0xdev-marketplace

# Configure your project
/project-setup

One command auto-detects framework, package manager, database, entrypoints, and scripts. Installs a subset of rules and hooks; the full plugin bundles 16 rules + 7 hooks. Use --lite to only configure CLAUDE.md (skip rules/hooks).

# Codex CLI / Cursor / Windsurf / Aider — skills only
npx skills add sd0xdev/sd0x-harness

Then, inside Codex CLI, generate the AGENTS.md kernel and install the commit-msg hook. The pre-push gate is opt-in — add --with-push-gate to install it too:

$codex-setup init

Requirements: Claude Code 2.1+ | Node.js 18+ | jq (pre-edit-guard and post-edit-format parse their hook payload with it — without jq both exit 0, so the sensitive-path guard and auto-formatting are silently off) | Codex CLI (optional to install the plugin; the default reviewer for the /codex-* review gates — on codex_fail — the adapter's start or resume exiting 1, and nothing else — the gate is carried by a contract-aware fallback reviewer under the same mechanism, fail-closed per family contract with [REVIEWER_FALLBACK] recorded; a missing adapter, a configuration error, an unfinished run, or an alloc/cleanup failure dispatches no fallback, records no marker and leaves the gate open, and only when every carrier is exhausted does the review surface ⚠️ Need Human instead of a verdict)

Codex exec setup

The review loop talks to Codex through codex exec, driven by a small adapter. There is no MCP server to register: this plugin no longer dispatches through codex mcp-server.

1. In a shell — install the Codex CLI (>= 0.149.0) and sign in:

codex --version

2. In Claude Code — install the transport adapter into this project. This is a slash command, not a shell command; typed into a terminal it would try to run an absolute path:

/sd0x-dev-flow:install-scripts codex-exec.js

Step 2 is optional: the first review that needs the adapter auto-installs it, using the same three-level lookup precommit-fast uses for its runner. Run it explicitly when you would rather the install not happen inside a review.

Model and reasoning effort now live in a Codex profile, not on a registration command. Name one in rules/auto-loop-project.md:

## Codex Profile

review

That name resolves to $CODEX_HOME/<name>.config.toml — the profile-v2 form codex exec -p layers on top of your base user config (codex exec --help: "Layer $CODEX_HOME/<name>.config.toml on top of the base user config"). So a review profile holding model_reasoning_effort = "high" gives the review loop the depth the old -c override gave it, and leaves your interactive Codex sessions alone. Leaving ## Codex Profile empty is fine: the adapter then passes no -p and Codex uses its own default configuration.

The adapter pins the sandbox and the approval policy itself for every dispatch, so neither is a setup decision — see skills/codex-code-review/references/codex-transport.md for the full contract.

Why v4

Frontier models can plan, batch, and recover from structured state — they no longer need the harness to dictate every next command. v4 moves from choreography to contracts: the harness stopped scripting the model's moves and started defining what must be true when the work is declared done, without relaxing a single safety or review anchor.

The non-negotiable core lives in a closed Anchor Register (rules/discretion.md) that no project override can downgrade — resolution is Anchor-first, and a test suite fails by design if a Register entry is removed. Inside that boundary, ownership is explicit:

The model owns the path. The harness owns the evidence and non-negotiable boundaries. The human retains irreversible authority.

Why v5

Recommended models: Claude Opus 5.5 or later. The 3.x line is deprecated and suitable only for models before Claude Opus 4.8.

v4 changed who chooses the path: the model owns the route inside a closed set of anchors. v5 changes when procedural instructions enter the context. Everything a session carries from launch competes with the task for attention, so 5.0 keeps at launch only what must hold before the task is known — the Anchor Register, the gates, the tiers and an index of contracts — and moves the step-by-step procedures into contracts read when their situation arises.

• A failed Read stops the action it governs instead of proceeding from memory. The contracts ship with the plugin, so rules copied into a project without it have nothing to read.
• A path match is automatic; a contract is not. It is reached through the trigger table, the resident rule's pointer, the skill that runs the work, or an advisory procedure_hint in the reminder facts.
• The budget is measured. The plugin-managed launch core of a rendered fresh install is 49,614 characters / 582 lines at 5.0.0, and test/rules/residency-budget.test.js holds it at ≤ 50,000 / 600. That is a reduction in resident text; the design does not claim a measured change in how well the model follows it.

What every Anchor prohibits or authorizes is unchanged, and review, /precommit and doc review run exactly when they did.

Upgrading an installed project: update the plugin, run /install-rules --all, and copy § Contract Triggers from the plugin's CLAUDE.template.md into .claude/CLAUDE.md. No *-project.md edit is required. The block-by-block 4.x → 5.0 mapping and the before/after measurement are in CHANGELOG.md.

What's New in 4.4

If you notice review quality drop after upgrading to 4.4.0 — real defects slipping through, or reviews converging too eagerly — please open an issue. This release changes review judgment, and field reports are the only way to validate it.

The plain-language version: the auto-loop used to let reviews dig ever deeper — a reviewer would flag a weak test, the fix added a stronger guard, the next round attacked that guard, and so on. We measured a real case: 9 review rounds where 7 of 8 blocking findings were about the test guards' own strength, and none were about the delivered change. 4.4 draws a line: once a property is demonstrated in both directions on its real path, further hardening of that property is non-blocking unless an AC or security invariant requires it.

Why we believe this is right (and why we still want your reports): IFScale measures model-specific adherence degradation as instruction density rises from 10 to 500 simultaneous instructions; context-rot research finds longer contexts and topically related distractors reduce reliability; and Vercel's agent evals found an always-present documentation index scored 100% where a skill with explicit trigger