What's the correct workflow after executing the plan to refine/fix implementation

[kodoa-dev]

Hi,

Spec-kit is great, it's my new workflow and I love it, but as you probably know, sometimes the result is not 100% aligned with what was wanted.
It could be because of deviations, bugs or simply because we missed some features or details in the planning mode.

Now my question is simple: when the tasks are fully implemented, but the result is not perfect, whats the correct workflow ? Create new tasks, a whole new plan to fix and modify features ? Just interacting with my agent ?

The goal is the agent to make use of the context and what has been done to be good at fixing issues and improving features.

Thanks a lot !

[faaz-netapp]

@aesislabs , I have been testing out /clarify option to refine the specs after they have been generated and also after a plan has been generated. Altough would love to hear prespective of other users.

[Helleeni]

I have the same question - it's not clear for me how to continue to fix bugs after the tasks have been implemented. It would be great to have a guideline for this. Now the agent context window is often used after implementation, and one would need to open a new agent chat for starting to fix the defects, but then one looses all the goods that come with Spec Kit /implement command.

[nvcnvn]

I use something like:
/implement fix bug: ....

At least it will add the fix bug tasks to the list.

[jkp]

im also wondering this - since the specs are meant to be the ssot - if we find something out during implementation - do we back out and update the specs / plan and redo everything?

[wilsonneto-swe]

Sure, the plan is to have this back and forth situation in complex scenarios, before fixing the issue explain the issue and the fix to the agent and ask it to update the task/plan/data-model/contracts or any related file that should be fixed to reflect the fix and mainly avoid it happening again.

In some cases you can even fix the issue, or ask the agent to fix it, then after it ask the agent again to update the task, plan, data-model, contracts or any related file to make it aligned. Remember that the specification is the durable thing, the plan, tasks and so on are the flexible ones.

[Helleeni]

Maybe there could be a /bugfix command that would take the bug description, read the constitution, spec, plan and tasks of the feature and proceed to fix the bug in the same branch (or in a new branch if the feature is already merged to main branch) and update the test cases and then the documents once approved by user.
What I observe now is that if I do bug fixes that alter the implementation some way, then the tests and the documentation will immediately be out of date.

[wilsonneto-swe]

Sure, I agree!

[schnee]

at pre-implementation /clarify seems to be the correct command, at least idiomatically. E.g. /clarify remove FR-008 because we don't require authentication.

[wilsonneto-swe]

Clarify is designed to be used after the spec, after the task break and before the implementation the proper command is analyse (AFAIK).

[danieldekay]

Yes, just for getting rid of under-specd content.