Reservine-DX

The problem

The classic failure mode of an autonomous coding agent is that it skips steps. Tell it to "follow the 11 phases" and it reads the whole plan, decides it knows better, and jumps straight to writing code — no worktree, no spec, no security pass. Prose instructions like "you MUST do X first" are advisory; the model treats them as suggestions and rationalizes its way around them. The more capable the model, the more confidently it cuts corners.

Across two very different stacks — an Angular/Nx frontend and a Laravel backend — I kept re-explaining the same delivery discipline every session: context, spec, branch, build, verify, review, ship. That knowledge lived in my head and in scattered prose, so each repo drifted and each session re-litigated the process.

I wanted the process to be a property of the tooling, not something I have to stand over and police.

The enforced loop

@reservine/dx is a published Claude Code marketplace plugin: a shared, cross-repo set of skills — feature planning, cross-plan, implement-plan, cherry-pick, commit — installed with `bunx @reservine/dx install`.

The core is implement-plan, a phase router. Instead of handing the agent the whole playbook, it loads exactly one phase file at a time — Context, then Spec, Worktree, Implementation, Build, Verification, PR, Review, Security, Retro, Handoff (plus a conditional 6.5). The agent cannot look ahead, because the next phase simply isn't in its context yet.

Between phases sits the part that makes it real: `scripts/validate-phase-gate.sh`, a real shell check that emits a binary `GATE_RESULT: PASS/FAIL` and exits non-zero on failure. The router must run it and check the exit code before advancing. This is not a prompt asking the model to behave — it is a process that returns 1, and a non-zero exit stops the loop. The model can argue with prose; it cannot argue with an exit code.

The plugin auto-detects whether it is in the frontend or backend repo and wires up worktree automation accordingly, so the same loop runs across both stacks without me re-explaining it.

Why it matters

The distinction I care about is that this is a verifiable guardrail, not a persuasive one. Most "agent guardrails" are just more prose telling the model to be careful — which holds until the model decides it's done. A shell gate that exits non-zero is the same kind of control I'd put in CI: deterministic, inspectable, and indifferent to how convincingly the agent narrates its own compliance.

I published this as my own tooling because the pattern generalizes. Single-phase context loading plus a real exit-code gate is how you get an agent to do thorough work end-to-end instead of an enthusiastic 60% — and it's how a team can trust an autonomous run without re-reading every line it produced.

It also puts process where process belongs: in version-controlled scripts a team can read, change, and extend — not in one engineer's habits or a long system prompt nobody audits.