RFP

The RFP is the pipeline's entry point: the Request for Proposal every later document is built from. You either upload one you already have, or talk the idea through with the project's agent and let it draft one from the conversation. Either way, /scope stays locked until the project has an approved RFP.

Two ways to get an RFP

An upload is you vouching for the document, which is why it needs no review. The bridge extracts its text when you upload it, and rejects a file it cannot read (RFP_UNREADABLE) rather than letting later steps work from nothing.

Drafting from the chat

Describe the idea in SDLC Studio: who the system is for, what it must do, any deadline or budget. The agent — using its project-assistant skill — asks follow-up questions and summarises. When it judges the conversation holds enough, a banner appears: "The agent has enough to draft your RFP. It comes back for your review before /scope unlocks.", with a Generate RFP button. You can also type /rfp in the composer at any time while the step is available. See Talk to the agent.

What you get

A Markdown document titled Request for Proposal. The bridge puts the title block on top: a table with the project, client, version and date. Below it is the agent's RFP, which opens with a short title for the solution being requested and then these sections, in order:

• Executive Summary
• Background
• Objectives
• Users and Stakeholders
• Scope, with In Scope and Out of Scope lists
• Functional Requirements — one "The system shall …" statement per bullet
• Non-Functional Requirements
• Integrations
• Constraints and Assumptions
• Deliverables
• Timeline and Budget
• Evaluation Criteria
• Open Questions

The agent may add one Mermaid diagram where it helps, such as a flowchart of the users, the system and its integrations.

The bridge requires nine of these headings before it accepts the draft: Summary, Background, Objectives, Scope, Functional Requirements, Non-Functional Requirements, Deliverables, Evaluation Criteria and Open Questions. Headings match without regard to case and as part of a longer heading, so "Executive Summary" satisfies "Summary".

Before you run it

• The project needs a name. Every project has one, so in practice this always holds.
• There must be something to draft from: at least one message from you in the project chat, or a project description. Otherwise the run stops with "There is nothing to draft an RFP from yet — describe the idea in the project chat first, or upload an RFP."
• The project's agent must be bound and available. See Set up the project agent.

The RFP step has no prerequisites in the gate table — it is always available until an RFP exists.

How it works

The run makes one skill call, sdlc-rfp-writer, with up to three attempts.

Drawing diagram…

The message carries the project name, the client name, the project type and timeline when they are set, the project description, and the conversation — up to the 60 most recent completed chat messages, oldest first. The skill treats your messages as the source of truth; it uses a fact from the agent's own replies only when you confirmed it.

The skill's rules keep the draft honest: it never invents facts, figures, names, dates or systems the conversation does not contain, puts unknowns under Open Questions, never writes "TBD", and writes for a vendor who has never seen the chat. If the input has no usable project information at all, the agent declines instead of guessing.

The run panel shows these stages:

Ids this step owns

None. The RFP is free text; ids start with the Scope step.

Reviewing it

Read the draft in the document panel beside the chat. Check that:

• every feature you described appears as a Functional Requirement, and nothing appears that you never asked for;
• the Non-Functional Requirements carry only figures you actually gave;
• Open Questions lists the gaps that matter — the scope analyst reads this RFP next, and anything missing here is missing everywhere after it.

Request changes works differently for the RFP than for later steps: the agent receives the draft under review plus your change list, applies every change, and keeps everything else as it was. Write one change per line, for example "Add a Timeline and Budget note that launch is planned for March" or "Remove the SMS integration".

You can also replace an agent draft that is awaiting review with a file of your own: Replace RFP takes the place of Upload RFP while a draft is under review. The uploaded file becomes the approved RFP.

When it fails

Under the hood

• The driver is bridge/src/services/rfpPipeline.service.ts; uploads go through POST /api/projects/:id/rfp and bridge/src/lib/rfpRecord.ts.
• A drafted RFP is written to .sdlc/artifacts/rfp-vN.md; an uploaded one keeps its extension (rfp-vN.pdf, rfp-vN.docx …) and is also stored as projects/<id>/rfp/rfp-vN.<ext>.
• state.json gets artifacts.rfp (path, version, hash, version history). An upload also gets approvals.rfp, with you as the approver.
• The RFP's text is saved on the project inputs as rfpText, with rfpSource (agent or upload) and rfpStatus (draft or approved). /scope reads that text.
• The draft under review is kept in .sdlc/tmp/rfp-data.json so Request changes can edit it; approval deletes it.