A real SDLC chain, not a chat thread — with a ledger, gates, and evidence at every step.
One orchestrator classifies every request and routes it to the right toolkit — brainstorm, spec, design, build, or ship. The PM → BA → ARCH → DEV → QA pipeline is just one of the routes. Whatever the route, the kernel keeps the truth: workflow state, approvals, and evidence live as files in your repo. Claude Code and Codex are the runtimes — the governance is SDTK's.
> UNGOVERNED AI WORK DOESN'T COMPOUND
AI can generate all day. Can you audit any of it?
✕The agent did something — but there's no record of what ran, what was skipped, or why.
✕Your AI chat forgot the spec. Your repo forgot the decisions. Nothing connects.
✕Output lands as a wall of diffs with no evidence attached — review becomes "trust me".
✕Every session starts with re-explaining the project instead of continuing it.
> ONE FRONT DOOR. THE RIGHT WORKFLOW, AUTOMATICALLY.
You don't pick the workflow. Describe the work — the Orchestrator routes it.
The SDTK Orchestrator now classifies every request and sends it to the right pack — brainstorm, build, spec, or ship. No more forcing a quick bug fix through a full spec pipeline. The PM -> BA -> ARCH -> DEV -> QA chain is just one of the routes.
You type
“Analyze why the auth module is slow”
Brainstorm / discoveryClarify the problem before any code
You type
“Fix the login validation bug”
SDTK-CODEstart -> build -> verify -> ship
You type
“Design & spec the notification feature”
SDTK-SPECPM -> BA -> ARCH -> DEV -> QA
You type
“Deploy v2 to production”
SDTK-OPSplan -> deploy -> verify
> ARTIFACTS, NOT CHAT HISTORY
What you actually get — real files in your repo, not lost messages.
Every SDTK phase writes concrete artifacts to your project tree. Click a tab to see a real sample of what lands on disk.
Generated path
docs/product/PRD_ORDER_TRACKING.md
PM phase output: goals, scope, success metrics — written from the discovery brief.
Produced by SDTK-SPEC
PRD_ORDER_TRACKING.md
# PRD: Order Tracking
## Goal
Reduce "where is my order" support tickets by 40%
via customer self-serve tracking.
## Success metrics
- Tracking page p95 load < 500 ms
- 70%+ of tracking inquiries deflected from support
- Zero PII leak in tracking page
## Scope
- In: customer self-serve tracking page, status polling
- Out: carrier-side integration, refund flow
All artifacts live in your repo. None of this leaves your machine.
> FIVE PHASE TOOLKITS, EACH WITH A JOB
Each toolkit owns one phase of the lifecycle. Together, they cover idea to ship.
SDTK-SPEC
Live + MIT
Your PM, BA, Architect, and QA — as installable skills
SDTK-WIKI and SDTK-AGENT are always-on capabilities every other toolkit can call on. SDTK-BRAIN stands fully apart: a standalone second-brain vault tool that shares SDTK's viewer — and nothing else.
MemoryLive + MIT
SDTK-WIKI
Your project memory — so the next session doesn't start from zero
Every decision, spec, and lookup gets indexed into a local graph. Every other toolkit reads it so context survives between sessions.
Durable multi-step agent workflows with human approval gates
The kernel's orchestration surface: chains multi-step runs into one file-backed ledger — pausable and resumable from any process, gated by human approval where it matters. Dispatches through pluggable adapters (manual, shell, sdtk-cli, and a Hermes Kanban dry-run planner); the kernel keeps the ledger and gates.
Your personal second-brain vault — a separate tool, not a pipeline stage
A standalone local-first vault CLI: immutable raw/ sources compiled into a markdown wiki/ knowledge layer your agent reads and maintains. Not part of the sdtk-kit umbrella — install it on its own (npm i -g sdtk-brain-kit). No LLM, no network, no telemetry.
Not another agent runner — the governor that decides if it's safe to let one run.
Claude, Codex, and friends execute. SDTK is the local trust layer around them: deterministic capabilities that make it safe to let an AI build, verify, and ship — even while you sleep.
Guardrails
Trust at the action boundary
Classify every command allow / ask / deny, and lock edits to a declared file scope — before anything runs.
$ sdtk-code guardrails check --command "rm -rf ."
Observability
Trust through transparency
An explainable ship-readiness score (no fake readiness) plus a reconstructable trust trace of what happened and why.
External runtimes plug in through an adapter contract. The shipped Hermes Kanban adapter is dry-run only — it compiles the exact card plan a live dispatch would create, never calls a gateway, and refuses mode:"live" (fail-closed). Live dispatch is roadmap, gated behind recovery verbs and independent review.
Sleep Readiness Governor
Can I sleep while the AI runs?
Before any agent runs overnight, SDTK assembles a bounded plan and grades it as a pre-flight dry run — executing nothing. It says NO first with the exact fixes needed, then YES once they're real.
NOT_READY30 / 85 — FAIL
Scope not declared — the agent could touch any file; scope_lock has nothing to enforce.
READY_TO_SLEEP75 / 85 — PASS
The plan is bounded, readiness is PASS, and test obligations are present.
Claude and Codex execute; they don't govern. They forget your project when the tab closes, and what they did survives only as chat history. SDTK puts a real SDLC chain (PM → BA → ARCH → DEV → QA), a file-backed ledger, human gates, and a local memory layer behind them — so every session starts grounded and everything the AI does leaves reviewable artifacts in your repo.
Built for engineers who need AI-assisted work they can audit — on Claude Code or Codex.
