sdlc-harness
A reusable agentic SDLC harness. Brings principled, evidence-backed,
cross-model-reviewed software delivery to any project that uses
Claude Code (and works with Codex CLI
for cross-model adversarial / security review).
Inspired by obra/pstack
(Lauren Tan / poteto / Cursor) and designed as an adopter-ready template for
Claude Code projects.
What you get
| |
|---|
Role agents (.claude/agents/*.md) | 5 specialized roles: planner (intake / design / plan phases), builder (implementation), reviewer (quality / qa / adversarial / acceptance modes), security, release. Each cites principles by name + has clear hand-off rules. (Collapsed from 10 in v1.0 — see docs/MIGRATING_v1.0_to_v1.1.md.) |
Slash commands (.claude/commands/feature-*.md) | /feature-init, /feature-loop, /feature-review, /feature-context, /feature-claim, /feature-next-task, /feature-verify, /feature-ready, /feature-reconcile, /feature-amend, /feature-reflect, /feature-why, /feature-arena. |
Principles (docs/principles/) | 5 universal principles + a README index. Meta-principle: principle-encode-lessons-in-structure — when a rule recurs, encode it as a script/check, not more prompt text. |
Feature templates (docs/features/_template{,_medium,_small}/) | Three tiers: small (1 file), medium (5 files), large (19 files). |
Scripts (scripts/) | Deterministic feature lifecycle (init/context/next-task/verify/ready/reconcile), credential preflight, cross-model wrappers (adversary-review, security-review) backed by Codex CLI, shared sensitive-data sanitizer (lib-sanitize.sh), test harness (test-framework-v3). |
Bash guard hook (.claude/hooks/guard-bash.sh) | Blocks destructive git operations + raw codex invocations. |
Domain packs (examples/domains/) | Optional starter configuration for common project shapes such as web apps, services, and CLI tools. |
Shareable docs (docs/share/*.html) | Standalone browser-ready versions of the overview and workflow docs, formatted for easy reading and sharing. |
How to use it
There are two install paths. Pick whichever fits your project.
Path 1 — Plugin install (Claude Code v2.1+)
Adds the framework as a Claude Code plugin. Slash commands are
namespaced (/sdlc-harness:feature-init), scripts and agents are
loaded from the plugin's cache directory. Easiest to update (one
command) but you can't customize the framework files directly without
forking.
/plugin marketplace add manish-dharod/sdlc-harness
/plugin install sdlc-harness@sdlc-harness
Then try a slash command:
/sdlc-harness:feature-context <slug>
To update: /plugin update sdlc-harness. To uninstall: /plugin uninstall sdlc-harness.
Path 2 — Template clone (clone-and-customize)
The original install pattern. Copies the framework files directly into
your project's .claude/ dir. Slash commands are un-namespaced
(/feature-init). Easiest to customize — every framework file is
yours to edit — but updates are manual.
# In your project root:
git clone https://github.com/manish-dharod/sdlc-harness.git /tmp/sdlc-harness
# Copy the framework dirs into your repo:
cp -R /tmp/sdlc-harness/.claude/agents/*.md .claude/agents/
cp -R /tmp/sdlc-harness/.claude/commands/feature-*.md .claude/commands/
cp -R /tmp/sdlc-harness/.claude/hooks/ .claude/
cp -R /tmp/sdlc-harness/docs/principles/ docs/
cp -R /tmp/sdlc-harness/docs/features/_template* docs/features/
cp -R /tmp/sdlc-harness/scripts/ .
cp /tmp/sdlc-harness/docs/AGENT_SDLC_WORKFLOW.md docs/
# Commit as your initial framework import
git add .claude docs scripts
git commit -m "chore: import sdlc-harness framework"
Picking a path
| Aspect | Plugin install | Template clone |
|---|
| Slash command names | /sdlc-harness:feature-init (namespaced) | /feature-init (un-namespaced) |
| Customization | edit your own overlay; framework upgrades wipe local edits | every file is yours to edit |
| Updates | /plugin update sdlc-harness | re-run the cp -R commands manually |
| Version pinning | pinned to the marketplace's commit SHA | pinned to your import commit |
| Best for | adopters who want to consume the framework as-is | adopters who want to customize per-project |
Per-project customization
The framework is intentionally generic. There are three places you'll
typically customize:
1. Domain-specific principles
The framework ships 5 universal principles in docs/principles/:
principle-encode-lessons-in-structure (the meta-principle)
principle-prove-it-works
principle-fix-root-causes
principle-boundary-discipline
principle-no-production-deploys-from-loop