11 KiB
Greenfield Workflow
Workflow for new projects built from scratch. Flows linearly: Problem → Research → Plan → UI Design (if applicable) → Decompose → Implement → Run Tests → Security Audit (optional) → Performance Test (optional) → Deploy → Retrospective.
Step Reference Table
| Step | Name | Sub-Skill | Internal SubSteps |
|---|---|---|---|
| 1 | Problem | problem/SKILL.md | Phase 1–4 |
| 2 | Research | research/SKILL.md | Mode A: Phase 1–4 · Mode B: Step 0–8 |
| 3 | Plan | plan/SKILL.md | Step 1–6 + Final |
| 4 | UI Design | ui-design/SKILL.md | Phase 0–8 (conditional — UI projects only) |
| 5 | Decompose | decompose/SKILL.md | Step 1–4 |
| 6 | Implement | implement/SKILL.md | (batch-driven, no fixed sub-steps) |
| 7 | Run Tests | test-run/SKILL.md | Steps 1–4 |
| 8 | Security Audit | security/SKILL.md | Phase 1–5 (optional) |
| 9 | Performance Test | test-run/SKILL.md (perf mode) | Steps 1–5 (optional) |
| 10 | Deploy | deploy/SKILL.md | Step 1–7 |
| 11 | Retrospective | retrospective/SKILL.md (cycle-end mode) | Steps 1–4 |
Detection Rules
Resolution: when a state file exists, state.step + state.status drive detection and the conditions below are not consulted. When no state file exists (cold start), walk the rules in order — first folder-probe match wins. Steps without a folder probe are state-driven only; they can only be reached by auto-chain from a prior step.
Step 1 — Problem Gathering
Condition: _docs/00_problem/ does not exist, OR any of these are missing/empty:
problem.mdrestrictions.mdacceptance_criteria.mdinput_data/(must contain at least one file)
Action: Read and execute .cursor/skills/problem/SKILL.md
Step 2 — Research (Initial)
Condition: _docs/00_problem/ is complete AND _docs/01_solution/ has no solution_draft*.md files
Action: Read and execute .cursor/skills/research/SKILL.md (will auto-detect Mode A)
Research Decision (inline gate between Step 2 and Step 3)
Condition: _docs/01_solution/ contains solution_draft*.md files AND _docs/01_solution/solution.md does not exist AND _docs/02_document/architecture.md does not exist
Action: Present the current research state to the user:
- How many solution drafts exist
- Whether tech_stack.md and security_analysis.md exist
- One-line summary from the latest draft
Then present using the Choose format:
══════════════════════════════════════
DECISION REQUIRED: Research complete — next action?
══════════════════════════════════════
A) Run another research round (Mode B assessment)
B) Proceed to planning with current draft
══════════════════════════════════════
Recommendation: [A or B] — [reason based on draft quality]
══════════════════════════════════════
- If user picks A → Read and execute
.cursor/skills/research/SKILL.md(will auto-detect Mode B) - If user picks B → auto-chain to Step 3 (Plan)
Step 3 — Plan
Condition: _docs/01_solution/ has solution_draft*.md files AND _docs/02_document/architecture.md does not exist
Action:
- The plan skill's Prereq 2 will rename the latest draft to
solution.md— this is handled by the plan skill itself - Read and execute
.cursor/skills/plan/SKILL.md
If _docs/02_document/ exists but is incomplete (has some artifacts but no FINAL_report.md), the plan skill's built-in resumability handles it.
Step 4 — UI Design (conditional)
Condition (folder fallback): _docs/02_document/architecture.md exists AND _docs/02_tasks/todo/ does not exist or has no task files.
State-driven: reached by auto-chain from Step 3.
Action: Read and execute .cursor/skills/ui-design/SKILL.md. The skill runs its own Applicability Check, which handles UI project detection and the user's A/B choice. It returns one of:
outcome: completed→ mark Step 4 ascompleted, auto-chain to Step 5 (Decompose).outcome: skipped, reason: not-a-ui-project→ mark Step 4 asskipped, auto-chain to Step 5.outcome: skipped, reason: user-declined→ mark Step 4 asskipped, auto-chain to Step 5.
The autodev no longer inlines UI detection heuristics — they live in ui-design/SKILL.md under "Applicability Check".
Step 5 — Decompose
Condition: _docs/02_document/ contains architecture.md AND _docs/02_document/components/ has at least one component AND _docs/02_tasks/todo/ does not exist or has no task files
Action: Read and execute .cursor/skills/decompose/SKILL.md
If _docs/02_tasks/ subfolders have some task files already, the decompose skill's resumability handles it.
Step 6 — Implement
Condition: _docs/02_tasks/todo/ contains task files AND _dependencies_table.md exists AND _docs/03_implementation/ does not contain any implementation_report_*.md file
Action: Read and execute .cursor/skills/implement/SKILL.md
If _docs/03_implementation/ has batch reports, the implement skill detects completed tasks and continues. The FINAL report filename is context-dependent — see implement skill documentation for naming convention.
Step 7 — Run Tests
Condition (folder fallback): _docs/03_implementation/ contains an implementation_report_*.md file.
State-driven: reached by auto-chain from Step 6.
Action: Read and execute .cursor/skills/test-run/SKILL.md
Step 8 — Security Audit (optional) State-driven: reached by auto-chain from Step 7.
Action: Apply the Optional Skill Gate (protocols.md → "Optional Skill Gate") with:
- question:
Run security audit before deploy? - option-a-label:
Run security audit (recommended for production deployments) - option-b-label:
Skip — proceed directly to deploy - recommendation:
A — catches vulnerabilities before production - target-skill:
.cursor/skills/security/SKILL.md - next-step: Step 9 (Performance Test)
Step 9 — Performance Test (optional) State-driven: reached by auto-chain from Step 8.
Action: Apply the Optional Skill Gate (protocols.md → "Optional Skill Gate") with:
- question:
Run performance/load tests before deploy? - option-a-label:
Run performance tests (recommended for latency-sensitive or high-load systems) - option-b-label:
Skip — proceed directly to deploy - recommendation:
A or B — base on whether acceptance criteria include latency, throughput, or load requirements - target-skill:
.cursor/skills/test-run/SKILL.mdin perf mode (the skill handles runner detection, threshold comparison, and its own A/B/C gate on threshold failures) - next-step: Step 10 (Deploy)
Step 10 — Deploy State-driven: reached by auto-chain from Step 9 (after Step 9 is completed or skipped).
Action: Read and execute .cursor/skills/deploy/SKILL.md.
After the deploy skill completes successfully, mark Step 10 as completed and auto-chain to Step 11 (Retrospective).
Step 11 — Retrospective State-driven: reached by auto-chain from Step 10.
Action: Read and execute .cursor/skills/retrospective/SKILL.md in cycle-end mode. This closes the cycle's feedback loop by folding metrics into _docs/06_metrics/retro_<date>.md and appending the top-3 lessons to _docs/LESSONS.md.
After retrospective completes, mark Step 11 as completed and enter "Done" evaluation.
Done
State-driven: reached by auto-chain from Step 11. (Sanity check: _docs/04_deploy/ should contain all expected artifacts — containerization.md, ci_cd_pipeline.md, environment_strategy.md, observability.md, deployment_procedures.md, deploy_scripts.md.)
Action: Report project completion with summary. Then rewrite the state file so the next /autodev invocation enters the feature-cycle loop in the existing-code flow:
flow: existing-code
step: 9
name: New Task
status: not_started
sub_step:
phase: 0
name: awaiting-invocation
detail: ""
retry_count: 0
cycle: 1
On the next invocation, Flow Resolution rule 1 reads flow: existing-code and re-entry flows directly into existing-code Step 9 (New Task).
Auto-Chain Rules
| Completed Step | Next Action |
|---|---|
| Problem (1) | Auto-chain → Research (2) |
| Research (2) | Auto-chain → Research Decision (ask user: another round or proceed?) |
| Research Decision → proceed | Auto-chain → Plan (3) |
| Plan (3) | Auto-chain → UI Design detection (4) |
| UI Design (4, done or skipped) | Auto-chain → Decompose (5) |
| Decompose (5) | Session boundary — suggest new conversation before Implement |
| Implement (6) | Auto-chain → Run Tests (7) |
| Run Tests (7, all pass) | Auto-chain → Security Audit choice (8) |
| Security Audit (8, done or skipped) | Auto-chain → Performance Test choice (9) |
| Performance Test (9, done or skipped) | Auto-chain → Deploy (10) |
| Deploy (10) | Auto-chain → Retrospective (11) |
| Retrospective (11) | Report completion; rewrite state to existing-code flow, step 9 |
Status Summary — Step List
Flow name: greenfield. Render using the banner template in protocols.md → "Banner Template (authoritative)". No header-suffix, current-suffix, or footer-extras — all empty for this flow.
| # | Step Name | Extra state tokens (beyond the shared set) |
|---|---|---|
| 1 | Problem | — |
| 2 | Research | DONE (N drafts) |
| 3 | Plan | — |
| 4 | UI Design | — |
| 5 | Decompose | DONE (N tasks) |
| 6 | Implement | IN PROGRESS (batch M of ~N) |
| 7 | Run Tests | DONE (N passed, M failed) |
| 8 | Security Audit | — |
| 9 | Performance Test | — |
| 10 | Deploy | — |
| 11 | Retrospective | — |
All rows also accept the shared state tokens (DONE, IN PROGRESS, NOT STARTED, FAILED (retry N/3)); rows 4, 8, 9 additionally accept SKIPPED.
Row rendering format (step-number column is right-padded to 2 characters for alignment):
Step 1 Problem [<state token>]
Step 2 Research [<state token>]
Step 3 Plan [<state token>]
Step 4 UI Design [<state token>]
Step 5 Decompose [<state token>]
Step 6 Implement [<state token>]
Step 7 Run Tests [<state token>]
Step 8 Security Audit [<state token>]
Step 9 Performance Test [<state token>]
Step 10 Deploy [<state token>]
Step 11 Retrospective [<state token>]