# Sdd Yolo > SDD fast path. Runs the full pipeline — analyse → plan → implement → review → archive — with a single confirmation gate before implementation begins. Stops automatically if Critical or Major issues are found in review. Use when you want to ship a well-understood feature with minimal interruptions. - Skill: `sivaprasadreddy/sdd-yolo` (Agent Skill) - Install (CLI): `npx skillmds@latest add sivaprasadreddy/sdd-yolo` - Raw SKILL.md: https://api.skillmd.com/api/skills/sivaprasadreddy/sdd-yolo/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: DevOps & Infra - Author: sivaprasadreddy (https://skillmd.com/u/sivaprasadreddy) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/sivaprasadreddy/sdd-yolo --- # SDD: YOLO Full Pipeline You are running the full SDD workflow end-to-end with minimal interruptions. The pipeline is: **analyse → plan → implement → review → archive**. There is exactly **one confirmation gate**: after the spec and plan are produced, before implementation begins. Everything else runs automatically. ## Required Inputs Before starting, collect these inputs. If any are missing, ask for them now — do not proceed without them. | Input | Description | Example | |-----------------------|---------------------------------|-----------------------------------------------------| | `feature_description` | The feature to build end-to-end | "Add JWT authentication with refresh token support" | ## Steps ### Step 0: Validate Inputs (ALWAYS DO THIS FIRST) Check the conversation for `feature_description` and for `docs/project.md`. - If `docs/project.md` does not exist → stop and tell the user to run `/sdd-init` first. - If `feature_description` is present → proceed to Phase 1. - If `feature_description` is missing → ask: "What feature would you like to build?" Do NOT proceed until the user provides it. --- ## Phase 1 — Analyse Follow the full `sdd-feature` process: 1. Read `docs/project.md`. 2. Analyse the request: **`feature_description`** (collected in Step 0). 3. Ask clarifying questions **only for blockers** — information without which you cannot write a correct spec. Skip questions about preferences or nice-to-haves. Maximum 3 questions. 4. Write `feature.md` in the project root using the standard structure: ```markdown # Feature: ## Summary ## User Stories ## Functional Requirements ## Acceptance Criteria - [ ] AC-01: ... ## Technical Scope ## Non-Functional Requirements ## Out of Scope ## Open Questions ``` 5. Print a compact summary of the spec (3–5 bullet points, not the full file). --- ## Phase 2 — Plan Follow the full `sdd-plan` process immediately after Phase 1: 1. Read `feature.md` and `docs/project.md`. 2. Write `plan.md` in the project root with ordered implementation steps, specific file paths, checklist items, and an AC-to-test mapping table. 3. Print a compact summary of the plan (step names only, not full detail). --- ## Confirmation Gate Present the following prompt and **wait for the user's response** before continuing: ``` ## Ready to implement Spec: feature.md ✓ Plan: plan.md ✓ [Compact spec summary — 3–5 bullets] [Plan steps — numbered list of step names] Type PROCEED to start implementation, or describe any changes you want first. ``` - If the user types **PROCEED** (or equivalent confirmation): continue to Phase 3. - If the user requests changes: apply them to `feature.md` and/or `plan.md`, show what changed, then re-present the gate. - If the user aborts: stop and leave `feature.md` and `plan.md` in place for manual continuation. --- ## Phase 3 — Implement Follow the full `sdd-implement` process: 1. Read `plan.md`, `feature.md`, and `docs/project.md`. 2. Execute each step in `plan.md` in order. 3. Compile and run tests after each layer. Fix failures before moving on — never carry failures forward. 4. Do not introduce new dependencies without flagging them to the user. 5. After all steps, run the full test suite and verify every AC against a passing test. 6. Print the completion summary (files created/modified, AC pass/fail table). If any AC is failing after implementation, **stop here**. Report what failed and ask the user to fix it before continuing. --- ## Phase 4 — Review Follow the full `sdd-review` process immediately after Phase 3: 1. Run `git diff main...HEAD --name-only` to determine changed files. 2. Review across all 8 dimensions (AC coverage, language best practices, framework conventions, security, duplication, design, performance, test quality, observability). 3. Produce the full structured review report. --- ## Phase 5 — Archive or Stop Evaluate the review verdict: ### If verdict is ✅ Ready to merge OR 🟡 Merge after minor fixes Proceed automatically to archive: 1. Follow the full `sdd-archive` process. 2. Update `docs/project.md` (features list, architecture decisions, API surface, env config). 3. Show the proposed `project.md` changes and ask for confirmation before writing. 4. Move `feature.md` and `plan.md` to `docs/specs-archive//`. 5. Create `docs/specs-archive//README.md`. Then print the final pipeline summary: ``` ## YOLO Pipeline Complete ✓ Feature: Archived to: docs/specs-archive// Phase results: Analyse ✓ Plan ✓ Implement ✓ (N files created, M files modified) Review ✓ () Archive ✓ Next: commit docs/specs-archive// and docs/project.md to version control. ``` ### If verdict is 🟠 Requires fixes and re-review OR 🔴 Do not merge **Stop. Do not archive.** Print: ``` ## YOLO Pipeline Stopped — Review issues require attention Feature: Phase results: Analyse ✓ Plan ✓ Implement ✓ Review ✗ () Archive — (skipped) Critical/Major findings must be resolved before archiving. Fix the issues above, then run /sdd-review to re-review, and /sdd-archive when clean. ``` Leave `feature.md` and `plan.md` in the project root so the user can continue manually.