The SDLC Pipeline
Eight structured prompts form a linear pipeline. Each reads prior-stage artifacts and produces the next stage. The pipeline enforces gap surfacing, traceability, and phased execution — turning a software idea into working code through documented stages.
Pipeline Commands
Each command has a defined input/output contract. Conversation-path commands format discussion into documents. Document-path commands generate decisions from prior-stage documents.
Format a conversation into structured user requirements
- Input
- Conversation about the product idea, goals, and requirements
- Output
- sdlc/docs/draft.user.md — draft user requirements document
The draft-user command takes an ongoing conversation about a product idea and extracts user requirements into a structured document. It identifies user stories, functional requirements, acceptance criteria, and constraints from the natural-language discussion.
It extracts and structures what was said — it does not invent requirements. User requirements always start from conversation; there is no gen-user because requirements must come from a human.
Format a conversation into a structured Product Design Review
- Input
- Conversation about architecture, components, data models, and implementation approach, plus the user requirements document
- Output
- sdlc/docs/draft.pdr.md — draft Product Design Review
The draft-pdr command takes a conversation where architecture and design decisions have been discussed and formats it into a structured Product Design Review. It extracts component interfaces, data models, dependency choices, and platform decisions from the discussion.
Like draft-user, it extracts rather than invents. The alternative document path is gen-pdr, which generates a PDR directly from the user requirements document without requiring conversation input.
Format a conversation into a structured phased release plan
- Input
- Conversation about phasing, priorities, and milestones, plus user requirements and PDR documents
- Output
- sdlc/docs/draft.plan.md — draft phased release plan
The draft-plan command takes a conversation where planning decisions have been discussed — phase boundaries, risk ordering, priorities, milestones — and formats it into a structured phased release plan with task tables.
The alternative document path is gen-plan, which generates a plan directly from the PDR document without requiring conversation input.
Generate a Product Design Review from user requirements documents
- Input
- sdlc/docs/final.user.md or sdlc/docs/draft.user.md — the user requirements document
- Output
- sdlc/docs/draft.pdr.md — draft Product Design Review
The gen-pdr command reads a user requirements document and designs the physical system that satisfies it. It makes design decisions — choosing components, defining data models, identifying risks — based on what the requirements ask for and what good engineering practice demands.
This is the fast-path alternative to draft-pdr. Instead of formatting conversation content, it generates design decisions directly from the requirements document.
Generate a phased release plan from a Product Design Review
- Input
- sdlc/docs/final.pdr.md or sdlc/docs/draft.pdr.md — the PDR document, plus user requirements for context
- Output
- sdlc/docs/draft.plan.md — draft phased release plan
The gen-plan command reads a Product Design Review and decomposes it into a risk-ordered phased release plan. It makes planning decisions — choosing phase boundaries, ordering by risk and dependency, defining per-phase scope — based on the design and what good engineering sequencing demands.
This is the fast-path alternative to draft-plan. It generates planning decisions directly from the PDR document without requiring conversation.
Convert three draft documents into three finalized documents with gap analysis
- Input
- sdlc/docs/draft.user.md, sdlc/docs/draft.pdr.md, sdlc/docs/draft.plan.md
- Output
- sdlc/docs/final.user.md, sdlc/docs/final.pdr.md, sdlc/docs/final.plan.md
The finalize command processes all three draft documents in strict sequence: user requirements, then PDR, then plan. Each finalized document feeds into the next — the final user requirements inform the final PDR, which informs the final plan.
It fills gaps the draft author missed without rewriting their vision. It performs gap analysis, adds traceability IDs (US-NNN, NFR-NNN), and flags any critical issues found. The result is three buildable, internally consistent documents.
Generate self-contained phase execution plans from finalized documents
- Input
- sdlc/docs/final.plan.md, sdlc/docs/final.pdr.md, sdlc/docs/final.user.md
- Output
- sdlc/plan/phase{NN}/plan.md — one file per phase
The expand command reads the finalized plan, PDR, and user requirements, then produces one standalone plan file per phase. Each phase plan contains everything an implementer needs — task tables, relevant schema, import paths, design notes, and verification criteria — without re-reading the full PDR.
This is the bridge between finalized documentation and implementation. It runs once after finalize and before implement.
Execute phase plans — write code, update task status, verify, and commit
- Input
- sdlc/docs/final.plan.md and sdlc/plan/phase{NN}/plan.md for the target phase
- Output
- Working code, updated task tables with timestamps, one commit per phase
The implement command is the execution engine. It reads the plan state, finds the next incomplete phase, and works through each task: marking it started, doing the implementation work, running verification, and marking it complete with PST timestamps.
It updates both the master plan and the per-phase plan as it goes, writes a phase summary, and commits. It can run in single-phase mode (default) or autonomous mode (all remaining phases end-to-end).
Workflow Paths
There are three ways to move through the pipeline. All paths start with conversation-driven user requirements and end with the same finalize/expand/implement sequence.
Three Workflow Paths
Conversation path
draft-user → draft-pdr → draft-plan → finalize → expand → implement
Have a conversation about each stage, then format it into a document. The most thorough path — every decision is discussed before being captured.
Fast path
draft-user → gen-pdr → gen-plan → finalize → expand → implement
Conversation for user requirements only. The PDR and plan are generated directly from documents — faster, but the AI makes more design decisions autonomously.
Mixed path
draft-user → draft or gen → draft or gen → finalize → expand → implement
Any combination — conversation for requirements, generated PDR, conversation for plan, or vice versa. Use conversation for decisions you want to control and generation for the rest.
What Each Stage Produces
Finalize
The finalize command converts three draft documents into three final documents, processed in strict sequence: user requirements first, then PDR, then plan. Each final feeds into the next. It performs gap analysis, adds traceability IDs (US-NNN, NFR-NNN), and flags critical issues — making the documents buildable without rewriting the original vision.
Expand
The expand command generates standalone phase execution plans at sdlc/plan/phase{NN}/plan.md. Each phase plan is self-contained: it includes the task table, relevant schema, import paths, design notes, and verification criteria. An implementer can execute a phase without re-reading the full PDR.
Implement
The implement command is the execution engine. It reads plan state, finds the next incomplete phase, and works through each task: marking it started, writing code, running verification, and marking it complete with PST timestamps. It updates both the master plan and per-phase plan, writes a phase summary, and commits. It runs in single-phase mode by default, or autonomous mode for end-to-end execution.