docs: document high-assurance spec workflow#2518
Conversation
There was a problem hiding this comment.
Pull request overview
Updates the Quick Start documentation to present clarify, checklist, and analyze as standard quality gates for higher-assurance workflows, rather than optional steps.
Changes:
- Reframes the Quick Start workflow as “Recommended Workflow” and adds a high-assurance command sequence.
- Updates the “Break Down and Implement” step to include explicit
/speckit.checklistand/speckit.analyzevalidation prior to/speckit.implement. - Tweaks the “Key Principles” guidance to emphasize validating requirements and plans before coding.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| > [!TIP] | ||
| > **Context Awareness**: Spec Kit commands automatically detect the active feature based on your current Git branch (e.g., `001-feature-name`). To switch between different specifications, simply switch Git branches. | ||
|
|
||
| For quick experiments, you can move directly from `specify` to `plan`, `tasks`, and `implement`. For production features or any work with meaningful ambiguity, treat `clarify`, `checklist`, and `analyze` as regular quality gates: |
| ```text | ||
| /speckit.specify -> /speckit.clarify -> /speckit.plan -> /speckit.tasks -> /speckit.checklist -> /speckit.analyze -> /speckit.implement | ||
| ``` |
| ```text | ||
| /speckit.specify -> /speckit.clarify -> /speckit.plan -> /speckit.tasks -> /speckit.checklist -> /speckit.analyze -> /speckit.implement | ||
| ``` | ||
|
|
||
| Use `clarify` to reduce requirement ambiguity before planning, `checklist` to validate requirements quality before implementation, and `analyze` to check spec/plan/task consistency before implementation starts. |
| ``` | ||
|
|
||
| ### Step 6: Break Down and Implement | ||
| ### Step 6: Break Down, Analyze, and Implement |
mnriem
left a comment
There was a problem hiding this comment.
Please address Copilot feedback
cab45c4 to
6220cc8
Compare
|
Addressed Copilot feedback in 6220cc8: clarified slash-command names, moved checklist before planning to match the detailed example, changed the flow to implement before analyze, and updated the headings accordingly. |
There was a problem hiding this comment.
Copilot's findings
Comments suppressed due to low confidence (2)
docs/quickstart.md:110
- Step 6 instructs running
/speckit.implementand only then/speckit.analyze, butanalyzeis designed to run aftertasksand before implementation to validate spec/plan/tasks consistency. Reorder these two substeps (and wording) so the analysis gate happens before/speckit.implement.
Use the `/speckit.implement` slash command to execute the plan.
```markdown
/speckit.implement
After implementation, use /speckit.analyze as a final consistency check:
/speckit.analyze**docs/quickstart.md:188**
* In the Detailed Example, Step 7 has `/speckit.implement` before `/speckit.analyze`, which contradicts the command’s documented intent (analyze after tasks, before implement). Swap the order so the analysis is an actual pre-implementation quality gate.
Step 7: Implement and Analyze
Finally, implement the solution:
/speckit.implementThen use /speckit.analyze as the final quality gate:
/speckit.analyze- Files reviewed: 1/1 changed files
- Comments generated: 2
| For quick experiments, you can move directly from `/speckit.specify` to `/speckit.plan`, `/speckit.tasks`, and `/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.specify -> /speckit.clarify -> /speckit.checklist -> /speckit.plan -> /speckit.tasks -> /speckit.implement -> /speckit.analyze | ||
| ``` | ||
|
|
||
| Use `/speckit.clarify` to reduce requirement ambiguity before planning, `/speckit.checklist` to validate requirements quality before planning, and `/speckit.analyze` as a final consistency check after implementation. |
| > [!TIP] | ||
| > **Context Awareness**: Spec Kit commands automatically detect the active feature based on your current Git branch (e.g., `001-feature-name`). To switch between different specifications, simply switch Git branches. | ||
|
|
||
| For quick experiments, you can move directly from `/speckit.specify` to `/speckit.plan`, `/speckit.tasks`, and `/speckit.implement`. For production features or any work with meaningful ambiguity, treat `/speckit.clarify`, `/speckit.checklist`, and `/speckit.analyze` as regular quality gates: |
|
Please address Copilot feedback |
Description
Closes #2496.
Updates the quickstart guide to present
clarify,checklist, andanalyzeas regular quality gates for production or ambiguity-heavy work. The recommended command path now shows the high-assurance flow before implementation and the task breakdown step now includes checklist and analysis validation before/speckit.implement.Testing
uv run specify --helpuv sync && uv run pytestAdditional validation:
git diff --checknpx markdownlint-cli2 docs/quickstart.mdAI Disclosure
Used AI assistance to inspect repository context, draft the documentation wording, and run local validation; the changes were reviewed before submission.