Summary
The git extension is currently bundled and enabled by default during specify init. Starting with v1.0.0, it will still be bundled but no longer enabled by default — users will need to explicitly opt in. We should add messaging now so users are aware of the upcoming change.
📋 Spec artifact linked: features/git-extension-deprecation-notice/spec.md
Problem Statement
The git extension is currently bundled and enabled by default during specify init. Starting with v1.0.0, it will still be bundled but no longer enabled by default — users will need to explicitly opt in. Without advance notice, users may be surprised by this change when upgrading to v1.0.0.
Requirements
Functional Requirements
- FR-1: During
specify init, display a warning notice when the git extension is auto-enabled
- FR-2: The notice must clearly state the timeline (v1.0.0) for the change
- FR-3: The notice must explain how to opt in after the change (
specify init --extension git or specify extension add git)
- FR-4: The notice must be non-blocking (warning styling, does not halt initialization)
Non-Functional Requirements
- NFR-1: Notice should use yellow/warning styling consistent with existing CLI warning patterns
- NFR-2: Notice should be concise and actionable
User Scenarios
Scenario 1: User runs specify init and sees deprecation notice
Given a user is initializing a new project with specify init
When the git extension is auto-enabled as part of the default behavior
Then a warning notice is displayed informing them that the git extension will require explicit opt-in starting with v1.0.0
Scenario 2: User understands how to opt in after v1.0.0
Given a user sees the deprecation notice during specify init
When they read the notice
Then they understand they can use specify init --extension git or specify extension add git to enable the git extension after v1.0.0
Acceptance Criteria
Out of Scope
- Changes to the git extension itself or its functionality
- Changes to the bundled status of the git extension (it remains bundled/shipped with spec-kit)
- Actually removing the default-enabled behavior (that happens at v1.0.0, not now)
Summary
The
gitextension is currently bundled and enabled by default duringspecify init. Starting with v1.0.0, it will still be bundled but no longer enabled by default — users will need to explicitly opt in. We should add messaging now so users are aware of the upcoming change.Problem Statement
The
gitextension is currently bundled and enabled by default duringspecify init. Starting with v1.0.0, it will still be bundled but no longer enabled by default — users will need to explicitly opt in. Without advance notice, users may be surprised by this change when upgrading to v1.0.0.Requirements
Functional Requirements
specify init, display a warning notice when the git extension is auto-enabledspecify init --extension gitorspecify extension add git)Non-Functional Requirements
User Scenarios
Scenario 1: User runs specify init and sees deprecation notice
Given a user is initializing a new project with
specify initWhen the git extension is auto-enabled as part of the default behavior
Then a warning notice is displayed informing them that the git extension will require explicit opt-in starting with v1.0.0
Scenario 2: User understands how to opt in after v1.0.0
Given a user sees the deprecation notice during
specify initWhen they read the notice
Then they understand they can use
specify init --extension gitorspecify extension add gitto enable the git extension after v1.0.0Acceptance Criteria
specify initshows a notice when the git extension is auto-enabledOut of Scope