You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 /plan command. I’m more comfortable refining the original plan input rather than directly editing plan.md, and then rerunning /plan, followed by /tasks and /analyze.
When it suggests modifying the spec:
The spec also follows its own structure and syntax, which differs from the original /plan input description. Fortunately, I can use /clarify to enrich the user story details, and then rerun /checklist, /plan, /tasks, and /analyze.
My Questions
Is my understanding correct? And is my approach to handling tasks, plan, and spec appropriate?
If I run analyze, update the spec, and then run analyze again and receive more suggestions—can I keep repeating this process until there are no more issues, and only then proceed to implement? Is it acceptable to iterate on the analyze step multiple times like this?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
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