You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Several community extensions are still bundled and installed by default even though their responsibilities and contracts have become outdated relative to the current Spec Kit architecture. This adds maintenance cost, keeps stale workflow assumptions alive, and makes newly initialized projects look more complex and authoritative than they should.
The first known candidates are:
intake
inception
The remaining default community extensions should be reviewed in the same cleanup:
discovery
preview
repository-governance
Today these extensions are referenced across the default-extension configuration, bundled snapshots, package data, catalogs, documentation, workflow presets, and tests. Removing only one catalog entry would leave an inconsistent and misleading distribution.
Proposed Solution
Retire obsolete bundled community extensions from the default distribution, beginning with intake and inception, and perform a maintainer audit of the other default community extensions.
For every extension selected for retirement:
Remove it from the default installation set.
Remove its bundled snapshot and package-data registration.
Remove or mark its catalog entry as retired so users are not directed to an obsolete integration.
Delete or replace workflow-preset assumptions that depend on its commands, artifacts, blocker routes, or schemas.
Update README, community-extension docs, examples, and upgrade notes.
Update tests and fixtures so they assert the new minimal default set.
Preserve existing user projects: upgrading Spec Kit must not destructively delete extension files already installed in a project.
The resulting default installation should contain only extensions that are actively maintained, still match the current architecture, and provide clear value as defaults. Maintained but non-essential community extensions can remain opt-in rather than bundled or auto-installed.
Alternatives Considered
Keep the extensions bundled but stop installing them by default. This reduces initial clutter but leaves obsolete snapshots, contracts, documentation, and maintenance burden in the repository.
Mark them deprecated without removal. This is useful only as a short migration stage; it should not become the permanent state.
Remove only intake. This would miss the broader problem that the current default community-extension set has not been revalidated as a whole.
Component
Other — extension catalog, bundled community extensions, default initialization, workflow presets, documentation, and tests.
AI Agent (if applicable)
Not applicable.
Use Cases
A new user runs specify init and receives a small, current, understandable default workflow.
Maintainers can evolve core and preset contracts without preserving obsolete extension-specific artifact routes.
Community extensions remain discoverable as opt-in components only when they are maintained and compatible.
Existing projects can upgrade without Spec Kit silently deleting user-managed extension files.
Acceptance Criteria
Maintainers document which default community extensions are retained, moved to opt-in, deprecated, or removed, with a reason for each decision.
intake and inception are no longer installed by default.
Every retired extension is removed from bundled snapshots and package-data configuration.
Catalog entries for retired extensions are removed or carry an explicit retirement state and migration guidance.
Core commands and workflow presets no longer require retired extension commands, schemas, artifacts, or routes.
README, community-extension docs, examples, and upgrade guidance reflect the new default set.
Tests cover fresh initialization, upgrade behavior, extension listing, package contents, and the workflow contracts affected by the cleanup.
Upgrades do not destructively remove extension files from existing user projects.
git diff --check, focused extension/init/preset tests, and the repository test suite pass.
Additional Context
Current repository evidence includes the default extension list in src/specify_cli/commands/init.py, bundled/package-data registration in pyproject.toml, extension metadata in extensions/catalog.json and extensions/catalog.community.json, bundled sources under extensions/, and extensive references in README, workflow presets, and tests. This should therefore be handled as one coordinated retirement rather than a catalog-only edit.
AI Disclosure
Posted on behalf of @bigsmartben by OpenAI Codex (GPT-5, autonomous). Codex inspected the local repository, mapped the affected surfaces, and drafted this issue; scope and implementation remain subject to maintainer review.
Problem Statement
Several community extensions are still bundled and installed by default even though their responsibilities and contracts have become outdated relative to the current Spec Kit architecture. This adds maintenance cost, keeps stale workflow assumptions alive, and makes newly initialized projects look more complex and authoritative than they should.
The first known candidates are:
intakeinceptionThe remaining default community extensions should be reviewed in the same cleanup:
discoverypreviewrepository-governanceToday these extensions are referenced across the default-extension configuration, bundled snapshots, package data, catalogs, documentation, workflow presets, and tests. Removing only one catalog entry would leave an inconsistent and misleading distribution.
Proposed Solution
Retire obsolete bundled community extensions from the default distribution, beginning with
intakeandinception, and perform a maintainer audit of the other default community extensions.For every extension selected for retirement:
The resulting default installation should contain only extensions that are actively maintained, still match the current architecture, and provide clear value as defaults. Maintained but non-essential community extensions can remain opt-in rather than bundled or auto-installed.
Alternatives Considered
intake. This would miss the broader problem that the current default community-extension set has not been revalidated as a whole.Component
Other — extension catalog, bundled community extensions, default initialization, workflow presets, documentation, and tests.
AI Agent (if applicable)
Not applicable.
Use Cases
specify initand receives a small, current, understandable default workflow.Acceptance Criteria
intakeandinceptionare no longer installed by default.git diff --check, focused extension/init/preset tests, and the repository test suite pass.Additional Context
Current repository evidence includes the default extension list in
src/specify_cli/commands/init.py, bundled/package-data registration inpyproject.toml, extension metadata inextensions/catalog.jsonandextensions/catalog.community.json, bundled sources underextensions/, and extensive references in README, workflow presets, and tests. This should therefore be handled as one coordinated retirement rather than a catalog-only edit.AI Disclosure
Posted on behalf of @bigsmartben by OpenAI Codex (GPT-5, autonomous). Codex inspected the local repository, mapped the affected surfaces, and drafted this issue; scope and implementation remain subject to maintainer review.