End-to-End Example
This walkthrough shows the full SDLC pipeline applied to a single, simple project: building a daily standup log — a static page where a developer records what they did yesterday, what they're doing today, and any blockers.
The Idea
ConversationThe developer describes what they want:
"I want a simple static page where I can log daily standups. Three fields: yesterday, today, blockers. Entries are stored in a JSON file. No backend — just a local HTML file I open in my browser. I want to see the last 7 days of entries."
This conversation is the raw input. It's informal, incomplete, and that's fine — the pipeline's job is to add structure.
Requirements
/sdlc draft-userThe pipeline extracts structured requirements from the conversation:
US-001: As a developer, I can enter yesterday's work, today's plan, and current blockers into a form and save the entry.
US-002: As a developer, I can view the last 7 days of standup entries in reverse chronological order.
US-003: As a developer, I can edit or delete a previous entry.
NFR-001: No server required. All data stored in browser localStorage.
NFR-002: Page loads in under 1 second on any modern browser.
Notice US-003 — edit/delete wasn't in the original conversation. The gap analysis surfaced it as a likely need and flagged it for review.
Design
/sdlc gen-pdrThe PDR makes concrete technology and architecture decisions:
Stack: Single HTML file, vanilla JS, no build step. CSS in <style> tag.
Data model: localStorage key standup-entries, value is JSON array of { date, yesterday, today, blockers } objects.
Components: Entry form (3 textareas + submit), entry list (card per day), delete confirmation modal.
Constraints: No external dependencies. No CDN. Single file, copy-pasteable.
The PDR made the "single HTML file" decision based on the "no server" NFR and the simplicity of the project. This is documented and traceable — not an implicit assumption.
Plan
/sdlc gen-plan + /sdlc finalizeThe plan breaks the design into ordered, independently shippable phases:
| Phase | Goal | Tasks |
|---|---|---|
| 00 | HTML shell + localStorage read/write | 3 |
| 01 | Entry form + save to storage | 4 |
| 02 | Entry list + 7-day display | 3 |
| 03 | Edit/delete + confirmation | 4 |
Phase 00 proves the storage mechanism works before building UI. If localStorage has a quirk, you find out in a 3-task phase, not after building the whole app.
Phase Plans
/sdlc expandEach phase gets a detailed execution plan with context the implementor needs:
Phase 01, Task 01.2: Create entry form with three <textarea> elements (yesterday, today, blockers) and a submit button. On submit, read values, create entry object with date: new Date().toISOString().slice(0,10), append to array in localStorage, clear form.
Pattern: JSON.parse(localStorage.getItem('standup-entries') || '[]')
Verification: Fill form, submit, check localStorage in DevTools, refresh page, verify data persists.
The phase plan includes the exact code pattern, the verification method, and the specific localStorage key. The implementor doesn't need to make any design decisions.
Implementation
/sdlc implementThe agent executes each phase, updating task status with timestamps as it works:
| Task | Status | Started | Completed |
|---|---|---|---|
| 01.1 | Completed | 2:30 PM | 2:32 PM |
| 01.2 | Completed | 2:32 PM | 2:38 PM |
| 01.3 | Completed | 2:38 PM | 2:41 PM |
| 01.4 | Completed | 2:41 PM | 2:43 PM |
One commit per phase. Each phase is verified working before moving on. The timestamps create an audit trail showing where time was actually spent.
From rough idea to 4-phase implementation in minutes. The pipeline didn't just generate code — it generated requirements, design decisions, a phased plan, and an audit trail. Every decision is documented. Every output is verifiable.
Ready to try it? Get started or explore the full workflow.