Agentic coding outgrew the prompt. The work now is the harness around the model: what it may see, what it may do, and what it may never decide. SSD 3.0 is that harness. You still ship every day. The agent does not ship itself.
Prompt engineering treats the instruction as the control. Context engineering treats the files in the window as the control. Both still trust the model to obey. SSD 3.0 moves the control into the harness: executable gates, schemas, an authorization directory the repository cannot see, and a ship command that only a human runs.
| SSD 2.x relied on the model | SSD 3.0 enforces it |
|---|---|
| The skill text said to stop, propose, and wait. | Bare /ssd proposes. run stops at the gate. /ssd ship is a human command. There is no --force. |
An in-repo approved: true could look like consent. | Grants for ship, deploy, publish, release, tag, rollout, and flag removal live outside the repo. One use. Bound to the action, the path, and the snapshot. A worker cannot mint one. |
The review checklist lived in the prompt. The model could report its own gate_pass. | Gate rules and schemas run as programs. Certification ignores a model-supplied gate_pass. |
| A killed session was a story to reconstruct. | .ssd/ holds the record. /ssd doctor reads it and writes nothing. /ssd resume continues the run and does not restore a grant. |
| The same context often reviewed its own diff. | Architect, coder, and reviewer are separate role files with separate tools. The reviewer cannot edit, and it cannot certify the gate. A host has not dispatched them yet. |
The ladder is unchanged since 2.14: propose by default, advance for one phase, run up to the gate. Announce, then log, then act. The ceiling is the gate. Ship, deploy, and flag removal sit above it, and they require a grant the agent cannot write for itself. A lock is not a grant. Unattended run is certified only for the jail plus the external control directory on the Linux host that ran the suite. Everywhere else, doctor reports the gap and the effective mode stays propose.
A grant lives in SSD_CONTROL_DIR, or in ~/.ssd-control/ plus the first 16 hex characters of the project path’s SHA-256. The directory must sit outside the project. One use is the default. A different snapshot does not match. SSD_WORKER=1 cannot create a grant and cannot spend one. .ssd/control/grants.yml is not consulted. A missing guard fails closed.
YAML schemas are the contract. JSON schemas are generated from them. A schema-valid file is not a gate result and not an authorization. The skill-metadata rule checks frontmatter inside this library and skips elsewhere. A missing parser is a failure. The rail is brief, design, code, review, gate, ship. ssd/rails.md still lists deploy, rollout, and flag removal after the gate. Those steps stay outside an unattended run.
Doctor resolves the library, the project, the worktree, and the store, then reports health: missing, valid, corrupt, or unreadable. Corrupt state is corrupt. It is not an empty project. Doctor does not install, repair, or open the network. Resume continues the same record. It does not reset a spent transition, and it stops if a worker may still be alive. Clearing the lock and starting /ssd run is a new run, with fresh budgets.
Three role files describe the subagents. The architect reads. The coder edits and does not get a shell; a test it did not run is NOT_RUN. The reviewer reads only. A delegation envelope matches one schema, and a valid envelope is not permission to act. The release checks did not have a host dispatch a role, so observed delegation stays NOT_RUN. Tests that must run go through an unshare jail and then chroot. If that mechanism is missing, strong-assurance review is unsupported.
hooks/hooks.json calls the adapter on Bash, on writes, and at session start, setup, and stop. An empty or malformed payload grants nothing. A PreToolUse timeout does not block, which is why the control directory remains the authority. Process tests of the adapter passed. Claude Code did not deliver an event in the release checks, so host delivery is NOT_RUN.
Sixteen fixtures, two held out, and a live driver that can call Claude Code or the Messages API. The driver checks a spend ceiling before each call. Unknown cost stays unknown, and later calls do not start. --dry-run prints the plan and does not call a model. No live model was called. The three suite rows that are NOT_RUN — in-session instruction loading, live repetitions, and the five-user pilot — are named, not passed. That honesty is the point. Read True As Of.
The clone path is kept: git clone into ~/.claude/skills. The same tree carries a plugin named ssd at 3.0.0, with no bin/. On a namespaced host the commands look like /ssd:coder. The clone keeps /coder. AGENTS.md is the contributor guide for the skills repository. A user project receives instructions only with consent, inside a managed block. Whether a session loaded AGENTS.md was not measured.
The tutorial is the propose path. The Guide has the commands, the migration from 2.x, and the evidence table.
The exact inventory is next. True as of 12 October 2026, skills main at c6dd481.
Checked against skills main at c6dd481 on 12 October 2026. That commit is the squash of pull request #58, and it is the same tree as d6f23bd. VERSION is 3.0.0. A clone of main prints 3.0.0. The list below is the release record: tasks, evidence, deviations, owner actions, and ADR-0024.
These shipped, and the check that can run without a live model did run.
| In 3.0 | What it does |
|---|---|
| Autonomy ladder | Bare /ssd proposes. advance takes one phase. run stops at the gate. Announce, then log, then act. An absent autonomy: block makes no extra call. |
| Human ship wall | /ssd ship is a human command. Ship, deploy, publish, release, tag-default, rollout-advance, and flag-removal sit above the gate. |
| Shipping grants | Grants live in SSD_CONTROL_DIR or ~/.ssd-control/, outside the project. One use. Bound to the action, the path, and the snapshot. A worker cannot mint or spend one. An in-repo approved: true is ignored. A missing guard fails closed. |
| Doctor | /ssd doctor reports health and writes nothing. It does not install, repair, or open the network. Corrupt state is corrupt, not an empty project. An unsupported run is reported as effective mode propose, and the config file is left alone. |
| Resume | /ssd resume continues the same record. It does not reset a spent transition, does not restore a grant, and does not invent a finish. A worker that may still be alive is FM-2. A conflicting fingerprint is STOP-4. |
| Setup plan | setup-plan returns writes: 0. It names discovered test commands and does not run them. Optional permissions stay off until you consent. |
| Managed blocks and removal | SSD text in AGENTS.md or CLAUDE.md sits in a managed block. Removal strips those blocks and an SSD pre-commit symlink, and it keeps .ssd/, your source, and a foreign hook. |
| Format marker | Migration format-marker writes .ssd/format containing 3 when the file is absent, and it refuses a marker that is not major 3. Rollback is the backup migrate.sh writes. Libraries before 3.0.0 do not read the file. |
| Agent Skills frontmatter | Every SKILL.md starts with name and description. The library gate reported 11 skill(s) have valid frontmatter. The rule skips outside this library. A missing parser is a failure. |
| Compact entrypoints | Five skills keep their previous text in references/archive-v2.14.md. The suite checks line count, required sentences, and links. |
| Paths and state | The library classifies an external project, a path with spaces, a linked worktree, and corrupt state versus missing state. |
| Authored schemas | YAML is the contract. JSON is generated from it. Skeptic reports have a schema. refactor-plan.md stays unmatched on purpose. A schema-valid file is not a gate result and not an authorization. |
| Jail, on the tested host | Tests that must run go through unshare and then chroot. Symlink, absolute path, secret environment, output directory, snapshot, and network checks passed on the Linux host that ran the suite. |
| Model selection | An omitted model stays inherit. An unsupported name is not replaced. No commercial model is required. |
| Fingerprint replay | The same edge returns the recorded result. A different fingerprint on that edge is STOP-4. Child transitions share the budget. |
| Snapshot-bound evidence | A stale dirty tree fails the evidence check. A missing record is NOT_RUN. A skip summarizes as NOT_RUN. |
| Offline eval harness | Sixteen fixtures, two held out, and scripts/v3_suite.py. The recorded suite is 101 pass, 0 fail, 3 NOT_RUN. Parity is 384/384. --dry-run prints the plan and does not call a model. The fake-runtime driver test called no model. |
| Plugin manifest, beside the clone | Marketplace name ssd, plugin ssd at 3.0.0, no bin/. The owner’s claude plugin validate . passed with warnings, and both warnings are addressed. Clone install still prints 3.0.0. The two installs can coexist. |
| Portable export | The bundle is format-validated. Closure passed. unattended_run is false. It was not installed on a host. |
| Finding certification, on a fixture | findings.certify ignores a model-supplied gate_pass, grades a planted inventory, and rejects a missing runner. That grade is of a fixture, not a live review. |
| Hook adapter, in process tests | hooks/hooks.json calls the adapter. Empty and malformed payloads grant nothing. A PreToolUse timeout does not block. Process tests for empty, malformed, deny, post-tool, and stop passed. |
The code is in the tree. A live session did not exercise it. NOT_RUN is not a pass.
| Shipped, unproven live | What was not run |
|---|---|
| Live eval driver | Wired for claude -p (non-bare) and the Anthropic Messages API, with SSD_EVAL_SPEND_CEILING checked before each call and during a stream. Unknown cost stays unknown, and later calls do not start. No live model was called. Arm A stays on baseline e732a93 and was not executed. |
| Role subagents | agents/ssd-architect.md, ssd-coder.md, and ssd-reviewer.md are in the tree, with a delegation schema. A valid envelope is not permission to act. No host dispatched a role. |
| Hooks inside a Claude Code session | Process tests passed. Claude Code did not deliver an event, so host delivery is NOT_RUN. |
AGENTS.md in a session | The contributor guide and .claude/CLAUDE.md (@../AGENTS.md) are in the tree. Whether a session loaded them was not measured. A user project receives instructions only with consent. |
| Live finding recall | The fixture grade ignores gate_pass. That is not a live review, and live recall was not run. |
| Isolated review versus inline review | Inline review is labeled inline. No live comparison of isolated and inline review was run. |
Unattended run on other hosts | Certified only for the jail plus the external control directory on the Linux host that ran the suite. Everywhere else, doctor reports the gap and the effective mode stays propose. |
| A model reading the archives | The line check on the five compacted skills passed. “References were read by a model” was not run. |
| Live routing from frontmatter | The frontmatter lint passed. Routing those descriptions against a live model was not run. |
Each row names its category: deferred, not done yet, or excluded by design.
| Category | Not in 3.0 today |
|---|---|
| Deferred | T26. Coded workflows. No workflow file, and no measured benefit. |
| Deferred | T27. Secondary verification of disputed findings. It is off, and it is not implemented. |
| Deferred | T28. Specialist fan-out. The reviewer does not fan out into a milestone audit. |
| Deferred | T29. Cloud routines. No cloud credentials, and no routine that posts anywhere. |
| Deferred | T30. Usage export beyond unknown token counts. Token counts stay unknown. There is no export. |
| Deferred | T31. MCP. No client was identified, and no MCP tool is registered. |
| Deferred | T32. Spec Kit. No adapter, and a mapping was not executed. |
| Deferred | T33. Clone retirement. Clone installation stays. No deprecation date is set. |
| Not done yet | v3.0.0 tag. Nothing has been tagged v3.0.0. The latest tag remains v2.14.0. |
| Not done yet | GitHub release. No GitHub release has been published for 3.0.0. |
| Not done yet | Marketplace directory listing. marketplace.json is in the repo. It has not been submitted to a marketplace directory. |
| Not done yet | Clean-host plugin install. /plugin marketplace add and /plugin install ssd@ssd match the manifest. They were not recorded as run. |
| Not done yet | Five-user pilot. The protocol is written. No pilot session was held. |
| Not done yet | Live eval baseline. Three live repetitions of arm A, pinned at e732a93, were not executed. A missing baseline stays NOT_RUN and is not copied from HEAD. |
| Excluded by design | No --force. No script accepts the flag. Overriding a red gate means merging on purpose and writing the reason down. |
| Excluded by design | No automated ship. /ssd ship is the human path. --until ship is FM-4. A lock is not a grant. |
| Excluded by design | CI is informational. The four workflow checks can pass, and they did on d6f23bd. The ruleset does not list them as required status checks. |
The Guide has the commands. This list is the boundary.
Shippable States Development (SSD) — a pragmatic AI-powered software engineering discipline developed by Alex Horovitz that requires maintaining a deployable, production-ready state at all times. SSD replaces sprint-based release cycles with continuous-deployment discipline amplified by AI-assisted tooling. Practiced from solo developers to enterprise engineering organizations. Published at insanelygreat.com.
SSD is a toolkit, not a doctrine. Per Agile², process is a tool — if a practice here doesn’t increase your velocity, change it. I’ve adapted these disciplines to two-person startups and hundred-thousand-person manufacturers; the constant is measurement, not ceremony.
Shippable States Development (SSD) is a pragmatic AI-powered software engineering discipline in which a codebase is kept deployable at all times and a shipping event occurs every day without exception. Originated by Alex Horovitz, it is practiced by solo developers and by engineering organizations of thousands.
SSD differs from Continuous Delivery in one crucial respect: Continuous Delivery guarantees that software can be shipped at any time, while Shippable States Development requires that it is ship every development day. A development day without a ship is treated as a process failure, not a neutral outcome.
Over thirty years of building software — at NeXT, Apple, Bank Boston, Lehman Brothers, Disney, the NFL, Symantec, Intel, Apple (again), Ford, and now Snowcap Compute — I have made most of the mistakes there are to make. Death marches. Features that shipped broken. Teams that burned out. Codebases that became impossible to change. Projects that were "90% done" for six months. I know exactly how each of those stories ends.
InsanelyGreat's SSD exists because those lessons have real value to the next generation of developers. And that value multiplies only when it's shared freely. The goal has never been to monetize a methodology. The goal is to help engineers and the organizations they work in — from one person to a hundred thousand — build excellent software without having to repeat thirty years of avoidable mistakes to get there.
So this is published rather than sold: an open methodology, with the tooling that implements it in a public repository. Take it, fork it, argue with it, delete the parts that don’t fit your organization. A discipline earns its keep only by being used, and the fastest way to find out whether an idea is any good is to put it where people can test it against their own reality.
Public repository. No sign-up, no paywall, no license to negotiate.
Traditional development front-loads the visible work and back-loads the dangerous work. The result is predictable.
Every project has exactly three variables. You can fix at most one. The other two must flex.
What features and capabilities ship
When the software ships
How well it works in production
Most project failures come from pretending you can fix all three.
Pick your constraint. Let the others flex. Ship working software.
Simple ideas. Profound consequences — whether you're a team of one or twenty.
Your development environment must match production from Day 1. Deploy "Hello World" to production before writing any business logic. Deployment is never "the hard part" because you do it constantly. Production issues surface immediately when they're easy to fix.
At the end of each work session, the system must be in a state where all tests pass, no broken user-facing features exist, and it could be deployed to production without embarrassment. Not feature-complete. Just actually working.
Long-lived feature branches cause merge hell. All work happens on main, behind flags, off by default. Feature exists in production but is invisible until ready. No "works on my branch" syndrome.
Forward progress only. Every commit improves the system in some measurable way. No WIP commits. No "I'll fix the tests tomorrow." No commented-out code. The ratchet only moves forward.
Reducing scope is not failure — it's engineering judgment. Break work into independently shippable units. Prioritize ruthlessly. Ship whatever is complete and working by the deadline, not everything broken.
Concrete techniques that bring the principles to life in daily practice.
The SSD orchestrator now treats parallel workstreams as first-class. Multiple features, multiple branches, optional git worktrees, and overlap detection at gate time — all wired into the standard /ssd flow.
Run up to four workstreams in parallel against the same repo. Each gets its own branch, optional worktree, and tracked file footprint. The single-feature flow remains the default — parallel is opt-in.
/ssd switch <slug> pauses the current workstream, captures a handoff note, and checks out the target. No git stash dance, no losing your place.
/ssd feature new <slug> --worktree creates a separate working directory so two features can be edited side-by-side without checkout churn. Single-tree workflow is still the default.
When two workstreams touch the same files, /ssd gate raises a suggestion-tier warning — never a blocker. Overlap is often intentional; the orchestrator surfaces, you judge.
Running /ssd (no arg) on any branch resolves to the right workstream automatically. Branch name, recorded mapping, then prompt — in that order.
/ssd gate before merge. Parallelism reduces switching friction; it does not lower the bar.
The orchestrator has always proposed and waited. It still does, by default. Since v2.14.0 you can opt into letting it execute its own proposal — bounded by a ceiling it cannot raise, refereed by an executable gate, and written to disk before it acts. 3.0 does not raise that ceiling. It puts shipping authority in a grant that lives outside the repo.
propose — the defaultReads your state, proposes the next action, waits for you. This is what every SSD project does today, and the default is absence: with no autonomy block configured, the orchestrator makes no additional call at all.
advance — one stepBare /ssd executes its own top proposal when exactly one unambiguous next action exists. One phase per invocation, unconditionally. Anything ambiguous falls back to proposing, and falling back is not a failure.
run — the loop/ssd run <slug> walks design → code → review → gate unattended, looping coder and reviewer until the gate passes or a budget stops it. --dry-run prints the plan and writes nothing.
ship, deploy, publish, release, rollout-advance and flag-removal need a grant stored outside the repository. The grant is one use and matches one snapshot. A feature is bounded by two human decisions — the brief at the start, the ship at the end.
Every transition is narrated, then written to disk, and only then executed. The ordering is the whole claim: announce-then-act is a courtesy that evaporates when nobody is watching, which is the only time this feature gets used.
A run records the executable gate's exit status, not a boolean it wrote about its own work — and an outcome separate from why it stopped. Reaching the ceiling is not the same as succeeding, and a record that cannot tell those apart launders the difference.
--force, and that is the feature. The ceiling, the lock, the rails, and the budgets are exit codes in a script. This library once described a --force override in four files for eleven releases while no script accepted the flag. 3.0 still has no such flag. Unattended run is certified only where the jail and the outside control directory both work. /ssd resume continues a record and does not hand shipping authority back.
On day 30 you should be able to deploy to production with confidence in under 10 minutes.
InsanelyGreat’s SSD and all the Claude Code skills are public — the methodology and the tooling that implements it. No sign-up, no paywall, no license to negotiate. Clone it, run it, and change the parts that don’t earn their keep where you work.
The full InsanelyGreat's SSD Claude Code skill set — architect, coder, reviewer, skeptic, epistemic auditor, and more — is public and free to clone. Works today with Claude Code.
View on GitHubThe complete guide — principles, patterns, gates, and the practice of holding a system in a shippable state, whether you are one engineer or a thousand.
Read the GuideAlso available as a hands-on tutorial
The library on main is 3.0.0. Pull request #58 merged on 12 October 2026 (squash c6dd481, the same tree as d6f23bd). There is no v3.0.0 tag and no GitHub release. A clone of main prints 3.0.0. What shipped, what is wired but not verified live, and what is out is the inventory. The 2.x behavior it keeps stays documented in the Guide, with a migration note.
Shippable States Development (SSD) is a pragmatic AI-powered software engineering discipline in which a codebase is kept deployable at all times and a shipping event occurs every day without exception. It was originated by Alex Horovitz. The core claim is that daily shipping is not an aspiration but a design constraint — the codebase, tests, and workflows are all organized to make shipping today trivially achievable.
Continuous Delivery ensures that software can be shipped at any time. Shippable States Development requires that software is shipped every day. The difference is the mandatory cadence: SSD treats a day without a ship as a process failure, not a neutral outcome.
Shippable States Development was originated by Alex Horovitz and is published at insanelygreat.com/ssd.html.
SSD is well-suited to solo developers and small teams building production software, particularly those leveraging AI coding tools like Claude Code. It scales up as well — the same discipline has been adapted to large engineering organizations, where the constraint is usually the handoff between teams rather than the work inside them. It fits anywhere forward motion and frequent feedback matter more than ceremony.
SSD is a poor fit when shipping cadence is constrained by factors outside the team's control — regulated environments requiring formal change boards (medical device firmware, avionics, some financial systems), mobile app store review cycles that cap shipping frequency, or enterprise customers who contractually reject frequent updates. It is also inappropriate for research code and throwaway prototypes, where there is no production environment to ship into. In those cases, the daily-ship discipline becomes theater rather than a forcing function.
SSD requires three concrete practices: (1) the main branch is always deployable, so broken builds are treated as incidents; (2) every day includes a visible shipping event — a release, a deploy, or a user-facing change; (3) work is decomposed into pieces small enough to complete and ship within a day, which in practice means aggressive vertical slicing and a willingness to ship incomplete-but-correct functionality behind feature flags.
Only if you opt in, and the ceiling is unchanged in 3.0. The autonomy ladder is propose (the default: it proposes and waits), advance (one unambiguous phase), and run (design → code → review → gate, until the gate passes or a budget stops it). Ship, deploy, publish, rollout, and flag removal need a one-use grant outside the repository, bound to the snapshot you named. There is no --force. /ssd resume continues an interrupted record and does not restore that grant. Unattended run is certified only for the tested jail; elsewhere the effective mode stays propose. Every transition is announced, written to disk, and only then executed. A green run records the gate script’s exit status. If your gate mostly skips, that green means only that nothing which ran objected.
Yes. Parallel workstreams are first-class in SSD (since the v1.17 skill set, and still current in 3.0). The orchestrator supports up to four active workstreams per project, each on its own branch and optional git worktree. /ssd feature new <slug> creates a workstream; /ssd switch <slug> pauses the current one and checks out the target (with an automatic handoff note); /ssd gate detects cross-workstream file overlap and surfaces it as a non-blocking suggestion. The Shippable State Invariant still holds per workstream — parallelism reduces switching friction, it does not lower the bar.
For teams of 1–5, the best methodology is the one that keeps software deployable every day. Most popular methodologies — Scrum, SAFe, even traditional Kanban — were designed for 5–50 person teams at funded organizations. Their ceremonies cost more than they deliver at small team size. Shippable States Development (SSD) originated in exactly that context. See Software Engineering Methodologies for Small Teams: An Honest Comparison.
A solo developer is the product manager, the QA, the DevOps engineer, and the developer. The only way to survive this is to make every role automatic. SSD is the discipline that automates the roles you can't hire for: CI handles QA, feature flags handle release management, and the daily ship handles project management. See The Solo Developer's Engineering Manifesto.
Treat quality as a ratchet, not a pendulum. Every commit must improve the system in some measurable way: tests pass, no broken features, no commented-out code, no "WIP" left on main. Encode the ratchet in CI so it cannot move backward. See Code Quality Without a QA Team: The Ratchet Principle.
Standard Scrum was designed for a 5–9 person team with a dedicated Scrum Master and Product Owner. Below 3 people, the ceremony costs more than it delivers. The strongest alternatives are SSD (continuous shipping, no sprints), Shape Up (six-week cycles, betting table), and minimal Kanban (WIP limits and pull, no ceremonies). See Why Standard Scrum Fails Small Teams.
Stop managing releases as events. With continuous deployment plus feature flags, a "release" becomes a flag flip and a changelog entry. The work that used to require a release manager — coordination, QA gating, rollback planning — gets distributed into the daily work and automated tooling. See How Small Teams Should Think About Releases.
Most lifecycle complexity exists to manage deployment fear. Remove the fear by deploying constantly, and 80% of the ceremony dissolves. What survives: CI, feature flags, the Nightly Ritual. What dies: sprints, release branches, change advisory boards, QA gates as separate phases. See The Simplest Engineering Lifecycle That Actually Works.
Follow the four-week onboarding plan above: Week 1 — wire CI/CD and ship "Hello World" to production; Week 2 — ship one feature end-to-end behind a flag; Week 3 — establish daily deploy rhythm; Week 4 — optimize deploy time and remove old flags. The full Guide walks through each step in detail.
No shortcuts. No "we'll fix it later." No broken code on main. The payoff: no death marches, predictable delivery, high quality, low stress.
Read the full guide