[Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON

[nicolehaugen]

Problem Statement

Consumers of SpecKit sometimes need "the baseline set of commands, templates, and scripts baked into SpecKit itself — what a project has with zero presets and zero extensions installed." Command names are already enumerable via CORE_COMMAND_NAMES at extensions/__init__.py:119 — and, importantly, this is not a static list. It's populated by _load_core_command_names() at extensions/__init__.py:78-108, which already dynamically scans core_pack/commands (wheel-time) or templates/commands (source checkout) at import time, using the canonical _locate_core_pack() / _repo_root() asset resolvers. Current commands in the baseline (from that scan): analyze, checklist, clarify, constitution, converge, implement, plan, specify, tasks, taskstoissues.

There is no equivalent scan for the shipped templates or scripts, so consumers who want the baseline have to either:

1. Enumerate the filesystem directly (fragile — internal directory layout isn't a stable contract), or
2. Maintain their own hardcoded list. speckit-wizard-canvas does exactly this — composition/collect.mjs::loadCoreInventory imports pipeline/canonical.mjs, which is a hand-maintained copy of what SpecKit ships. Every SpecKit release risks drift.

A companion issue (specify artifact info --json, filed separately) already surfaces core as layer: "core" rows inside each artifact's stack, but that's a per-artifact view. For "what does a bare-bones SpecKit look like?" a consumer needs an inventory view too.

Proposed Solution

Add a specify core inventory --json command that returns the full baseline inventory:

{
  "commands": [
    { "id": "core:_:command:speckit.plan",
      "name": "speckit.plan",
      "description": "…",
      "sourcePath": "<internal-path-relative-to-package>",
      "artifact": "specs/{feature}/plan.md",
      "optional": false,
      "handoffs": [ "…" ] }
  ],
  "templates": [
    { "id": "core:_:template:constitution",
      "name": "constitution",
      "description": "…",
      "sourcePath": "…" }
  ],
  "scripts": [
    { "id": "core:_:script:setup",
      "name": "setup",
      "description": "…",
      "sourcePath": "…",
      "runtimes": ["bash", "powershell", "python"] }
  ]
}

The entry shape mirrors the per-contribution schema returned by the companion preset info --json / extension info --json issue, minus strategy (core is always the base layer). Under the hood the command:

• Reuses CORE_COMMAND_NAMES for the command list.
• Extends the existing file-scan pattern used by _load_core_command_names() — same _locate_core_pack() + _repo_root() canonical asset resolvers — to scan core_pack/templates and core_pack/scripts (with the equivalent source-checkout fallbacks under templates/ and scripts/). No new asset-discovery paths.
• Runs a small frontmatter parser over the enumerated command / template markdown files (and reads script headers), extracting name / description / artifact / optional / handoffs / (script) runtimes, and emits the JSON.
• Uses the same stable-id scheme (core:_:kind:name) as the companion specify artifact issue so consumers can join this output to that command's layer: "core" stack rows via lookupId.

Alternatives Considered

• Fold entirely into the companion specify artifact command's layer: "core" rows. Rejected — that command gives per-artifact stacks; this one gives the flat inventory needed for "here's what you get out of the box" listings. Both views point at the same data with the same id.
• Return only names (no description / sourcePath / handoffs). Rejected — the wizard's pipeline/canonical.mjs needs the metadata, which is why it exists in the first place.
• Ship the inventory as a static JSON file inside the package. Rejected — still requires the wizard to know the package path; a CLI command is more stable.

Component

Specify CLI (initialization, commands)

AI Agent (if applicable)

Not applicable

Use Cases

1. speckit-wizard-canvas deletes pipeline/canonical.mjs and replaces composition/collect.mjs::loadCoreInventory with JSON.parse(execFileSync("specify", ["core", "inventory", "--json"])).
2. A "SpecKit tour" UI shows first-time users exactly which commands / templates / scripts they get with zero installs.
3. A CI check asserts "no preset is shadowing a core artifact I depend on" by cross-referencing this inventory with the companion specify artifact info --json stacks and the companion preset list --json installed set.

Acceptance Criteria

• specify core inventory --json emits {commands, templates, scripts} arrays; each entry has id, name, description, sourcePath, and the kind-specific fields (artifact/optional/handoffs on commands, runtimes on scripts).
• id values follow the core:_:kind:name scheme (matching the stable-id scheme used by the companion specify preset info --json / specify extension info --json / specify artifact info --json commands) so consumers can join this inventory to those commands' output via lookupId.
• Command list is populated from CORE_COMMAND_NAMES; template and script lists come from a scan that reuses the existing _locate_core_pack() / _repo_root() canonical asset resolvers — not Path(__file__) arithmetic. (Path-arithmetic discovery has silently broken in this codebase once already; see refactor: move extension command handlers to extensions/_commands.py (PR-7/8) #3014 / Bug: extensions core-command discovery is dead — off-by-one paths after the #3014 module move #3274.) No filesystem paths outside the package leak into the output.
• Deterministic: same SpecKit version always produces identical output (stable order + stable ids).
• Non-zero exit + stderr JSON error on packaging problems (missing shipped file, malformed frontmatter).
• Tests: enumeration parity with CORE_COMMAND_NAMES for commands; count parity with the shipped file set for templates/scripts; lookupId cross-reference with the companion specify artifact info --json output on a bare-bones project.
• Docs: new specify core inventory section in the CLI reference plus a note that it complements the companion specify artifact command.

Additional Context

Direct replacement for plugins/spec-kit-copilot-wizard/extensions/speckit-wizard-canvas/pipeline/canonical.mjs and composition/collect.mjs::loadCoreInventory in github/spec-kit-copilot. Depends on the companion "stable id / lookupId" issue; benefits from the companion "artifact/optional/handoffs" issue.

[github-actions]

Feature assessment — core-inventory-command · Stage 1/5: Intake

Idea Intake: Add specify core inventory command

• Slug: core-inventory-command
• Created: 2026-08-19
• Source: GitHub issue [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215 (github/spec-kit), raised by @nicolehaugen
• Type: new-capability

Idea (as captured)

Add a specify core inventory --json command that returns the full baseline inventory of Spec Kit's built-in commands, templates, and scripts as structured JSON. Each entry carries id, name, description, sourcePath, and kind-specific fields (artifact/optional/handoffs for commands, runtimes for scripts). The id values follow a core:_:kind:name scheme matching a companion stable-id design so consumers can join this output to per-artifact stack rows. The command reuses existing asset resolvers (_locate_core_pack() / _repo_root()) and the already-dynamic CORE_COMMAND_NAMES scan.

Motivation: speckit-wizard-canvas (in github/spec-kit-copilot) maintains a hand-written pipeline/canonical.mjs copy of everything Spec Kit ships. Each Spec Kit release risks drift. The new command would let the wizard call execFileSync("specify", ["core", "inventory", "--json"]) and delete the manual copy.

Use cases:

1. Wizard canvas deletes pipeline/canonical.mjs and replaces loadCoreInventory with a CLI call.
2. A "SpecKit tour" UI shows first-time users what zero-extension installs give them.
3. A CI check cross-references this inventory with specify artifact info --json and specify preset list --json to assert no preset shadows a core artifact.

Restated

Spec Kit currently has no CLI surface for querying its own baseline (core) inventory of commands, templates, and scripts as machine-readable JSON, forcing downstream tools to maintain fragile hardcoded copies. The proposal is to add specify core inventory --json that dynamically scans and serializes the core assets using existing, proven asset-resolver infrastructure.

Origin & Context

• Raised by: @nicolehaugen
• Trigger: Drift risk between hand-maintained pipeline/canonical.mjs in speckit-wizard-canvas and the actual Spec Kit release contents; also mentioned as a building block for companion specify artifact info --json / specify preset info --json / specify extension info --json commands (filed as separate issues).

First-Glance Unknowns

• [NEEDS CLARIFICATION: Do the companion commands (specify artifact info --json, specify preset info --json, specify extension info --json) exist yet, or are they themselves future work? The cross-reference acceptance criterion depends on them.]
• [NEEDS CLARIFICATION: Is speckit-wizard-canvas the only known consumer that would benefit immediately, or are there others?]
• [NEEDS CLARIFICATION: What is the exact stable-id scheme specification? The issue sketches core:_:kind:name but the governing spec lives in a separate issue.]
• [NEEDS CLARIFICATION: Should the command be added under an existing specify core sub-command group, or does that group need to be created?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4215 · 487 AIC · ⌖ 22.6 AIC · ⊞ 38K · ◷

[github-actions]

Feature assessment — core-inventory-command · Stage 2/5: Research

Idea Research: Add specify core inventory command

• Slug: core-inventory-command
• Created: 2026-08-19
• Evidence confidence (overall): high

Users & Demand

• speckit-wizard-canvas / speckit-copilot team — The issue explicitly names github/spec-kit-copilot's pipeline/canonical.mjs as a hand-maintained hardcoded copy of Spec Kit's core asset list; every Spec Kit release risks drift. This is a documented, named real consumer actively suffering the problem. — [source: issue [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215 body] (confidence: high, cited)
• CI pipeline authors — The third use case in the issue (asserting no preset shadows a core artifact) describes a CI check pattern that requires cross-referencing this inventory with other specify output. This is plausible but hypothetical for now. — [source: issue [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215 body] (confidence: low, assumption)
• "SpecKit tour" UI — A first-time user onboarding view that shows bundled commands/templates/scripts. Plausible developer-experience product; not tied to a named in-flight project. — [source: issue [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215 body] (confidence: low, assumption)

Prior Art

• CORE_COMMAND_NAMES + _load_core_command_names() — Already exists at src/specify_cli/extensions/__init__.py:78–119. Dynamically scans core_pack/commands (wheel install) or templates/commands (source checkout) using _locate_core_pack() / _repo_root() canonical resolvers. — [source: codebase scan] (confidence: high, cited)
• _FALLBACK_CORE_COMMAND_NAMES — Hardcoded fallback frozenset of 10 names (analyze, checklist, clarify, constitution, converge, implement, plan, specify, tasks, taskstoissues) at extensions/__init__.py:48–60. This is the exact artifact the wizard maintains externally. — [source: codebase scan] (confidence: high, cited)
• _locate_core_pack() / _repo_root() — Canonical asset resolvers at src/specify_cli/_assets.py:13,30. Already used by multiple subsystems. The issue explicitly calls for reusing these rather than Path(__file__) arithmetic (which silently broke during the refactor: move extension command handlers to extensions/_commands.py (PR-7/8) #3014 module move, fixed in Bug: extensions core-command discovery is dead — off-by-one paths after the #3014 module move #3274). — [source: codebase scan + issue [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215] (confidence: high, cited)
• specify preset info — Exists in src/specify_cli/presets/_commands.py:461, but as a human-readable display command without --json output. The companion --json flag mentioned in the issue does not yet exist. — [source: codebase scan] (confidence: high, cited)
• specify extension info --json — No CLI surface found. Extension registry has get_extension_info() internally. — [source: codebase scan] (confidence: high, cited)
• Companion specify artifact info --json — No implementation found in codebase. Referenced as "filed separately" — planned, not shipped. The acceptance criterion cross-referencing this output is contingent on future work. — [source: codebase scan] (confidence: high, cited)
• specify core subcommand group — No existing core subcommand group found in src/specify_cli/commands/. Creating it is a prerequisite. — [source: codebase scan] (confidence: high, cited)
• templates/commands/ — Contains 10 .md files matching _FALLBACK_CORE_COMMAND_NAMES exactly. — [source: codebase scan] (confidence: high, cited)
• scripts/bash/, scripts/python/, scripts/powershell/ — Present with 6 scripts each runtime. Multi-runtime script variants exist. — [source: codebase scan] (confidence: high, cited)

Market & Context

• Alternative (current): Downstream tools enumerate the filesystem directly or maintain hardcoded lists. speckit-wizard-canvas takes the latter approach and already experiences the fragility. — [source: issue [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215] (confidence: high, cited)
• Cost of doing nothing: Every Spec Kit release that adds or renames a core command, template, or script requires a manual update to pipeline/canonical.mjs in a separate repo. This is a known, active maintenance burden. — [source: issue [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215] (confidence: high, cited)

Data & Constraints

• No new asset-discovery paths required: Reuses _locate_core_pack() / _repo_root(). File counts are small (≤15 files per category). — [source: codebase scan] (confidence: high, cited)
• Stable-id scheme dependency: The core:_:kind:name id format is tied to a companion "stable id / lookupId" issue. If that scheme changes, the id format here must match. — [source: issue [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215] (confidence: medium, cited)
• Companion commands not yet shipped: The specify artifact info --json cross-reference acceptance criterion cannot be satisfied today. This is a deferred test, not a blocker for the command itself. — [source: codebase scan] (confidence: high, cited)

Evidence Against the Idea

• Scope creep via companion dependency chain: The issue acknowledges it "depends on the companion stable id / lookupId issue." If those slip, some acceptance criteria are harder to fulfill — but the core command's functionality does not technically require them. The dependency is on test/doc criteria, not on the command itself.
• Narrow immediate consumer base: Only one concrete consumer (speckit-wizard-canvas) is named. The "tour UI" and "CI check" use cases are speculative. For an internal CLI tool, one concrete named consumer is a reasonable justification.
• specify core group creation adds surface area: A new CLI subcommand group is a permanent API commitment. If later features don't materialize to populate it, the group becomes a one-command stub.

Gaps & Open Questions

• [NEEDS CLARIFICATION: Do the companion commands have committed timelines? The cross-reference acceptance criterion depends on them.]
• [NEEDS CLARIFICATION: Is the stable-id scheme (core:_:kind:name) formally decided?]
• [NEEDS CLARIFICATION: Should specify core inventory live under a new specify core group, or under a flatter name?]
• [NEEDS CLARIFICATION: Does the speckit-wizard-canvas team own/sponsor this work?]

Sources

• [Feature]: Add specify core inventory command exposing the baked-in commands, templates, and scripts as JSON #4215 (host: github.com, policy: allowlisted)
• Codebase: src/specify_cli/extensions/__init__.py (local scan)
• Codebase: src/specify_cli/_assets.py (local scan)
• Codebase: src/specify_cli/presets/_commands.py (local scan)
• Codebase: src/specify_cli/extensions/_commands.py (local scan)
• Codebase: templates/commands/, templates/, scripts/ (local scan)

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4215 · 487 AIC · ⌖ 22.6 AIC · ⊞ 38K · ◷

[github-actions]

Feature assessment — core-inventory-command · Stage 3/5: Problem

Problem Definition: Core Asset Inventory Gap in Specify CLI

• Slug: core-inventory-command
• Created: 2026-08-19
• Inputs used: intake.md | research.md

Problem Statement

The Specify CLI ships a fixed baseline of commands, templates, and scripts ("core assets") but provides no machine-readable interface to enumerate them, forcing downstream tools to maintain fragile, hand-written copies that drift with every Spec Kit release.

Affected Users & Stakeholders

• Users: Tool authors and integrators (e.g., speckit-wizard-canvas maintainers) who need a stable, programmatic list of what Spec Kit ships out of the box — affected by silent drift when Spec Kit adds, renames, or removes core assets without updating external copies.
• Users: CI pipeline authors who want to assert compositional invariants (e.g., "no preset shadows a core command I depend on") — currently have no CLI surface to drive such checks.
• Stakeholders: Spec Kit maintainers — bear the maintenance burden of keeping external copies aligned and must coordinate with consumers on every breaking change to core asset names.
• Stakeholders: github/spec-kit-copilot team — directly owns the pipeline/canonical.mjs file that this command would replace.

Goals

• Expose a stable, machine-readable CLI command (specify core inventory --json) that returns the full baseline inventory of core commands, templates, and scripts.
• Eliminate the need for downstream tools to enumerate the Spec Kit filesystem or maintain hardcoded copies of core asset lists.
• Produce output whose id values are join-compatible with companion per-artifact and per-preset/extension output (once those commands exist).
• Reuse existing, tested asset-discovery infrastructure so discovery doesn't silently break on future module moves.

Non-Goals

• Exposing extension-installed or preset-installed assets (those are a separate per-artifact concern).
• Implementing the companion specify artifact info --json, specify preset info --json, or specify extension info --json commands — those are separate issues.
• Providing a human-readable display format (only --json is required by the stated use cases).
• Authoring the formal stable-id scheme specification (that is a companion issue; this command implements it).

Success Metrics

• speckit-wizard-canvas successfully replaces pipeline/canonical.mjs and loadCoreInventory with a specify core inventory --json call, with zero post-migration drift incidents (baseline: infinite drift risk today).
• specify core inventory --json output is deterministic: same Spec Kit version always produces byte-identical output (baseline: no such output exists today).
• Command, template, and script counts in the JSON output match the actual shipped file counts (baseline: fallback set has 10 commands; verifiable against filesystem).

Cost of Inaction

speckit-wizard-canvas continues to maintain a hand-written pipeline/canonical.mjs that must be manually updated with each Spec Kit release. Every missed update causes the wizard to present stale or incorrect data about available commands, templates, and scripts. As the core asset set grows, the synchronization burden increases and the surface for silent drift widens.

Open Questions

• [NEEDS CLARIFICATION: Are the companion commands (specify artifact info --json, specify preset info --json, specify extension info --json) committed and on what timeline? The cross-reference acceptance criterion depends on them.]
• [NEEDS CLARIFICATION: Is the core:_:kind:name stable-id scheme formally decided, or is it under active discussion?]
• [NEEDS CLARIFICATION: Should the command live under a new specify core subcommand group, or at a flatter level to avoid premature group commitment?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4215 · 487 AIC · ⌖ 22.6 AIC · ⊞ 38K · ◷

[github-actions]

Feature assessment — core-inventory-command · Stage 4/5: Concept

Concept: Core Asset Inventory Command

• Slug: core-inventory-command
• Created: 2026-08-19
• Recommended option: Option A — specify core inventory --json using existing resolvers

Options

Option A — specify core inventory --json (as proposed)

• Sketch: Add a specify core subcommand group with an inventory subcommand. The command calls _locate_core_pack() / _repo_root() (already used by _load_core_command_names()) to locate the commands, templates, and scripts directories, then scans and serializes them to JSON. Command entries use CORE_COMMAND_NAMES (or the same scan) for the name list; frontmatter is parsed from each .md to extract description, artifact, optional, and handoffs. Template entries similarly parse frontmatter. Script entries enumerate each runtime subdirectory (bash/, powershell/, python/) and record which runtimes ship a given script. Output uses core:_:kind:name stable ids. The command exits non-zero on packaging problems (missing shipped file, malformed frontmatter).
• Appetite: medium (weeks) — most infrastructure exists; the new work is wiring a new command group, the frontmatter parser over templates and scripts, and the JSON output shape.
• Trade-offs: Wins: eliminates drift risk for speckit-wizard-canvas, follows established patterns in the codebase, aligns with companion issue family. Risks: the specify core group is a permanent API commitment; the stable-id scheme is not yet formally published; companion cross-reference test cannot be written until companion commands exist.
• Rabbit holes: Frontmatter parsing across 15+ files must handle malformed/missing fields gracefully. Deciding on the exact runtimes field for scripts requires agreeing on which subdirectory naming convention is canonical. Creating specify core as a group now may leave it as a one-command group for some time.

Option B — Defer to a specify info --core flag on a future specify info meta-command

• Sketch: Wait for the companion --json commands to land and design a unified specify info meta-command that surfaces all layers including core. Core inventory would be a filter/mode of that command rather than a standalone.
• Appetite: large (months) — depends on companion commands landing first; no relief for speckit-wizard-canvas in the near term.
• Trade-offs: Wins: avoids premature API surface; produces a more coherent CLI design. Risks: blocks the named concrete consumer on an uncertain timeline.
• Rabbit holes: The unified design space is large; designing it before companion commands exist will produce premature abstractions.

Option C — Ship as an internal helper, not a stable CLI command

• Sketch: Add a hidden specify _core-inventory or expose a Python function importable by speckit-wizard-canvas directly via package import rather than subprocess.
• Appetite: small (days) — no stable CLI contract or stable-id requirement.
• Trade-offs: Wins: smallest scope. Risks: forces the wizard to take a Python import dependency on Specify CLI internals (fragile); doesn't serve the CI check use case; doesn't deliver the stable-id join capability.
• Rabbit holes: "Internal" helpers have a habit of becoming informal public APIs.

Recommendation

Option A. This is the right call because there is one concrete, named consumer (speckit-wizard-canvas) with a real, documented pain point today; the implementation reuses proven infrastructure; and Option B delays relief with no near-term benefit while Option C creates fragile import coupling.

The specify core group creation is a modest but real API commitment that should be made with the understanding that companion subcommands will populate it over time.

The cross-reference acceptance criterion should be deferred to when specify artifact info --json lands — it is an integration test, not part of the core command.

Out of Scope (for the recommended option)

• Companion specify artifact info --json, specify preset info --json, specify extension info --json commands.
• Cross-reference integration tests between this command and companion commands (deferred).
• Human-readable (non-JSON) display output.
• Exposing extension- or preset-installed assets.
• Formal stable-id scheme specification (this command implements a scheme; the spec lives in the companion issue).

Assumptions to Validate

• The core:_:kind:name stable-id format will be accepted or any divergence is minor enough to be a non-breaking output change.
• Frontmatter in the existing templates/commands/*.md files contains consistently structured description, artifact, optional, and handoffs fields (or those fields are known to be optional/absent for some commands).
• The scripts/bash/, scripts/python/, scripts/powershell/ directory naming convention is canonical and stable.
• speckit-wizard-canvas can be updated to use the CLI call without blocking on other dependencies.

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4215 · 487 AIC · ⌖ 22.6 AIC · ⊞ 38K · ◷

[github-actions]

Feature assessment — core-inventory-command · Stage 5/5: Decision — verdict go

Verdict: go — specify core inventory --json is ready to hand off to /speckit-specify.

---

Decision: Core Asset Inventory Command

• Slug: core-inventory-command
• Decided: 2026-08-19
• Verdict: go
• Artifacts reviewed: intake.md | research.md | problem.md | concept.md

Scorecard

Criterion	Rating	Justification
Problem validity	strong	Real, named consumer (speckit-wizard-canvas) actively maintains a hand-written copy that drifts with each Spec Kit release. The problem is documented, specific, and already causing maintenance burden.
Evidence strength	adequate	Codebase scan confirms the implementation path (existing resolvers, file counts, fallback set). One concrete consumer is named. Speculative use cases marked accordingly. No invented evidence.
Value vs. inaction	strong	Without this command, speckit-wizard-canvas bears indefinite synchronization burden. The fix eliminates an entire class of drift bugs for a zero-change-on-their-side migration once the command ships.
Feasibility / appetite	strong	The hard part (asset discovery) already exists and is tested. New work is wiring a command group, a frontmatter parser, and a JSON serializer — medium appetite (weeks), credible scope.
Strategic fit	strong	Follows the direction of the companion --json output family; reuses existing resolver infrastructure explicitly designed to be reused; aligns with the documented concern about Path(__file__) arithmetic breaking (#3014/#3274).
Risk posture	adequate	Key risks identified: premature specify core group commitment, stable-id scheme not yet formally published, companion cross-reference test deferred. None are blockers. The command delivers primary value independently of companion commands.

Verdict & Rationale

Go. The problem is real and well-evidenced, the implementation path is clear and conservative (reuses proven infrastructure), and there is a named, concrete consumer ready to migrate. Evidence strength clears adequate — codebase facts are cited directly from scans. A shaped concept (Option A) exists with credible appetite. The two open items (stable-id scheme formalization, companion cross-reference test) are deferred scope, not blockers; the command delivers its primary value — eliminating drift for speckit-wizard-canvas — independently of those.

The main risk is the specify core group becoming a one-command stub for some time. This is acceptable given the stated intent to populate it with companion commands, and given that the alternative (defer everything) blocks a named consumer with no benefit.

Handoff to /speckit-specify

• Problem: The Specify CLI has no machine-readable interface to enumerate its baseline (core) commands, templates, and scripts, forcing downstream tools to maintain fragile hardcoded copies that drift with each release.
• Chosen approach: Add specify core inventory --json under a new specify core subcommand group, scanning core assets using the existing _locate_core_pack() / _repo_root() resolvers, parsing frontmatter from command/template markdown files, enumerating script runtimes, and emitting structured JSON with core:_:kind:name stable ids.
• In scope: specify core inventory --json command; {commands, templates, scripts} JSON arrays; id, name, description, sourcePath, and kind-specific fields; deterministic output; non-zero exit on packaging errors; unit tests for enumeration parity and determinism; CLI reference documentation.
• Out of scope: Companion specify artifact info --json / specify preset info --json / specify extension info --json; cross-reference integration tests (deferred); human-readable display output; extension/preset assets.
• Success metrics: speckit-wizard-canvas migrates off pipeline/canonical.mjs; output is deterministic across versions; command/template/script counts match shipped file counts.
• Carried-forward open questions:
  • [NEEDS CLARIFICATION: Confirm the core:_:kind:name stable-id scheme is accepted by the companion stable-id issue before finalizing output shape.]
  • [NEEDS CLARIFICATION: Confirm frontmatter field coverage (artifact, optional, handoffs) across all 10 command templates — some may not carry all fields.]
  • [NEEDS CLARIFICATION: Whether specify core is the right group name, or whether specify inventory / specify core-inventory is preferred to avoid premature group commitment.]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4215 · 487 AIC · ⌖ 22.6 AIC · ⊞ 38K · ◷