Eleven scopes, one set of 33 stages. Which one fits your work?

The course runs used two scopes: express (10 stages) and feature (all 33). AI-DLC 2.11 ships eleven. A scope is not a different method: it is a list of which stages run, plus a few switches (depth, reviews, sensors, learnings). This page lays all eleven side by side from the engine's own output, shows how the tool picks one from your words, and what /aidlc compose proposed for a real bug in this course's API. The tables, the detection results and both compose replies are real 2.11.0 output from 17 Oct 2026; the switches in step 7 are documented, not run.

11scopes shipped with 2.11

33stages in five phases

8–33stages per scope

4stages every scope runs

2stages compose kept for the bug

0intents created on this page

The menusteps 1–3 · what the tool ships

real

The 33 stages every scope picks from

One graph of 33 stages in five phases. A scope never adds a stage of its own; it chooses from these. "Always" means the stage runs whenever its scope includes it; "conditional" stages can also skip themselves at run time (Operation skipped itself in the express run because there was no pipeline).

aidlc engine gen stage-table

You type read-only

aidlc engine gen stage-table

#	Stage	Phase	Runs	Lead agent
0.1	Workspace Scaffold	Initialization	always	(orchestrator)	every scope
0.2	Workspace Detection	Initialization	always	(orchestrator)	every scope
0.3	State Initialization	Initialization	always	(orchestrator)	every scope
1.1	Intent Capture & Framing	Ideation	always	product
1.2	Market Research	Ideation	conditional	product
1.3	Feasibility & Constraints	Ideation	conditional	architect
1.4	Scope Definition	Ideation	always	product
1.5	Team Formation	Ideation	conditional	delivery
1.6	Rough Mockups	Ideation	conditional	design
1.7	Approval & Handoff	Ideation	always	delivery
2.1	Reverse Engineering	Inception	conditional	developer
2.2	Practices Discovery	Inception	conditional	pipeline-deploy
2.3	Requirements Analysis	Inception	always	product	every scope
2.4	User Stories	Inception	conditional	product
2.5	Refined Mockups	Inception	conditional	design
2.6	Domain Design	Inception	conditional	architect
2.7	Units Generation	Inception	always	architect
2.8	Contract Design	Inception	conditional	architect
2.9	Delivery Planning	Inception	always	delivery
3.1	Functional Design	Construction	conditional	architect
3.2	NFR Requirements	Construction	conditional	architect
3.3	NFR Design	Construction	conditional	architect
3.4	Infrastructure Design	Construction	conditional	aws-platform
3.5	Code Generation	Construction	always	developer
3.6	Build and Test	Construction	always	quality
3.7	CI Pipeline	Construction	conditional	pipeline-deploy
4.1	Deployment Pipeline	Operation	conditional	pipeline-deploy
4.2	Environment Provisioning	Operation	conditional	aws-platform
4.3	Deployment Execution	Operation	conditional	pipeline-deploy
4.4	Observability Setup	Operation	conditional	operations
4.5	Incident Response	Operation	conditional	operations
4.6	Performance Validation	Operation	conditional	quality
4.7	Feedback & Optimization	Operation	conditional	operations

4 stages are in every scope: 0.1 Workspace Scaffold, 0.2 Workspace Detection, 0.3 State Initialization, 2.3 Requirements Analysis. Everything else is the scope's choice. Lead agents are the personas in .claude/agents/; a stage's support agents join only when collaborators are on.

In plain words. A scope is a menu order, not a different kitchen. The dishes (stages) are the same; a bug fix orders four of them, a regulated feature orders all of them.

real

Eleven scopes, side by side

Each column is the engine's own stage list for that scope (aidlc engine graph scope <name>), ordered from smallest to largest. A dot means the stage is in the plan; it can still skip itself if it is conditional.

aidlc engine graph scope

You type read-only

aidlc engine gen scope-table
aidlc engine graph scope bugfix

Stage	poc	bugfix	express	refactor	sec-patch	infra	classic	mvp	workshop	feature	enterprise
Initialization
0.1 Workspace Scaffold	●	●	●	●	●	●	●	●	●	●	●
0.2 Workspace Detection	●	●	●	●	●	●	●	●	●	●	●
0.3 State Initialization	●	●	●	●	●	●	●	●	●	●	●
Ideation
1.1 Intent Capture & Framing	●	·	·	·	·	·	·	●	·	●	●
1.2 Market Research	·	·	·	·	·	·	·	·	·	●	●
1.3 Feasibility & Constraints	·	·	·	·	·	·	·	●	·	●	●
1.4 Scope Definition	·	·	·	·	·	·	·	●	·	●	●
1.5 Team Formation	·	·	·	·	·	·	·	·	·	●	●
1.6 Rough Mockups	·	·	·	·	·	·	·	●	·	●	●
1.7 Approval & Handoff	·	·	·	·	·	·	·	·	·	●	●
Inception
2.1 Reverse Engineering	●	●	●	●	●	·	●	●	●	●	●
2.2 Practices Discovery	·	·	·	·	·	●	●	●	●	●	●
2.3 Requirements Analysis	●	●	●	●	●	●	●	●	●	●	●
2.4 User Stories	·	·	·	·	·	·	●	●	●	●	●
2.5 Refined Mockups	·	·	·	·	·	·	●	●	●	●	●
2.6 Domain Design	·	·	·	·	·	·	●	●	●	●	●
2.7 Units Generation	·	·	·	·	·	·	●	●	●	●	●
2.8 Contract Design	·	·	·	·	·	·	●	●	●	●	●
2.9 Delivery Planning	·	·	·	·	·	·	●	●	●	●	●
Construction
3.1 Functional Design	·	·	·	●	·	·	●	●	●	●	●
3.2 NFR Requirements	·	·	·	·	●	●	●	●	●	●	●
3.3 NFR Design	·	·	·	·	·	●	●	●	●	●	●
3.4 Infrastructure Design	·	·	·	·	·	●	●	●	●	●	●
3.5 Code Generation	●	●	●	●	●	·	●	●	●	●	●
3.6 Build and Test	●	●	●	●	●	·	●	●	●	●	●
3.7 CI Pipeline	·	·	·	·	·	●	·	●	●	●	●
Operation
4.1 Deployment Pipeline	·	●	●	●	●	●	·	·	●	●	●
4.2 Environment Provisioning	·	·	·	·	·	●	·	·	●	●	●
4.3 Deployment Execution	·	●	●	●	●	●	·	·	●	●	●
4.4 Observability Setup	·	·	●	·	·	●	·	·	●	●	●
4.5 Incident Response	·	·	·	·	·	·	·	·	●	●	●
4.6 Performance Validation	·	·	·	·	·	·	·	·	●	●	●
4.7 Feedback & Optimization	·	·	·	·	·	·	·	·	●	●	●
Stages	8	9	10	10	10	13	18	23	26	33	33

What the grid shows. The four incremental scopes (bugfix, express, refactor, security-patch) skip Ideation and keep Reverse Engineering: they work on code that exists. They differ by one stage each: refactor adds 3.1 Functional Design, security-patch adds 3.2 NFR Requirements, express adds 4.4 Observability. poc keeps only 1.1 from Ideation and stops at Build and Test: no deploy. infra is the only scope with no 3.5 Code Generation: it runs Practices Discovery, the NFR and infrastructure design stages, CI and Operation. feature and enterprise run all 33; they differ in depth and switches (step 3), not in stages.

In plain words. Read down a column to see what a scope will ask you about. Read across a row to see which kinds of work bother with that step at all.

real

What else a scope switches on

Besides the stage list, each scope file in .claude/scopes/ sets the depth of the artifacts and six switches. Blank means off. These are defaults: every one can be changed for one intent (step 7).

.claude/scopes/*.md

Scope	Depth	Stages	Skeleton	Reviews	Sensors	Learnings	Summary	Plan approval	Collab.	Guard	Keywords
poc Prove feasibility fast	Minimal	8	on	advisory	on	on	on			off	`proof of concept` `prototype` `poc` `spike`
bugfix Fix a specific bug	Minimal	9		advisory	on			on		off	`fix` `bug` `broken` `bugfix`
express Lightest run: requirements to deploy, no design pass, no reviewers	Minimal	10		none						off	`express` `lightweight`
refactor Clean up existing code	Minimal	10		full	on	on	on	on		off	`refactor` `clean up` `simplify`
security-patch CVE response	Minimal	10		full	on	on	on	on		off	`security` `CVE` `vulnerability` `patch`
infra Infrastructure changes	Standard	13	on	full	on	on	on	on		off	`infrastructure` `deploy` `infra`
classic V1-style ceremony through Inception and Construction - the implicit default	Standard	18		advisory	on	on		on		off	`[` `]`
mvp Skip operations, ship the core	Standard	23	on	full	on	on	on	on		off	`mvp` `minimum viable`
workshop Facilitated group session with mandatory gates	Standard	26	on	advisory	on	on	on	on		off	`workshop` `lab` `training`
feature Full lifecycle for new features, practical depth	Standard	33	on	full	on	on	on	on		off	`[` `]`
enterprise Regulated enterprise feature, full audit trail	Comprehensive	33	on	full	on	on	on	on	on	strict	`[` `]`

SkeletonBuild a walking skeleton first: the thinnest end-to-end slice, approved before other units start. Off for the incremental scopes: there is nothing to bootstrap.

Reviews, sensorsA reviewer agent checks the stage's output before the gate (advisory caps it; express has none). Sensors are automatic checks on file writes (traceability, required sections).

Learnings, summaryLearnings ask "Anything to add for next time?" after a stage. Summary confirmation restates your answers before a file is written. Both made the feature run longer; both are off in express and bugfix.

One sentence per scope, from its own file:
bugfix: Minimal depth for fixing one specific bug in an existing codebase. It skips ideation entirely (there is no new product to discover), runs reverse-engineering to understand the current code, pulls requirements for the fix, then generates, tests, and deploys it.
refactor: Minimal depth for cleaning up existing code without changing behaviour. Like `bugfix` it skips ideation and most operations, but it adds back functional-design — a refactor reshapes structure, so the design of the behaviour being preserved matters — and retains the deployment stages needed to ship the verified change.
security-patch: Minimal depth for responding to a CVE or vulnerability fast. It threads a narrow path: understand the code (reverse-engineering), state what the patch must do (requirements-analysis), capture the security constraint (nfr-requirements), fix and test (code-generation, build-and-test), then ship through the deployment stages so the patch actually reaches production.
poc: Minimal depth aimed at proving feasibility fast. Almost everything except the bare path to running code is skipped: capture the intent, reverse- engineer any existing code, pull the requirements, then generate and test. No design ceremony, no operations, no delivery planning.
infra: Standard depth for infrastructure changes. It is the one scope whose path leans on the back half of the graph: it skips ideation and the application-code construction stages, and instead runs practices-discovery, the NFR design pass, infrastructure-design, the CI pipeline, and the full deployment + observability set in operation.
workshop: Standard depth for a facilitated group session with mandatory gates, but with a Minimal test strategy - the `testStrategy` override that keeps the test floor light for a teaching context. It runs the inception, construction, and operation arc end to end (so participants see the whole lifecycle) while skipping the ideation discovery stages that a facilitator front-loads by hand.
enterprise: Comprehensive depth for regulated work that needs the full audit trail. Every stage in the graph executes — no shortcuts. Ideation, inception, construction, and operation all run end to end, so the artifact chain (intent through deployment and feedback) is complete and traceable.

Choosingsteps 4–6 · naming, detection, compose

real

How a scope gets picked

Three ways in. Name it, and the tool takes your word. Leave it out, and the engine reads your request for keywords, then asks you to confirm (it shows the other scopes with their stage counts). Or ask for compose and get a plan built for this request (step 5).

you, at the first prompt

You type in Claude Code · one of these

/aidlc bugfix Fix what ./docs-in/bug-report.md describes
/aidlc --scope bugfix Fix what ./docs-in/bug-report.md describes
/aidlc Fix what ./docs-in/bug-report.md describes
/aidlc compose Fix what ./docs-in/bug-report.md describes

The engine's keyword detection, run on six requests (aidlc engine scope detect --from-text --input "…", real output):

Request	Scope	How	Matched
`Fix what ./docs-in/bug-report.md describes`	bugfix	keyword	fix
`Patch CVE-2026-1234 in the jackson dependency`	security-patch	keyword	CVE
`Clean up the aging package without changing behaviour`	classic	freeform	clean up
`Refactor the aging package`	refactor	keyword	refactor
`Prove we can send email from the API`	classic	freeform	none
`Build what ./docs-in/request.md describes`	classic	freeform	none

Two surprises worth knowing. "Clean up …" matched refactor's own keyword clean up but still resolved to classic; "Refactor …" gets refactor. And a request with no keyword ("Build what … describes", "Prove we can …") falls back to classic, the V1-style 18-stage default, not express and not poc. So for anything but a fix or a CVE, name the scope. That is what the course runs do: /aidlc express … and /aidlc feature … ask no scope question at all.

In plain words. Typing the scope's name is the choice. If you don't, the tool guesses from one or two words in your request, and its guess for most requests is the middle-sized classic plan.

real

/aidlc compose on a real bug

Compose reads the request and the code, then proposes its own stage list and switches, and waits for your decision. This was run on the New Year bug in a copy of the finished Java workspace (intent 261013 complete, code at v1.1.0). It read HolidayCalendar itself and found the cause before proposing anything.

Kiran · Claude Code

You type in Claude Code

/aidlc compose Fix what ./docs-in/bug-report.md describes

You see real · 5 tool turns · 392 s

This looks like a small, well-pinned bug in one class. The holiday calendar always loads the tenant's 2026 holiday file, so on any 2027 date New Year's Day counts as a working day. A request received in October and checked on 5 Jan crosses both years, so the fix needs to load and combine every year's holiday file for the tenant, add the 2027 TX-01 list to the app's data, and add a regression test for PA-10231 checked on 2027-01-05. Because the nightly report already gives the right answer, I suggest a short run: you approve a code plan, then I build the fix, and then I run the full test suite.

A custom plan based on bugfix, 2 stages, 2 approval questions

Guard Policy: off. If an input changes after you approve something, you get one line about it rather than being asked to approve again. That suits a one-class fix with a clear expected answer. You can raise it to relaxed or strict here.

Scope settings: sensors on, learnings on, summary confirmation off, plan approval on, collaborators off, reviews advisory. The bug report already states the expected result, and one lead is enough for one class. You still approve how the years get combined before anything is built.

One trade-off: this plan doesn't write a separate requirements step. The build works from the existing rule (weekends and tenant holidays don't count), the bug report, and the code plan you approve. If you want "fixed" written down first, I can add that step back. The plan also doesn't deploy anything. It ends with a merged PR, as the last fix did.

You can ask to see why each stage is in or out, and the scores behind the sizing.

How do you want to go ahead?
- **Approve**: start the fix with this plan
- **Approve and save as scope**: same, and keep this plan for reuse
- **Edit the plan**: change stages, Guard Policy or settings
- **Reject**

Compare with the stock bugfix scope: 9 stages (Initialization, Reverse Engineering, Requirements Analysis, Code Generation, Build and Test, two deployment stages). Compose kept 2 of the 6 non-initialization ones. It also turned learnings on, which stock bugfix has off, and said plainly what it gives up: no written requirements step, no deploy.

In plain words. Compose is a planner that reads your bug before deciding how much process it needs. Here it said: this is a one-class fix with a known right answer, so plan, build, test, and stop.

real

Why each stage is in or out, with the scores

Before deciding, Kiran asked for the reasoning. Some reasons are judgment ("one unit, nothing to sequence"); others come from five scores against each stage's threshold. Nothing was approved: the proposal was left open, so no intent was created.

Kiran · Claude Code

You type in Claude Code

Before I decide: show me why each stage is in or out, and the scores behind the sizing.

#	Stage	Decision	Reason (Claude's words)
0.1	workspace-scaffold	EXECUTE	initialization - always runs
0.2	workspace-detection	EXECUTE	initialization - always runs
0.3	state-init	EXECUTE	initialization - always runs
1.1	intent-capture	skip	The bug report already captures the goal, the example and the expected result
1.2	market-research	skip	Internal reviewer screen fix; no market to research
1.3	feasibility	skip	Root cause is visible (year hard-coded in the file name); standard fix
1.4	scope-definition	skip	One defect in one class; the boundary is clear
1.5	team-formation	skip	One team, one repo
1.6	rough-mockups	skip	The screen's look does not change, only the number the API returns
1.7	approval-handoff	skip	No ideation stages run, so no handoff
2.1	reverse-engineering	skip	Three small classes; the code map from intent 261013 already exists
2.2	practices-discovery	skip	Conventions already set (Maven, scripts/verify, existing tests)
2.3	requirements-analysis	skip	Rule already in FR1.2; nightly report gives the answer; small decisions settled at plan approval
2.4	user-stories	skip	max target IAE=0.15 <= threshold 0.3 (cost 3)
2.5	refined-mockups	skip	max target IAE=0.15 <= threshold 0.3 (cost 3)
2.6	domain-design	skip	max target R=0.40 <= threshold 0.4 (cost 4)
2.7	units-generation	skip	One unit of work (one branch, one PR)
2.8	contract-design	skip	The /requests/pending API contract does not change
2.9	delivery-planning	skip	One unit, nothing to sequence
3.1	functional-design	skip	max target CSU=0.15 <= threshold 0.4 (cost 4)
3.2	nfr-requirements	skip	max target R=0.40 <= threshold 0.4 (cost 4)
3.3	nfr-design	skip	max target R=0.40 <= threshold 0.4 (cost 4)
3.4	infrastructure-design	skip	max target R=0.40 <= threshold 0.4 (cost 4)
3.5	code-generation	EXECUTE	spine - always (core implementation / verification)
3.6	build-and-test	EXECUTE	spine - always (core implementation / verification)
3.7	ci-pipeline	skip	max target VE=0.20 <= threshold 0.3 (cost 3)
4.1	deployment-pipeline	skip	No deployment setup in the repo; ships as a merged PR (turn on if this workflow must deploy)
4.2	environment-provisioning	skip	max target R=0.40 <= threshold 0.5 (cost 5)
4.3	deployment-execution	skip	Shipping is the normal PR merge (turn on with deployment-pipeline if needed)
4.4	observability-setup	skip	max target VE=0.20 <= threshold 0.5 (cost 5)
4.5	incident-response	skip	no cost prior in the shipped table - not numerically screenable; human judgment at the gate
4.6	performance-validation	skip	max target R=0.40 <= threshold 0.5 (cost 5)
4.7	feedback-optimization	skip	no cost prior in the shipped table - not numerically screenable; human judgment at the gate

Score	Symbol	Value	Band
Intent Ambiguity	IAE	0.15	LOW
Codebase Structural Uncertainty	CSU	0.15	LOW
Verification Entropy	VE	0.20	LOW
Risk / Blast Radius	R	0.40	MED
Unresolved Assumptions	UA	0.25	LOW
Composite ARS (advisory)	-	21 / 100	Focused

Compared with the stock bugfix plan, this one drops reverse-engineering, requirements-analysis, deployment-pipeline and deployment-execution. Code generation will warn that this plan produces no requirements document and no unit-of-work document. Stock bugfix doesn't produce the unit-of-work document either. Turning requirements-analysis back on closes the requirements gap. Its four choices: Approve, Approve and save as scope (keeps the plan as a new file in .claude/scopes/ for reuse), Edit the plan, Reject.

Notice 2.1. Compose skipped Reverse Engineering because "the code map from intent 261013 already exists": the first intent's codekb is reused. The stock bugfix run on the same bug kept 2.1 and asked whether to rescan, because the codekb was minted at v1.0.2 and the code is now v1.1.0. Both are defensible; compose trades a stale map for speed.

Steeringsteps 7–8 · changing a run once it has started

documented

Switches you can flip during a run

A scope is only the starting plan. These change one intent without touching the scope file; the next intent starts from the scope's defaults again. Plain words work too: the conductor maps them to the same commands.

you, at any prompt

Say or type	Effect
`/aidlc --learnings on`	Ask "Anything to add for next time?" after each stage, for this intent
`/aidlc --summary-confirmation on`	Restate your answers before writing each artifact
`/aidlc --collaborators on`	Bring each stage's support agents in (the mob: architect, quality, devsecops…)
`/aidlc --sensors on` / `off`	Automatic checks on file writes
`/aidlc --depth comprehensive`	Longer artifacts (minimal, standard, comprehensive)
`/aidlc --review …`, `--guard-policy strict`	How hard the reviewer and the change guards are
"skip market research" or `--skip market-research`	Changes the plan at once and names the undo; `--add <slug>` puts a stage back
"what else can we cut?"	Goes through compose again: a new proposal you approve
"build one unit at a time"	Construction setter: unit-major or stage-major, checkpoints on/off, serial or swarm

Where this comes from. The flags are listed in the /aidlc skill's own help (.claude/skills/aidlc/SKILL.md) and in each scope file ("Turn either back on per intent with /aidlc --learnings on…"). The feature run on this course used several: its learnings questions, summary confirmations and reviewer findings are all switches, not stages.

In plain words. Pick the smallest scope that fits, then turn on what you miss. It is easier than picking a big one and arguing with every question.

real

Models, new projects, and one stage on its own

Three more things people ask about. Which model does each agent use? What if the folder is a new project, not existing code? Can I run one stage without the whole workflow?

you, in the terminal or Claude Code

You type terminal · read-only

aidlc config models --show

You see real · 2.11.0

Model policy for claude

Preset: none (shipped defaults)

All 14 agents inherit your session model and effort, except:
  Reviewing (2 agents): sonnet / medium
    Review-only agents use the measured medium baseline; raising effort trades review time and cost for deeper correctness checking.

Recorded in: nothing yet - run 'aidlc config models --preset balanced --project --yes'
Full per-agent list: aidlc config models --show --json

ModelsBy default every agent uses your Claude Code session's model and effort, except the two reviewer agents (sonnet, medium). Presets thorough, balanced, minimal record a policy for the project: aidlc config models --preset balanced --project --yes.

New project or existing codeWorkspace Detection (0.2) decides from the folder. Say it in your own words to override: "treat it as a new project" or "this is existing code". The engine records it, never asks again, and for existing code runs Reverse Engineering first. The course's workspaces are all existing code; poc is the scope that starts lightest on a new one.

One stage on its own/aidlc --stage approval-handoff --single runs one stage and its gate without advancing the main workflow; the engine records it with its own ids. The packaged skills /aidlc-approval-handoff, /aidlc-reverse-engineering and the others in .claude/skills/ are shortcuts for exactly this.

Not covered by a run here: a greenfield start and a --single stage were not executed for this page; the text follows the 2.11 skill files. The config models output is real.

What is real here

Real, AI-DLC 2.11.0, 17 Oct 2026: the stage table, every scope's stage list and the counts (aidlc engine gen stage-table, gen scope-table, graph scope), the scope files' settings, the keyword detection results, aidlc config models --show, and both /aidlc compose replies (a headless Claude Code session on a copy of the finished Java workspace; the proposal was left unanswered, so no intent was created). The files are in aidlc-hello-world-java/scopes-data/. Documented, not run: the switches in step 7 and the greenfield and single-stage notes in step 8.

Sources: AI-DLC docs on scopes, depth and test strategy; the 2.11 harness files in .claude/scopes/ and .claude/skills/aidlc/.