docs: run /speckit.checklist after /speckit.plan in quickstart

The quickstart workflow showed /speckit.checklist before /speckit.plan,
contradicting the CLI next-steps text (commands/init.py), which lists the
checklist as running after the plan. Per the maintainer on #2816 — "the
docs were actually wrong here ... checklists are meant for after plan" —
align the docs to the CLI: move /speckit.checklist after /speckit.plan in
the workflow diagram, the prose, and both walkthrough step sequences.

Docs-only; no behavior change.

Closes #2606

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: jawwad-ali

docs/quickstart.md

@@ -13,10 +13,10 @@ This guide will help you get started with Spec-Driven Development using Spec Kit
 After installing Spec Kit and defining your project constitution, quick experiments can use the lean feature path: `/speckit.specify` -> `/speckit.plan` -> `/speckit.tasks` -> `/speckit.implement`. For production features or any work with meaningful ambiguity, treat `/speckit.clarify`, `/speckit.checklist`, and `/speckit.analyze` as regular quality gates:
 
 ```text
-/speckit.constitution -> /speckit.specify -> /speckit.clarify -> /speckit.checklist -> /speckit.plan -> /speckit.tasks -> /speckit.analyze -> /speckit.implement
+/speckit.constitution -> /speckit.specify -> /speckit.clarify -> /speckit.plan -> /speckit.checklist -> /speckit.tasks -> /speckit.analyze -> /speckit.implement
 ```
 
-Use `/speckit.clarify` to reduce requirement ambiguity before planning, `/speckit.checklist` to validate requirements quality before planning, and `/speckit.analyze` to check spec/plan/task consistency before implementation starts. You can repeat `/speckit.analyze` after implementation as an extra review, but keep the first analysis before `/speckit.implement` so gaps are caught while the plan and tasks can still be adjusted.
+Use `/speckit.clarify` to reduce requirement ambiguity before planning, `/speckit.checklist` to validate requirements quality once the plan exists, and `/speckit.analyze` to check spec/plan/task consistency before implementation starts. You can repeat `/speckit.analyze` after implementation as an extra review, but keep the first analysis before `/speckit.implement` so gaps are caught while the plan and tasks can still be adjusted.
 
 ### Step 1: Install Specify
 
@@ -75,12 +75,6 @@ uvx --from git+https://github.com/github/spec-kit.git specify init <PROJECT_NAME
 /speckit.clarify Focus on security and performance requirements.
 ```
 
-Then validate the requirements with `/speckit.checklist` before creating the technical plan:
-
-```bash
-/speckit.checklist
-```
-
 ### Step 5: Create a Technical Implementation Plan
 
 **In the chat**, use the `/speckit.plan` slash command to provide your tech stack and architecture choices.
@@ -89,6 +83,12 @@ Then validate the requirements with `/speckit.checklist` before creating the tec
 /speckit.plan The application uses Vite with minimal number of libraries. Use vanilla HTML, CSS, and JavaScript as much as possible. Images are not uploaded anywhere and metadata is stored in a local SQLite database.
 ```
 
+Then validate quality with `/speckit.checklist` once the plan exists:
+
+```bash
+/speckit.checklist
+```
+
 ### Step 6: Break Down, Analyze, and Implement
 
 **In the chat**, use the `/speckit.tasks` slash command to create an actionable task list.
@@ -150,20 +150,20 @@ You can continue to refine the spec with more details using `/speckit.clarify`:
 /speckit.clarify When you first launch Taskify, it's going to give you a list of the five users to pick from. There will be no password required. When you click on a user, you go into the main view, which displays the list of projects. When you click on a project, you open the Kanban board for that project. You're going to see the columns. You'll be able to drag and drop cards back and forth between different columns. You will see any cards that are assigned to you, the currently logged in user, in a different color from all the other ones, so you can quickly see yours. You can edit any comments that you make, but you can't edit comments that other people made. You can delete any comments that you made, but you can't delete comments anybody else made.
 ```
 
-### Step 4: Validate the Spec
+### Step 4: Generate Technical Plan with `/speckit.plan`
 
-Validate the specification checklist using the `/speckit.checklist` command:
+Be specific about your tech stack and technical requirements:
 
 ```bash
-/speckit.checklist
+/speckit.plan We are going to generate this using .NET Aspire, using Postgres as the database. The frontend should use Blazor server with drag-and-drop task boards, real-time updates. There should be a REST API created with a projects API, tasks API, and a notifications API.
 ```
 
-### Step 5: Generate Technical Plan with `/speckit.plan`
+### Step 5: Validate the Spec
 
-Be specific about your tech stack and technical requirements:
+Validate the specification checklist using the `/speckit.checklist` command:
 
 ```bash
-/speckit.plan We are going to generate this using .NET Aspire, using Postgres as the database. The frontend should use Blazor server with drag-and-drop task boards, real-time updates. There should be a REST API created with a projects API, tasks API, and a notifications API.
+/speckit.checklist
 ```
 
 ### Step 6: Define Tasks