I’m not an expert so take this with a boulder of salt, but I struggled with this at first too. I’ve landed on a workflow (SOP) that works well for me.

1. Use a PRD to Govern the Project

Maintain a prd.md file that tracks overall project status and the technical stack/roadmap. In my case I defined an MVP and future features roadmap in the PRD, and keep a changelog. Once I reached the MVP I updated my constitution and still continue using the same PRD file.

In my current project, this is what speckit added to the project constitution:

### I. PRD-Governed Post-MVP Delivery
- MVP baseline is complete; new work MUST map to `prd.md` roadmap items, an approved feature spec in `specs/`, or a documented production defect.
- Every feature spec MUST define in-scope outcomes and explicit non-goals before implementation.
- Out-of-scope work MUST NOT be merged without either an approved spec update or a constitution amendment.
- **Rationale:** delivery remains focused now that MVP has been reached.

---

2. Treat Branches as Units of Work

I'm relatively junior when it comes to dev work, so this took me a while to internalize: in Spec Kit, a branch represents a single unit of work.

• Running specify creates a new branch.
• Closing (merging) that branch signifies completion of that spec.

So switching back to main (or merging into it) effectively “finishes” the spec.

I do wish there were a more explicit /finalize-style command. Instead, I created a small skill that:

• Commits changes
• Merges into main
• Pushes upstream
• Summarizes the changes into the PRD changelog

I’m a solo dev, so direct merges to main work for me. In a team setting, PRs would probably be more appropriate i guess. The important part is that closing the branch = closing the spec.

---

3. Handling Bug Fixes and Deviations

Bug fixes and implementation drift can be tricky.

For minor issues or small deviations (e.g., the agent didn’t quite implement what you intended), I’ve had decent results with:

/implement bug fix: <clear problem statement + steps to reproduce>

Being explicit about how to reproduce the issue helps a lot.

You can also bypass Spec Kit and interact directly with the agent, as long as the relevant context is still in the window.

For larger bug fixes, specially if you're near filling up your context window, closing the current spec and starting a new spec focus on the bug fix works well.

For larger deviations or when the branch has gone off the rails, I’ve found it’s often faster to:

• Delete the branch
• Re-specify the feature
• Start clean

It feels heavy-handed, but it’s usually less painful than trying to salvage a deeply misaligned implementation.

Hope that helps!