Agentic Engineering: Risk-Routed Spec-Driven Dev
A spec-driven pipeline published as a plugin: risk-based T0–T4 routing and generated adapters for eight other agent harnesses

- An Agentive Labs product
- Developer Tooling
- Remote
- September 21, 2026
The problem
Working with a coding agent and no process means two equally bad extremes: every change going through full specification bureaucracy, or every change going straight to “vibes” with no record. And nearly every existing pipeline routes work by size — yet size is a bad proxy for risk. A one-line change to a rounding rule in billing is high risk; a 400-line test-only refactor is not.
What we built
A Claude Code plugin for spec-driven development, ported from a battle-tested internal
pipeline. /sdd is the front door: describe the work in plain language, and the plugin
classifies it — a bug, an idea that needs discovery, or a decided change — then scores
four signals (intent gaps, irreversibility, footprint, behaviour delta) and assigns a
tier:
- T0 — just do it; the commit message carries the reason.
- T1 — an inline micro-spec, implemented in the same session.
- T2 — plan first; every open question signed off before code.
- T3/T4 — PRD → epics → stories → test-first implementation → review → close.
Two rules make a zero-process tier safe: any irreversibility signal forces T2 minimum, whatever the size, and the classification is written to a file so you can override it rather than argue with the process.
Engineering decisions
Loops that compound, not logs that are forgotten. Every finished story records the
traps a green test suite didn’t catch, and the next story on the same surface is told.
/story-close asks one question per story: what did I just do by hand that a script or
test should have done — at most one improvement, and “none this run” is a valid answer.
Honesty as a rule, throughout. A skipped scan is reported differently from a clean
one. A bug verdict auto-downgrades to partial when the original repro was never actually
exercised. “No findings” is a legitimate outcome.
Cross-harness through generated adapters. The skills are byte-identical across eight
other harnesses — Cursor, Codex, Copilot, opencode, Cline, and more — generated from one
source by build-adapters.mjs (never hand-edited), and every adapter ships a
CAVEATS.md naming what that harness cannot enforce. A pipeline that looks identical
but silently drops a gate is worse than one that says so.
Running and verifying it
There is no UI; the artifact is the practice. The plugin installs via /plugin marketplace add from its private GitHub repo, then /sdd-init once per repo. Verification needs no
external services: claude plugin validate checks the manifests, node --test runs the
helper CLI suite, and CI runs four anti-drift guards — including one that fails the build
if a skill names a specific tool (the stack-agnostic promise decays silently otherwise) or
if the adapters/ tree goes stale.
Does your team face a similar problem?
Tell us about the workflow and its constraints. We start with a scope we can describe and verify.


