Scope

The Scope step reads the approved RFP and pins down what the project is: its objectives, what is in and out of scope, who the stakeholders are, the assumptions, constraints and risks, and what gets delivered. It produces two things at once — structured scope data that the SRS step reads, and the Project Scope document a client reads.

What you get

A Markdown document titled Project Scope, with the bridge's title block (project, client, version, date) on top and a Version History table at the end. In between is the agent's document, with these sections in order:

• Project Overview
• Objectives
• In Scope — every in-scope item with its id (SCOPE-001 …), title and description
• Out of Scope
• Stakeholders — a table of name, role, organization and contact type
• Assumptions
• Constraints — a table of type and description
• Risks — a table citing every risk id (RISK-001 …) with description, likelihood, impact and mitigation
• Deliverables
• Technical Context — tech stack, delivery model, integrations and the non-functional baseline, when the RFP gave them
• At least one Mermaid diagram: a system context flowchart of the users and channels, the system, and every integration

The bridge requires these headings: Overview, Objectives, In Scope, Out of Scope, Stakeholders, Assumptions, Constraints, Risks and Deliverables, plus at least one Mermaid diagram.

Before you run it

• The RFP must be approved. The gate requires the RFP to exist and its approval to match its current content. An uploaded RFP is approved on upload; an agent-drafted one needs Approve. Until then the /scope button is locked with "Approve /rfp to unlock this".
• There must be RFP text to read. The step uses the RFP's extracted text; if there is none it falls back to the project description. With neither, the run stops with "No RFP or brief content to extract scope from — upload a document or provide scope text."

How it works

Scope makes one skill call, sdlc-scope-analyst, with up to three attempts. Two checks run on every reply, and both must pass.

Drawing diagram…

The message gives the agent the project name, the client name, the full RFP text, and any notes (your change list, on a Request changes run). The skill returns one JSON object containing:

• the scope data: projectOverview, objectives, inScope, outOfScope, stakeholders, assumptions, constraints, risks, complianceFlags, deliverables, and — only when the RFP states them — techStack, deliveryModel, integrations and nfBaseline;
• the scope document, as Markdown.

The two checks:

1. The data is validated against the scope schema. It rejects unknown keys and requires at least one objective, in-scope item, stakeholder, constraint, risk and deliverable. Constraint types must be timeline, budget, technical or regulatory; risk likelihood and impact must be high, medium or low; any timeline dates must be YYYY-MM-DD.
2. The document must have the required headings and at least one diagram, and must cite every in-scope item id and every risk id from the data. A document that forgets RISK-003 is sent back.

All problems from one attempt go back together, so a single retry can fix them all. The skill derives the tech stack, delivery model, integrations and non-functional figures only from the RFP — it never asks and never invents a figure — and records ambiguity in the overview, assumptions or risks instead of adding fields.

The run panel shows: Checking project state, Extracting scope from inputs, Validating against schema, Persisting to project state, Writing the Markdown document.

Ids this step owns

Every one of these ids must appear in the document. Scope does not create requirement ids — those belong to the SRS.

Reviewing it

The SRS is decomposed from this scope, so anything wrong here spreads. Check that:

• the In Scope list covers every capability in the RFP, and Out of Scope captures what was deferred or excluded;
• the constraints and risks are real ones from the RFP, not generic filler;
• the Technical Context reflects technology the RFP actually mandates;
• the context diagram shows every integration.

When you Request changes, your change list is passed to the agent as additional notes, alongside the RFP, and the scope is extracted again. The agent does not receive the previous draft, so be specific — "Move the reporting dashboard to Out of Scope" works better than "the dashboard is wrong" — and re-read the whole document when it comes back. The new draft keeps the same version number.

When it fails

Under the hood

• The driver is bridge/src/services/scopePipeline.service.ts. It creates .sdlc/state.json if the project has none yet.
• The scope data is saved into the state as scopeOverview, scopeObjectives, scopeInScope, scopeOutOfScope, scopeDeliverables, scopeStakeholders, scopeTimeline, scopeRisks, scopeConstraints and scopeAssumptions, plus techStack, deliveryModel, integrations and nfBaseline. The SRS step reads these.
• The document is .sdlc/artifacts/scope-vN.md, registered as artifacts.scope with its hash and version history. The project phase moves from discovery to requirements.
• The validated scope data is kept in .sdlc/tmp_scope_data.json while the draft is under review; approval deletes it.