Developer ToolingCase study

Agentic Engineering: Risk-Routed Spec-Driven Dev

Delivered scope

A spec-driven pipeline published as a plugin: risk-based T0–T4 routing and generated adapters for eight other agent harnesses

Conceptual artwork. Not a photograph or screenshot of the client's system.
Client
An Agentive Labs product
Category
Developer Tooling
Location
Remote
Completed
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.

From this study to your project

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.

Next case study

Jelma: An Indonesia-First AI Website Builder