Integrating specs/ outputs into docs, workflow and prompts?*

[MrHinsh]

Do you continuously integrate outputs from specs/* back into your core documentation and architecture?

Context:

• I maintain a /docs folder covering architecture, CLI, TUI, orchestration, and module-level design
• I also have an .agent folder with guardrails and context definitions

Question:

• After implementation, do you systematically update docs to reflect what was actually built?
• If yes:
  • When does this happen, during the branch, post-merge, or as a separate activity?
  • Is this driven by a dedicated prompt or workflow?
  • Do you treat documentation updates as part of the Definition of Done, or as a follow-on process?

I am specifically trying to understand whether others:

1. Keep docs in lockstep with implementation via prompts in-branch
2. Run a separate consolidation step after implementation
3. Or accept drift and periodically reconcile

Looking for concrete workflows and prompts, not principles.

[mnriem]

As Spec Kt is very flexible now with several ways of working with it have you looked at the available community extensions as per https://github.com/github/spec-kit?tab=readme-ov-file#-community-extensions ?

[MrHinsh]

Yes, and I don't see anything that relates to my ask.

[mnriem]

Please consider writing an extension or a preset if you see a gap! Or continue the discussion here on what you need in more detail so others can chime in

[thompcd]

I've been thinking about the same thing. I'm trying to find a way to use my specs as a living definition of the product's expectations and wanting to figure out the best workflow for a team to do this.

[mnriem]

Note that we have just release 0.7.0 that includes Spec Kit workflows