I was manually invoking every stage in GitHub Spec Kit. I still ended up with a plan that included work I hadn't expected the feature to contain.
This wasn't an agent autonomously running through a sequence. I invoked a specific skill for each stage. In the first planning round, I reviewed the outputs lightly and trusted the generated decisions. When I got to the plan and tasks, I found misinterpretations of the problem and tasks outside my expected scope.
The uncomfortable part is that I was present throughout. Choosing to run the next stage wasn't the same as understanding and accepting the decisions carried into it.
Keep the finding, separate the decision
One part of that first plan included proposed fixes for possible preexisting problems. Their remediation had become feature work without the scope decision being clearly brought back to me.
That stayed in the plan and tasks. I didn't implement the first plan or make those out-of-scope code changes.
I created separate tickets to preserve the findings and directed their resolution outside the feature. The scope expansion was one of several problems that led me to discard the first plan and restart planning from scratch.
The useful distinction here isn't between a good finding and a bad finding. It's between discovering something worth addressing and deciding that this feature should address it.
Treat those as separate decisions:
- Assess the finding: what supports it, and what still needs confirmation?
- Decide its disposition: address it here, track it separately, or reject it with a reason.
- Approve any change to the feature's scope before treating it as an implementation obligation.
Keeping everything in the feature and throwing away everything outside it are not the only options. In my case, separate tickets preserved the findings without keeping their remediation in the feature plan.
Separate tracking is a scope decision, not a claim that the underlying problem is solved.
What changed in the second round
In the second round, I controlled the inputs more closely, corrected interpretations after each stage, and directed decisions along the way. That second plan is the one I followed for implementation.
The change was where I applied judgment. In the first round, reviewing the plan and tasks exposed decisions that had already accumulated. In the second, I reviewed and corrected them stage by stage.
That is a more involved way to use the workflow. It asks for attention during planning rather than only when the task list is ready. The tradeoff to weigh is review burden against how much interpretation you're willing to let accumulate before examining it.
Don't turn that into a demand to approve every sentence. Focus the review on interpretations that change the problem, the constraints, or what work belongs in the feature. That's the review I needed to take more seriously, too.
Where I'd put the architectural boundary
For a workflow that needs enforced approval, the recommendation goes beyond more careful reading: put consequential state transitions outside model judgment. This is an architectural recommendation, not a capability I'm claiming Spec Kit provided in my run.
Let the model identify concerns and propose a response. Require a separate human decision before a proposed scope expansion becomes accepted feature work. Have the surrounding workflow enforce that distinction rather than asking the same model to infer whether continuing means approval.
A practical checkpoint would ask:
- What changed in the interpretation of the feature?
- Which findings introduce work outside its current scope?
- Which additions are explicitly accepted, and which belong elsewhere?
Those questions are a suggested review aid, not a description of an approval mechanism I implemented.
Before starting the next stage, review the scope delta—not just whether the output looks complete.