Skip to content

How to keep specs consistent and up-to-date with spec-kit? #620

@elebescond

Description

@elebescond

With spec-kit, each feature defines its own spec. This works well at first, but over time and with the multiplication of features, some descriptions become outdated or are enriched by new features.

Example

  • Feature 001 – User Login defines that a user can log in with email + password.
  • A few months later, feature 009 – Two-Factor Authentication enhances the login by adding an extra step (OTP code).

In this case, the original spec of feature 001 becomes partially outdated or needs to be complemented by feature 009.

Discussion

  • Is there a recommended approach to consolidate specs over time?
  • Should the original feature be modified, or is it better to keep the historical record and add links to subsequent evolutions?
  • Are there patterns used by the community to manage the evolution and consistency of specs as new features are added?
  • Idea: Would it be useful to introduce a /close command (or equivalent) to mark a feature as deprecated and automatically update a centralized project documentation?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions