Replies: 1 comment
-
|
You have 4 options when it comes to modifying what Spec Kit produces:
There is no hard and set rule for when to use which and how many times. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Officially Documented Workflow
According to the official documentation, the workflow for using SpecKit is:
constitution → spec → plan → tasks → implement
There are also optional steps:
References: Commands and Guide details
My Understanding
From my experience using it, during the analyze step, SpecKit provides suggestions such as modifying the tasks, plan, or even the spec.
When it suggests modifying tasks:
I prefer not to manually edit the file. Instead, I would rather modify the plan and regenerate the tasks. This is because the tasks file contains many implicit SpecKit conventions (e.g., Phase, checkpoints, [P], [US], [T00X], etc.), which are auto-generated. I’m not familiar with these conventions, and even if I try to imitate them, the internal references become difficult to manage.
When it suggests modifying the plan:
The plan also has its own structure and syntax, which differs from the original description I provided when using the
/plancommand. I’m more comfortable refining the original plan input rather than directly editingplan.md, and then rerunning/plan, followed by/tasksand/analyze.When it suggests modifying the spec:
The spec also follows its own structure and syntax, which differs from the original
/planinput description. Fortunately, I can use/clarifyto enrich the user story details, and then rerun/checklist,/plan,/tasks, and/analyze.My Questions
Beta Was this translation helpful? Give feedback.
All reactions