A free-for-personal-use skill set for Claude Code that implements Shippable States Software Development — a pragmatic engineering discipline for solo developers and small teams. Platform-adaptive: web, iOS, Android, macOS, and headless.
Core invariant: If you can't ship it right now, you don't have a product — you have a construction site.
Learn more: insanelygreat.com
InsanelyGreat's SSD keeps software in a deployable, production-ready state at all times. It synthesizes continuous deployment, trunk-based development, and feature flags into a workflow a single developer can actually maintain — amplified by Claude Code at every step.
Five principles:
- Constant Production Parity — Deploy "Hello World" on Day 1. Deployment is never "the hard part."
- The Shippable State Invariant — Every session ends with passing tests and nothing broken.
- Feature Flags Over Feature Branches — All work on main, behind flags, off by default.
- The Ratchet Principle — Forward progress only. No WIP commits, no "fix tomorrow."
- Scope Flexibility Is a Feature — Cutting scope is engineering judgment, not failure.
Start with /ssd. It is the entry point for all SSD workflow phases. The other skills are invoked automatically by /ssd — you do not need to call them directly unless you are working outside the SSD workflow.
/ssd feature ← standard development session
/ssd start ← new project or major feature
/ssd gate ← quick shippable state check
| Type | Skills | When you invoke directly |
|---|---|---|
| Orchestrator | ssd |
Always — start here |
| Domain | architect, coder, systems-designer, refactor |
When working outside the SSD workflow |
| Review | code-reviewer, codebase-skeptic, software-standards |
On-demand or via SSD |
| Reference | methodology |
When you want to understand SSD doctrine |
The orchestrator. Sequences the right sub-skills for each development phase.
/ssd start — New project or major feature: Walking Skeleton setup
/ssd feature — Active development: design → build → review → deploy loop
/ssd milestone — Post-sprint consolidation: deep audit + targeted refactor
/ssd gate — Shippable state check only (code-reviewer)
/ssd ship — Deploy readiness check only (systems-designer checklist)
/ssd audit — Adversarial comparative review (nuclear option)
| Skill | Role |
|---|---|
/architect |
Design: models, services, API contracts. Platform-adaptive (web, iOS, Android, macOS, headless) |
/systems-designer |
Production readiness: reliability, observability, deployment safety |
/coder |
Implementation from spec (Python, TypeScript, Swift, Ruby, Java, C#, PHP, Go, Rust, C/C++, Obj-C) |
/code-reviewer |
PR gate: BLOCKER/MAJOR findings block merge |
/codebase-skeptic |
Deep architectural critique through 10 expert lenses |
/software-standards |
Adversarial comparative audit |
/refactor |
Post-ship targeted improvement |
/methodology |
SSD methodology reference |
Clone the repo into your Claude Code skills directory:
git clone https://github.com/AlexHorovitz/skills ~/.claude/skillsThen invoke any skill from Claude Code:
/ssd feature
/coder
/code-reviewer
- No merge without a clean
/ssd gate— No BLOCKER or MAJOR findings. No exceptions. - No incomplete work on main without a feature flag — WIP commits on main are banned.
- Tests must pass before and after every change — "I'll fix the tests tomorrow" is not a shippable state.
- Refactor only after shipping — Separate PRs, never mixed with feature work.
- Deploy beats perfection — Reduce scope rather than delay a deploy.
- Production parity from day one — If you haven't deployed to production yet, that is your next task.
Contributions are welcome. All content in this repo is Markdown — there is no code to compile or test suite to run. The bar for a good contribution is whether Claude follows the guidance accurately and produces better outcomes than it would without it.
- Fixes — Incorrect advice, outdated API references, broken examples, typos
- Additions — Missing patterns, platforms, or frameworks that belong in an existing guide
- New platform guides — A new
architect/subdirectory for a platform not yet covered (e.g.,watchOS,tvOS,embedded,visionOS) - New framework guides — A new
architect/web/frameworks/file for a web framework not yet covered (e.g.,sveltekit,remix,nestjs). Copyarchitect/web/frameworks/TEMPLATE.mdand fill in each section to ensure structural parity with existing guides - New skills — A complete
SKILL.mdfor a workflow not yet covered
- Promotional content, vendor recommendations without technical rationale
- Vague or aspirational guidance ("always write clean code") without actionable specifics
- Anything that contradicts the SSD core invariant (shippable state at all times)
- Fork the repo
- Make your changes on a branch
- Open a pull request with a clear description of what changed and why
These files are read by Claude, not rendered as a website. Write for clarity and precision over prose elegance.
- Be specific. "Use PostgreSQL" is better than "use a relational database."
- Give the rule, then the rationale. State the decision first, explain why second.
- Include the counter-case. Every "always do X" is more useful when paired with "except when Y."
- Concrete examples over abstractions. A short code block or table beats three paragraphs.
- Match the existing tone. Direct, opinionated, no hedging.
Each skill or guide follows this pattern:
skill-name/
└── SKILL.md — the skill itself (invoked by /skill-name in Claude Code)
architect/
└── platform/
└── GUIDE.md — platform-specific reference, loaded by the architect skill
SKILL.md and GUIDE.md files begin with a one-line license reference: <!-- License: See /LICENSE -->. The full license terms live in the LICENSE file at the repository root.
© 2026 Alex Horovitz. Shareware license — free for personal and internal organizational use. See LICENSE for details.
If SSD saved you a death march or helped your team ship with less stress, consider a small donation: venmo.com/alex-horovitz · $20 suggested · entirely optional