The SDLC pipeline

Proposal

The client-facing proposal drawn from the approved documents.

The Proposal step writes the client-facing technical proposal from the approved documents: what the client needs, the solution, how it will be built and delivered, the team, the compliance picture and why you are the right choice. It is the last reviewed document in the pipeline, and it deliberately carries no price — effort and cost are agreed separately.

What you get

A Markdown document titled Technical Proposal, with the bridge's title block on top and a Version History table at the end. The agent writes these sections, in order:

Section	Contents
1. Executive Summary	The client's need, the proposed solution and the outcome.
2. Understanding of the Requirement	Objectives, regulatory context, key success criteria.
3. Proposed Solution	The overview, the key features (citing the requirement ids they deliver), and the win themes.
4. Technical Approach	Architecture with a Mermaid flowchart built from the design components (citing their ids), technology stack, methodology, quality assurance, integrations.
5. Delivery Plan	Phases and milestones — a Gantt chart when the input carries dates, otherwise the phases in order.
6. Team	A table of name, role, years of experience and relevant projects.
7. Compliance	The frameworks from the project's compliance flags, with status and gaps.
8. Assumptions and Constraints	Bullets.
9. Why Us	Win themes and differentiators grounded in the requirements.

The bridge requires the headings Executive Summary, Understanding, Proposed Solution, Technical Approach, Delivery, Team, Assumptions and Why, and at least one Mermaid diagram.

Before you run it

The STS must be approved. Until it is, /proposal is locked with "Approve /sts to unlock this".
The Scope, SRS and SDS must all exist. The gate checks them in pipeline order and names the first one missing; the run itself stops with "Cannot generate proposal: … artifact is missing from state.json" if one is gone.

Running Compliance first is optional but worth it: the proposal's Compliance section names only the frameworks found in the project's compliance flags.

How it works

Proposal makes one skill call, sdlc-proposal-writer, with up to three attempts.

Drawing diagram…

The message carries the project and client names, every requirement, every design component, the compliance flags, the team profiles, the paths of the scope, SRS and SDS documents, and any notes. It also carries an estimate block with every figure set to zero and a note that the proposal carries no estimate.

The skill's rules:

No estimate. No effort figure, hours, rates, prices, currency amounts, payment schedule or cost section anywhere.
Win themes come from the top three "must" requirements, in the form "By [capability], we enable [client outcome], as demonstrated by [requirement reference]" — benefits, not features.
Compliance names only frameworks present in the input.
Team uses the project's team profiles verbatim when there are any; otherwise it uses role-based rows and never invents named people. The pipeline does not currently collect team profiles, so expect role-based rows.

Banned phrases

Besides the heading and diagram checks, every draft is scanned for placeholder language. Any of these, as a whole word and in any case, fails the draft:

TBD · N/A · to be determined · not available · placeholder · insert here · coming soon

Where the input lacks something, the skill states specifically what the client must supply instead. The match is whole-word, so "n/a" inside a URL path does not count.

Each retry hears every rejection so far, oldest first, so the writer cannot fix the latest problem while re-breaking an earlier one.

The run panel shows: Checking project state, Writing the proposal, Writing the Markdown document. The completion message reads "Proposal vN written with every required section and zero banned phrases — ready for review."

Ids this step owns

None. The proposal cites requirement ids (REQ-…) in its features and win themes, and design component ids (DC-NNN) in its architecture.

Reviewing it

This is the document your client reads, so review it as they would:

the executive summary and win themes should describe outcomes the client cares about, tied to real "must" requirements;
the architecture diagram should match the approved SDS;
the Team section: replace the role-based rows with your real people before you send it, or request changes naming them;
the Delivery Plan should use only dates that exist in the scope;
confirm there is no price anywhere — pricing belongs in a separate commercial document.

Request changes runs the writer again with your change list as notes; it does not see the previous draft, and the banned-phrase and heading checks apply again. Be concrete: "In Team, add our Solution Architect with 12 years of experience in core banking" or "Drop the mobile channel from the Proposed Solution".

You can export the proposal to Word or PDF from the document panel's Download menu. See Read and export documents.

When it fails

What you see	Why	What to do
`/proposal` locked: "Approve /sts to unlock this"	The STS is not approved.	Approve the STS.
"Cannot generate proposal: … artifact is missing from state.json. Run /… first."	The scope, SRS or SDS is missing.	Run the step it names.
"The proposal did not pass its checks."	Three drafts in a row missed a heading or the diagram, or used a banned phrase.	Run it again. If a banned phrase keeps appearing, add the missing fact through notes on a Request changes run, or fill it in upstream.

Under the hood

The driver is bridge/src/services/proposalPipeline.service.ts; the banned-phrase list is BANNED_PHRASES there.
The document is .sdlc/artifacts/proposal-vN.md, registered as artifacts.proposal. The phase moves to proposal.
The draft is kept in .sdlc/tmp/proposal-data.json while under review; approval deletes it and stores the approved file.