What Does iSDLC Add to Claude Code?

Claude Code is already capable. iSDLC adds structure, control, and traceability on top.

THINK — Planning Before Action

Both Claude Code and iSDLC believe in thinking before acting. The difference is altitude — tactical vs strategic — and what survives after the session ends.

CLAUDE CODE — Plan Mode
Tactical: This Edit Session
📋
One agent thinks out loud — Claude shows its approach for the edits it's about to make, in the current conversation
⏱️
One-turn interaction — approve or reject the plan, then Claude executes or stops
💨
Ephemeral — the plan lives in chat. If rejected, nothing persists. No files, no specs, no record
🔍
Ad-hoc codebase reads — Claude reads files as needed, no structured scan
🎯
Scope — "Before I touch these 6 files, here's my approach"
iSDLC — Analyse
Strategic: The Whole Feature
👥
Three perspectives by default — Business Analysis, Architecture, and Design examine the problem together. Teams can add more perspectives
🔄
Interactive conversation — 8-10 exchanges where the human drives every decision. Four-domain staged confirmation: Accept or Amend
📁
Durable artifacts — requirements spec, architecture overview, module design, task plan — all written to disk with traceability
🔬
Deep codebase analysis — semantic search, impact analysis, blast radius, dependency mapping, risk scoring
📐
Scope — "Before we build this, here's the spec the build will execute against"
EXECUTE — Turning Plans Into Code

Claude Code already executes well — it spawns parallel agents, runs tests, retries on failure, and reviews its own work. iSDLC adds structured phases, user-defined guardrails, and configurable control over how all of that happens.

CLAUDE CODE — Native Execute
Capable, Self-Directed
Capable execution — spawns parallel agents, uses agent teams, edits multiple files concurrently. Not limited to linear edits
🧪
Testing is Claude-directed — Claude decides when and how to test. TDD and ATDD are possible but not structurally enforced — no user control over test strategy
👀
Review is Claude-directed — Claude reviews its own work, but the developer has limited structured control over review criteria or coverage checks
🔄
Retries on failure — Claude retries when things break, but the retry strategy, escalation path, and circuit-breaker thresholds are not user-configurable
📝
No structured audit trail — work is captured in git history but not connected to requirements, acceptance criteria, or a traceable task plan
iSDLC — Build (adds structure)
Structured, User-Controlled
🏗️
Defined phases — test strategy → implementation → quality loop → code review. Each phase has a dedicated specialist, clear entry/exit criteria, and gates
🧪
Test-first enforced — the test strategy phase runs before implementation begins. The quality loop iterates until tests AND automated QA both pass. The team controls the coverage thresholds
🛡️
User-defined guardrails — constitutional validation, blast-radius coverage, iteration corridors. 36 runtime guardrails, all configurable by the team
🔄
Controlled retry + escalation — configurable retry limits per gate, circuit-breaker thresholds, and explicit escalation to human when automated retries are exhausted
Dependency-ordered parallel dispatch — tasks from the analysis plan are sorted into tiers and dispatched in parallel, with dependency tracking and per-task traceability
📊
Full traceability — every task traces to acceptance criteria. Every change traces to the task plan. Every review is recorded against defined check categories
PERSIST — What Survives After the Session

The real test of a development process: what exists after the developer closes the terminal?

CLAUDE CODE
Git History Only
📂
Modified files in the working tree
📜
Git commits — if the developer remembered to commit
💬
Chat history — lost when the session ends or compresses
No connection between the change and the requirement that prompted it
iSDLC
Complete Artifact Trail
📋
Requirements spec — what was asked for, with acceptance criteria and priorities
🏛️
Architecture decisions — options evaluated, selected approach, rationale
📐
Design specification — module boundaries, interfaces, data flow
Task plan — file-level breakdown with dependencies, traces to AC, completion status
🧪
Test strategy + results — what was tested, coverage, quality report
🔍
Code review record — per-file review against 8 check categories, constitutional compliance
📊
Visual diagrams — architecture and design diagrams generated alongside the specs
🔗
Bidirectional traceability — requirement ↔ design ↔ task ↔ test ↔ code change ↔ review

iSDLC Provides Structure to Claude Code

Claude Code is the engine. It spawns agents, edits files, runs tests, retries on failure, reviews code. These are powerful capabilities. iSDLC does not replace any of them — it adds a structured layer on top that gives teams control over how those capabilities are applied.

For tactical work — quick fixes, exploratory changes, one-off refactors — Claude Code's native capabilities are the right tool. Plan mode, direct execution, ad-hoc testing. Fast and flexible.

For structured work — features, bugs, and changes significant enough to warrant requirements, design, testing, review, and traceability — iSDLC provides the phases, the guardrails, the confirmation gates, and the audit trail that keep multi-file, multi-hour work consistent and traceable.

The trivial tier is the bridge — when analyse concludes a change is small enough, the build skips the full workflow and executes with Claude Code's native capabilities plus a lightweight audit trail. The framework adapts to scope, not the other way around.

The extensibility is the differentiator — the constitution, the perspectives, the skills, the guardrails, and the finalization checklist are all configuration-driven and hackable. Teams shape the framework to their standards; the framework doesn't impose a one-size-fits-all process.

In practice, they stack: Discover sets up the project knowledge → Embeddings enable semantic search → Test Generate captures existing behaviour → Add tracks work items from GitHub or Jira → Analyse produces the spec through interactive conversation → Build executes the spec automatically. Each stage's output feeds the next. Plan mode and native execute remain available for ad-hoc work between workflow runs.

iSDLC End-to-End Workflow

Intelligent Software Development Lifecycle Harness
Agent
Process
Artifact
Hook
Decision
Click Play to start
or click any stage
setup
1
DISCOVER
/discover
discover-orchestrator
⇣ parallel fan-out
arch-analyzer
test-evaluator
feature-mapper
constitution-gen
skills-researcher
constitution.md
architecture skill
conventions skill
domain skill
test-landscape skill
characterization tests
session cache
Setup — Parallel agents analyse codebase, produce constitution + skills + test scaffolds.
setup
2
EMBEDDINGS
isdlc-embedding generate
Tree-sitter Chunker
Jina v2 Base Code
↓ CoreML fp16
768-dim vectors
.emb (vector index)
MCP Server :7777
semantic_search
list_modules
Search — AST-aware chunks → vectors → cosine search → MCP. Enables semantic search for all agents.
setup
3
TEST GENERATE
characterization scaffolds exist?
test-design-engineer
software-developer
↓ task-level dispatch
quality-loop ∥
qa-engineer
test-strategy.md
test files
quality-report.md
Phase loop — Scaffolds → test strategy → implementation → quality → review.
daily
4
ADD
add "#N" / "PROJECT-N" / "description"
GitHub
gh issue view #N
title, labels, body
Jira
Atlassian MCP
summary, type, priority
Manual
reverse-lookup
match or create GH issue
docs/requirements/
└─ REQ-GH-{N}-{slug}/
├─ draft.md
└─ meta.json
BACKLOG.md [ ] entry
Inline — No workflow, no state.json, no branch. Under 5 seconds.
daily
5
ANALYSE — Roundtable
resolve item
Bug / Feature?
parallel (T=0)
GH/Jira fetch
memory read
persona + topics
docs/requirements/
└─ {REQ|BUG}-GH-{N}-{slug}/
├─ draft.md
├─ meta.json
├─ requirements-spec.md ←
├─ architecture-overview.md ←
├─ module-design.md ←
└─ ... (written at finalization)
Maya (Business Analyst)
Alex (Solutions Architect)
Jordan (System Designer)
Security Reviewer
DevOps Reviewer
QA Tester
Domain Expert
↓ 8-10 exchanges
state card
task card
rolling state
trailer + markers
Requirements ✓
Architecture ✓
Design ✓
Tasks ✓
Amend → restart from top
↓ batch write
requirements-spec.md
user-stories.json
traceability-matrix.csv
impact-analysis.md
architecture-overview.md
module-design.md
interface-spec.md
data-flow.md
error-taxonomy.md
design-summary.md
quick-scan.md
tasks.md
architecture-diagram.excalidraw
design-diagram.excalidraw
State-machine-driven — card composition per turn, skills at sub-task granularity, hybrid rolling state.
can run
concurrently
on different
items
tasks.md
user-confirmed task plan
→ feeds phase 06 dispatch
daily
6
BUILD
create branch
init state.json
tasks.md → docs/isdlc/ → readTaskPlan()
parse phases, tiers, blocked_by → TaskCreate per phase
test-design-engineer
critic
refiner
debate loop (optional)
software-developer
reviewer
updater
assignTiers() → dependency-ordered parallel dispatch
TIER 0
T001
T002
T003
TIER 1
T004
T005
TIER N
T...
each task: [ ] → [X]
fail: retry 3× → escalate → skip
TRACK A — Testing
integration-tester
build + test + coverage
TRACK B — QA
qa-engineer
SAST + audit + review
loop until both tracks pass
tasks.md phases marked COMPLETE
qa-engineer
logic · errors · security · constitutional
all [ ] → [X]
100% coverage verified
tool-router
branch-guard
gate-blocker
blast-radius
constitution
task-completion
test-watcher
state-validator
phase-loop-ctrl
F0001 merge branch
F0002 sync status
F0003 clear workflow
F0004 task cleanup
F0005 session cache
F0006 contracts
F0007 code index
F0008 memory embeddings
F0009 code embeddings
BACKLOG.md [x]
GH issue closed
Phase loop — Task-level dispatch, hooks enforce at every boundary, 9-step finalize checklist.