Refactoring specs how to?

[voipp]

When i want to perform refactoring, should i run speckit specify?
In this case previous old specs arent got altered, why?

[Kxrma47]

/speckit.specify describes the next bounded change; it does not automatically rewrite older specs/.../spec.md files. For a refactor, write a new spec that states what must stay compatible (public behavior, API, data, tests) and what internal structure may change, e.g. /speckit.specify Refactor the parser into modules; preserve inputs, outputs, and error behavior. Then run clarify → plan → tasks → analyze for that change.

If you are still working on the same feature and its existing spec is wrong, explicitly edit that feature's spec.md and regenerate/review its downstream plan and tasks. A purely internal cleanup need not retroactively alter unrelated old specs.

Reference: Spec Kit's existing-project guide.

[TongyiDai]

/speckit.specify is appropriate for a refactor when the refactor is a new bounded change, but whether an old spec should change depends on the persistence model you chose.

The current Evolving Specs guide describes three supported models:

• Flow-forward: create a new spec for the refactor and leave older feature directories as historical records.
• Living spec: edit the existing spec first, then regenerate or revise plan.md and tasks.md.
• Flow-back: capture an implementation discovery where it occurs, then reconcile every artifact that now disagrees.

That is why old specs are not changed automatically: Spec Kit cannot know whether your team treats them as immutable history or as living contracts, and rewriting them would destroy provenance for flow-forward projects.

For a behavior-preserving refactor, I would normally use flow-forward:

1. Run /speckit.specify with the desired internal change and explicit compatibility constraints.
2. Run clarify, plan, and tasks.
3. Run analyze before implementation.
4. Run implement and converge, reviewing both code and artifact diffs.

Example requirement: “Refactor the parser into modules; preserve public API, inputs, outputs, error behavior, and existing tests.”

If the existing spec is still the authoritative contract and is factually wrong, use the living-spec path instead: edit that spec explicitly, update its downstream plan and tasks, then run /speckit.analyze. Do not alter unrelated completed specs merely because the implementation was reorganized.

Guide: https://github.com/github/spec-kit/blob/main/docs/guides/evolving-specs.md