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
The enrichment comment has been posted on issue #750. Here's a summary of what was covered:
Issue #750 asks for an OpenSpec extension for GitHub's SpecKit framework. The comment I posted addresses:
What SpecKit extensions are — manifest-based packages with commands, hooks, and config, using Markdown files with YAML frontmatter (very similar to OpenSpec's existing skill format)
Two interpretations of the request:
A standalone SpecKit extension that wraps OpenSpec's 10 workflow commands into SpecKit's speckit.openspec.* command format
An internal SpecKit adapter added to OpenSpec's 24-adapter generation pipeline
Relevant codebase context — key files involved (types.ts, registry.ts, config.ts, adapter examples), the README's explicit comparison to SpecKit, and the active add-tool-command-surface-capabilities proposal that would affect how a SpecKit adapter is classified
No duplicates found in existing issues
Suggested approach — start with the standalone extension (interpretation feat: initialize typescript project #1), then optionally add a SpecKit adapter to OpenSpec's generation pipeline
Thanks for the suggestion. Here's some context to help frame this request.
What's being asked
The request is to create an OpenSpec extension for SpecKit — GitHub's spec-driven development toolkit. SpecKit has a community extensions system where third-party tools can register commands, hooks, and configuration into the SpecKit workflow.
What a SpecKit extension looks like
A SpecKit extension is a directory with:
extension.yml — manifest declaring ID, version, commands, hooks, and config
commands/ — Markdown files with YAML frontmatter (similar to OpenSpec's existing skill format)
Commands follow the naming pattern speckit.{extension-id}.{command-name} and are Markdown files with a description frontmatter field and $ARGUMENTS placeholders for user input. Extensions can also define hooks (after_tasks, after_implement, etc.) and configuration.
The SpecKit catalog (catalog.json) is currently empty — no community extensions have been published yet, though a V-Model extension pack exists as a reference.
How this relates to the current codebase
There are two possible interpretations of this request:
1. A SpecKit extension that wraps OpenSpec workflows (external extension)
This would be a standalone extension living in the SpecKit ecosystem that exposes OpenSpec's workflows as SpecKit commands (e.g., speckit.openspec.explore, speckit.openspec.apply). This would let SpecKit users invoke OpenSpec workflows from within SpecKit's command surface.
This is straightforward to build. OpenSpec already generates Markdown-based command files with YAML frontmatter for 24 tools — the SpecKit extension format is very similar. The workflow templates in src/core/templates/workflows/ produce the command content, and a mapping to SpecKit's extension.yml manifest + commands/ structure would be needed.
2. A SpecKit adapter inside OpenSpec (internal adapter)
This would add SpecKit as a supported tool in OpenSpec's adapter system, similar to the 24 existing adapters in src/core/command-generation/adapters/. This would mean running openspec init --tools speckit would generate OpenSpec skills into SpecKit's expected directory structure (.specify/extensions/).
The README explicitly compares OpenSpec to SpecKit at line 134: "vs. Spec Kit (GitHub) — Thorough but heavyweight. Rigid phase gates, lots of Markdown, Python setup. OpenSpec is lighter and lets you iterate freely."
The active proposal add-tool-command-surface-capabilities is introducing a capability model (adapter, skills-invocable, none) that would affect how a SpecKit adapter would be classified
SpecKit uses Python (specify CLI) while OpenSpec is TypeScript/Node — they are separate runtimes, so integration would be at the file/command level rather than programmatic
No duplicate issues found
No existing issues reference SpecKit or a SpecKit extension.
Suggested approach
The most practical path would be interpretation #1: a standalone SpecKit extension that maps OpenSpec's 10 workflow commands (explore, new-change, continue-change, ff-change, apply-change, verify-change, sync-specs, archive-change, bulk-archive-change, onboard) into SpecKit's extension format. This could live in a separate repo or as a directory in this repo.
A secondary step could be interpretation #2: adding a SpecKit adapter to OpenSpec's generation pipeline so that openspec init can produce SpecKit-compatible files directly, following the same pattern as the existing 24 adapters.
Thanks for the suggestion, Josef! We've evaluated this and a SpecKit extension isn't something we're planning to build at this time — we have a lot on our plate and want to stay focused. Closing for now, but feel free to open a new discussion if the community picks up interest.
Activity
21st-connector commentedon Feb 23, 2026
Task completed.
The enrichment comment has been posted on issue #750. Here's a summary of what was covered:
Issue #750 asks for an OpenSpec extension for GitHub's SpecKit framework. The comment I posted addresses:
What SpecKit extensions are — manifest-based packages with commands, hooks, and config, using Markdown files with YAML frontmatter (very similar to OpenSpec's existing skill format)
Two interpretations of the request:
speckit.openspec.*command formatRelevant codebase context — key files involved (
types.ts,registry.ts,config.ts, adapter examples), the README's explicit comparison to SpecKit, and the activeadd-tool-command-surface-capabilitiesproposal that would affect how a SpecKit adapter is classifiedNo duplicates found in existing issues
Suggested approach — start with the standalone extension (interpretation feat: initialize typescript project #1), then optionally add a SpecKit adapter to OpenSpec's generation pipeline
View full conversation
Powered by 1Code
21st-connector commentedon Feb 23, 2026
Issue Analysis
Thanks for the suggestion. Here's some context to help frame this request.
What's being asked
The request is to create an OpenSpec extension for SpecKit — GitHub's spec-driven development toolkit. SpecKit has a community extensions system where third-party tools can register commands, hooks, and configuration into the SpecKit workflow.
What a SpecKit extension looks like
A SpecKit extension is a directory with:
extension.yml— manifest declaring ID, version, commands, hooks, and configcommands/— Markdown files with YAML frontmatter (similar to OpenSpec's existing skill format)config-template.yml— optional configuration schemaCommands follow the naming pattern
speckit.{extension-id}.{command-name}and are Markdown files with adescriptionfrontmatter field and$ARGUMENTSplaceholders for user input. Extensions can also define hooks (after_tasks,after_implement, etc.) and configuration.The SpecKit catalog (
catalog.json) is currently empty — no community extensions have been published yet, though a V-Model extension pack exists as a reference.How this relates to the current codebase
There are two possible interpretations of this request:
1. A SpecKit extension that wraps OpenSpec workflows (external extension)
This would be a standalone extension living in the SpecKit ecosystem that exposes OpenSpec's workflows as SpecKit commands (e.g.,
speckit.openspec.explore,speckit.openspec.apply). This would let SpecKit users invoke OpenSpec workflows from within SpecKit's command surface.This is straightforward to build. OpenSpec already generates Markdown-based command files with YAML frontmatter for 24 tools — the SpecKit extension format is very similar. The workflow templates in
src/core/templates/workflows/produce the command content, and a mapping to SpecKit'sextension.ymlmanifest +commands/structure would be needed.2. A SpecKit adapter inside OpenSpec (internal adapter)
This would add SpecKit as a supported tool in OpenSpec's adapter system, similar to the 24 existing adapters in
src/core/command-generation/adapters/. This would mean runningopenspec init --tools speckitwould generate OpenSpec skills into SpecKit's expected directory structure (.specify/extensions/).Key files involved:
src/core/command-generation/types.ts—ToolCommandAdapterinterfacesrc/core/command-generation/adapters/— where aspeckit.tsadapter would gosrc/core/command-generation/registry.ts— adapter registrationsrc/core/config.ts— tool metadata (name, value, skillsDir)src/core/init.ts:558-567— skill installation logicRelevant context
add-tool-command-surface-capabilitiesis introducing a capability model (adapter,skills-invocable,none) that would affect how a SpecKit adapter would be classifiedspecifyCLI) while OpenSpec is TypeScript/Node — they are separate runtimes, so integration would be at the file/command level rather than programmaticNo duplicate issues found
No existing issues reference SpecKit or a SpecKit extension.
Suggested approach
The most practical path would be interpretation #1: a standalone SpecKit extension that maps OpenSpec's 10 workflow commands (
explore,new-change,continue-change,ff-change,apply-change,verify-change,sync-specs,archive-change,bulk-archive-change,onboard) into SpecKit's extension format. This could live in a separate repo or as a directory in this repo.A secondary step could be interpretation #2: adding a SpecKit adapter to OpenSpec's generation pipeline so that
openspec initcan produce SpecKit-compatible files directly, following the same pattern as the existing 24 adapters.alfred-openspec commentedon Feb 23, 2026
Thanks for the suggestion, Josef! We've evaluated this and a SpecKit extension isn't something we're planning to build at this time — we have a lot on our plate and want to stay focused. Closing for now, but feel free to open a new discussion if the community picks up interest.
JosefJezek commentedon Feb 27, 2026
FYI