Should we really retain all the generated artifacts indefinitely in version control?

[scooter-dangle]

If I think of AI+Spec-kit as a compiler, the generated files in the spec directory are primarily intermediate build artifacts. The spec file itself might be thought of as annotated source code, since it has the bit that came from a human / primary agent.

We don't traditionally commit intermediate build artifacts from pre-AI compilers, and they generate a lot of noise. It's not clear which pieces might still have value later other than the spec. And even that often looks more like what we'd have in our project tracking application (e.g., Jira). For teams / developers where I'm advocating trying spec driven development, committing vast amounts of what looks like non-code is a barrier.

And aside from whether it permanently belongs in the repo, there's also the fact that these workflows are still very new for many people, and if we want them to learn how to use them to greatest effect, I like the build artifacts being available somewhere for debugging and learning.

In many CI/CD workflows, the build artifacts are stored for some time in a location outside the repo itself and provide that ability to debug when the build doesn't behave as expected.

E.g., I could see one option being that all the extra files get attached to the PR for visibility but are excluded from the code change itself. Are there other options? How do other people handle these files in practice?

[mnriem]

Thanks for raising this—you don’t have to retain every generated artifact indefinitely. The compiler analogy is useful, though feature specs can capture intent that isn’t recoverable from the code alone. Our spec persistence guide currently describes flow-back, flow-forward, and living-spec approaches; we’re working on documenting a fourth, constitution-only model.

All four retain the constitution as overarching project governance. Constitution-only retires completed feature delivery artifacts from maintained repository content after the usual delivery and review process—not all project documentation, and not the feature-level intent itself. Enduring requirements, acceptance criteria, and decisions still need a maintained home, whether that’s documentation, design records, or a tracker. Attaching delivery artifacts to a PR or archiving them externally fits that approach; teams can also discard them according to their own policy.

Spec Kit itself illustrates the distinction: it tracks .specify/memory/constitution.md but ignores specs/, while documentation, tests, and contributor guidance preserve enduring knowledge. That demonstrates exclusion from version control, not automatic cleanup: archival and deletion remain team policy, not an automatic CLI feature.

[scooter-dangle]

Thanks for the response 👍

Our spec persistence guide currently describes flow-back, flow-forward, and living-spec approaches; we’re working on documenting a fourth, constitution-only model.

That link 404s for me 🤔