[Feature]: Expose hook contributions and runtime bindings via specify artifact

[nicolehaugen]

Problem Statement

specify artifact list --json and specify artifact info --json unify preset/extension/built-in provenance for command, template, and script contributions. Hook contributions are not currently exposed through that interface.

The hook domain model already exists internally:

• derive_hook_id produces deterministic IDs in the form {layer}:{sourceId}:hook:{eventName}:{command}.
• _HOOK_LAYERS restricts hooks to preset and extension layers.
• EnhancedManifest.iter_contributions() emits hook declarations with their manifest metadata.
• HookExecutor.get_hooks_for_event() returns every enabled runtime registration for an event, sorted by priority.

The runtime registration state lives in .specify/extensions.yml. Without a JSON introspection surface, consumers must separately parse installed extension manifests and runtime hook configuration, duplicate hook-ID derivation, and reconcile declarations with registrations.

Revised Contract

The original proposal described duplicate hook declarations as replacement layers with one priority-selected winner. Implementation review established that this does not match existing Spec Kit behavior: HookExecutor.register_hooks() preserves entries from different extensions, and get_hooks_for_event() returns every enabled entry. The artifact contract therefore models hooks as additive contributions.

This revision changes only introspection. Hook registration and execution behavior remain unchanged.

Proposed Solution

1. Extend ArtifactKind to include "hook".

2. Include one hook artifact row per unique (eventName, targetCommand) pair in specify artifact list --json and support round-trip lookup with:

hook:{eventName}:{targetCommand}

3. Use this JSON shape:

{
  "id": "hook:before_specify:speckit.compliance.pre-check",
  "name": "before_specify:speckit.compliance.pre-check",
  "kind": "hook",
  "description": "Enforces internal policy checks before specification runs.",
  "eventName": "before_specify",
  "targetCommand": "speckit.compliance.pre-check",
  "registered": true,
  "stack": [
    {
      "id": "hook:before_specify:speckit.compliance.pre-check",
      "layer": "extension",
      "sourceId": "compliance-fast",
      "presetId": null,
      "presetName": null,
      "strategy": "additive",
      "active": true,
      "hidden": false,
      "manifestPath": ".specify/extensions/compliance-fast/extension.yml",
      "lookupId": "extension:compliance-fast:hook:before_specify:speckit.compliance.pre-check",
      "priority": 5,
      "optional": false
    },
    {
      "id": "hook:before_specify:speckit.compliance.pre-check",
      "layer": "extension",
      "sourceId": "compliance-audit",
      "presetId": null,
      "presetName": null,
      "strategy": "additive",
      "active": true,
      "hidden": false,
      "manifestPath": ".specify/extensions/compliance-audit/extension.yml",
      "lookupId": "extension:compliance-audit:hook:before_specify:speckit.compliance.pre-check",
      "priority": 10,
      "optional": true
    }
  ]
}

Field Semantics

• id is the public round-trip shorthand hook:{eventName}:{targetCommand}.
• stack[].lookupId uses the existing derive_hook_id grammar; no new identifier grammar is introduced.
• stack[].strategy is always "additive" because enabled declarations from different extensions all execute.
• stack[].active is true exactly when that declaration matches an enabled runtime registration returned by HookExecutor.get_hooks_for_event(). Multiple entries may be active.
• A runtime registration matches a declaration only when both its extension and concrete command match; a command-less entry does not act as a wildcard.
• stack[].active does not identify a priority winner and does not evaluate the optional event-time condition.
• stack[].hidden is always false; additive hook declarations do not hide one another.
• stack[].priority and stack[].optional describe the contributing manifest declaration. Spec Kit normally copies these defaults into .specify/extensions.yml during registration.
• registered is true when any stack entry is active.
• A declared hook with no matching enabled runtime registration still appears with registered: false.
• Hooks only appear on preset or extension layers; there is no built-in/core hook layer.
• Common stack provenance fields (presetId, presetName, hidden, and manifestPath) are retained.

This source split follows Spec Kit's existing hook model: installed manifests declare hooks and their defaults, while .specify/extensions.yml records project registration and enabled state. Consistent with the shared hook configuration API, an invalid or unreadable .specify/extensions.yml is normalized to an empty hook map, so declarations remain visible with registered: false. Reconciling later manual drift between those files or changing this tolerant runtime behavior is outside this issue.

Error Contract

Hook collection uses the existing artifact error taxonomy:

• Unknown hook shorthand emits the existing unknown artifact envelope.
• Extension-registry or resolver failures that prevent artifact-layer collection emit artifact resolution failed.
• Consistent with existing command, template, and script inventory, an individual manifest that cannot be parsed or validated is omitted; manifest diagnosis remains the responsibility of the preset and extension inspection surfaces.
• Runtime .specify/extensions.yml read and validation failures retain the existing hook behavior and are normalized to an empty registration map.
• Error responses do not leak partial JSON to stdout.

Alternatives Considered

• Separate specify hook command: rejected because hooks are contributions and belong in the unified artifact inventory.
• Winner/replacement model: rejected because it contradicts HookExecutor, which preserves and returns every enabled hook.
• Runtime registrations only: rejected because declared-but-unregistered hooks must remain discoverable.
• Wizard-side manifest parsing: rejected because it duplicates schema and identifier logic outside the CLI.

Component

Specify CLI — artifact catalog, extensions, and JSON contracts.

Use Cases

1. UI and automation consumers can inspect declared hooks, current activation state, and provenance from one CLI contract.
2. Debuggers can show every hook associated with an event and identify which declarations are currently enabled.
3. Reproducibility tooling can identify declared-but-unregistered hooks without independently parsing installed manifests.

Acceptance Criteria

• ArtifactKind includes "hook".
• artifact list --json includes one row per unique (eventName, targetCommand) pair.
• artifact info hook:{eventName}:{targetCommand} --json round-trips.
• Every hook lookupId equals derive_hook_id(layer, sourceId, eventName, targetCommand).
• Hooks only appear on preset and extension layers.
• Every hook stack entry uses strategy: "additive" and hidden: false.
• Every declaration with a matching enabled registration is active: true; duplicate declarations may all be active.
• A command-less runtime binding does not activate a concrete hook declaration.
• Top-level registered equals any(stack[].active).
• Per-entry priority and optional remain visible; no winner-derived top-level values are emitted.
• Common stack fields and declaring manifestPath are retained.
• Declared-but-unregistered hooks remain visible with registered: false.
• Unknown hook shorthand and registry/resolver collection failures preserve the existing artifact error envelopes.
• Invalid individual hook manifests are omitted consistently with other artifact kinds rather than introducing a hook-specific validation failure.
• Invalid or unreadable runtime hook configuration retains the existing hook behavior and reports declarations as unregistered.
• Documentation covers shorthand, additive execution, registration semantics, provenance, and the _HOOK_LAYERS invariant.
• Tests cover additive duplicate handling, independent activation, stable ordering, registration true/false paths, lookup-ID parity, round-trip lookup, provenance, error behavior, and no regression to existing artifact kinds.

Additional Context

The Spec Kit Wizard was the motivating consumer when this issue was opened. Its current main branch has since reorganized the composition implementation, so adopting this revised JSON contract should be handled as a separate downstream change rather than by preserving the superseded winner schema here.

Depends on #4305. Related to #4210 and #4212.

Scope note: Hook execution is unchanged. This issue exposes existing declarations, activation state, and provenance.

[github-actions]

Feature assessment — hook-artifact-exposure · Stage 1/5: Intake

Idea Intake: Expose Hook Contributions via Artifact CLI

• Slug: hook-artifact-exposure
• Created: 2026-08-26
• Source: GitHub issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 (github/spec-kit), labeled feature-assess
• Type: improvement

Idea (as captured)

The specify artifact list --json and specify artifact info --json commands (being introduced in PR #4305) unify preset/extension/built-in provenance for command, template, and script contributions, but deliberately exclude hook contributions. The proposal is to extend ArtifactKind to include "hook", remove the filter that excludes hooks from the stack builder, and serialize hook contributions — including their runtime registered state from .specify/extensions.yml — into the artifact catalog JSON output.

Restated

The feature proposes that specify artifact list --json and specify artifact info --json include hook contributions alongside commands, templates, and scripts, with a registered flag reflecting runtime binding state, so that external consumers (primarily speckit-wizard-canvas) can drop their direct manifest-parsing code and rely solely on the CLI as the source of truth for the composition graph.

Origin & Context

• Raised by: @nicolehaugen
• Trigger: The speckit-wizard-canvas plugin currently re-parses .specify/extensions/*/extension.yml and .specify/extensions.yml directly (~140 lines in composition/hooks.mjs) to get hook metadata — the exact anti-pattern that PR feat: add specify artifact introspection #4305 was introduced to eliminate for commands/templates/scripts. This issue closes the remaining gap.

First-Glance Unknowns

• [NEEDS CLARIFICATION: Is PR feat: add specify artifact introspection #4305 merged yet? This issue is marked as depending on it, and the specify artifact command does not yet exist in the current codebase (confirmed at runtime: specify artifact returns "No such command").]
• [NEEDS CLARIFICATION: What is the expected timeline / priority relative to feat: add specify artifact introspection #4305 landing?]
• [NEEDS CLARIFICATION: Are there consumers beyond speckit-wizard-canvas that would immediately benefit?]
• [NEEDS CLARIFICATION: Does the registered field need to track partial bindings (where .specify/extensions.yml binds an extension for an event but without specifying individual commands)?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4343 · 580 AIC · ⌖ 27.4 AIC · ⊞ 36.5K · ◷

[github-actions]

Feature assessment — hook-artifact-exposure · Stage 2/5: Research

Idea Research: Expose Hook Contributions via Artifact CLI

• Slug: hook-artifact-exposure
• Created: 2026-08-26
• Evidence confidence (overall): high

Users & Demand

• Direct stated consumer: speckit-wizard-canvas (composition/hooks.mjs, ~140 lines) explicitly states in its header comment that it parses manifests directly because the CLI does not surface hook data. This is concrete, acknowledged technical debt — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 body] (confidence: high, cited)
• Secondary consumer need: composition/artifact-cli.mjs:220–366 contains hook-attribution passes that would be removable once the CLI exposes hooks — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 body] (confidence: high, cited)
• Pattern evidence: Issues [Feature]: Add deterministic contribution IDs and stack lookup IDs for resolved artifacts #4210, [Feature]: Add specify artifact command exposing composition stacks as JSON #4212, and PR feat: add specify artifact introspection #4305 were all introduced to eliminate the "consumers reading manifests directly" anti-pattern for other artifact kinds; this issue is the natural fourth extension of that arc — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 references, PR feat: add specify artifact introspection #4305] (confidence: high, cited)
• Future consumers: CI tooling, external UIs, reproducibility tooling named as hypothetical beneficiaries — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 Use Cases] (confidence: medium, assumption — no concrete external consumer named beyond the wizard)

Prior Art

• PR feat: add specify artifact introspection #4305 (open at assessment time): Introduces specify artifact list --json and specify artifact info --json for command, template, script kinds. Hooks deliberately excluded. This is the direct predecessor and dependency — [source: PR feat: add specify artifact introspection #4305] (confidence: high, cited)
• Issue [Feature]: Add deterministic contribution IDs and stack lookup IDs for resolved artifacts #4210: Introduced the stable per-contribution ID scheme that derive_hook_id reuses — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343] (confidence: high, cited)
• Issue [Feature]: Add specify artifact command exposing composition stacks as JSON #4212: Introduced the artifact command itself — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343] (confidence: high, cited)
• _HOOK_LAYERS and derive_hook_id at src/specify_cli/_identifier.py:174, :55 (per issue): The hook ID grammar already exists internally — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 body; file not found in current working tree, likely part of un-merged PR feat: add specify artifact introspection #4305] (confidence: medium, cited with caveat)
• EnhancedManifest.iter_contributions() at src/specify_cli/extensions/__init__.py:795–824 (per issue): Already emits kind:"hook" entries with all required fields — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 body; runtime grep confirmed hook infrastructure at lines 73–5136] (confidence: medium, cited)

Market & Context

• Cost of doing nothing: speckit-wizard-canvas maintains ~140+ lines of bespoke manifest-walking JavaScript duplicating derive_hook_id's grammar. Any manifest schema change requires coordinated updates to both CLI and wizard — a drift risk. — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 body] (confidence: high, cited)
• Alternative today: Direct parsing of .specify/extensions/*/extension.yml and .specify/extensions.yml. Works but is fragile against schema evolution. — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 body] (confidence: high, cited)

Data & Constraints

• Existing hook infrastructure confirmed in current codebase: DEFAULT_HOOK_PRIORITY (line 73), normalize_priority (line 185), coerce_hook_entries (line 207), hook validation (lines 380–537), ExtensionManifest.hooks property (line 724) all present in src/specify_cli/extensions/__init__.py — [source: runtime grep, confidence: high, cited]
• specify artifact command absent in current codebase: Command does not yet exist (specify artifact returns "No such command" at runtime). PR feat: add specify artifact introspection #4305 is the gate — [source: runtime verification, confidence: high, cited]
• Scope: Hook execution runtime is explicitly out of scope — introspection only — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 scope note] (confidence: high, cited)
• registered semantics: Determined by .specify/extensions.yml hooks: map via ExtensionConfig API; partial bindings (extension-level, no command) treat all commands for that event as registered — [source: issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343] (confidence: high, cited)

Evidence Against the Idea

• Hard dependency on un-merged PR feat: add specify artifact introspection #4305: The specify artifact command doesn't exist yet. This issue cannot be implemented until feat: add specify artifact introspection #4305 lands. — (confidence: high, cited)
• Limited concrete consumers today: Beyond speckit-wizard-canvas, no other concrete named consumers identified. The wizard could theoretically adapt its existing parsing rather than requiring a CLI change — though that is acknowledged as the anti-pattern. — (confidence: medium, cited)
• strategy: "replace" is a fixed constant: Slightly asymmetric with other artifact kinds where strategy varies. Not a blocking concern. — (confidence: medium, cited)

Gaps & Open Questions

• [NEEDS CLARIFICATION: PR feat: add specify artifact introspection #4305 must land first — what is its merge timeline?]
• [NEEDS CLARIFICATION: Does _identifier.py (introduced by feat: add specify artifact introspection #4305) already expose derive_hook_id and _HOOK_LAYERS exactly as the issue claims?]
• [NEEDS CLARIFICATION: Are there extensions in production already declaring hooks for regression testing?]

Sources

• Issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 body (github.com, policy: allowlisted)
• PR feat: add specify artifact introspection #4305 (github.com, policy: allowlisted)
• Runtime grep of src/specify_cli/extensions/__init__.py
• Runtime specify artifact --help — confirmed command absence

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4343 · 580 AIC · ⌖ 27.4 AIC · ⊞ 36.5K · ◷

[github-actions]

Feature assessment — hook-artifact-exposure · Stage 3/5: Problem

Problem Definition: Expose Hook Contributions via Artifact CLI

• Slug: hook-artifact-exposure
• Created: 2026-08-26
• Inputs used: intake.md | research.md

Problem Statement

Hook contributions declared by extensions and presets are invisible to the specify artifact CLI surface, forcing external consumers to parse raw extension manifests and the runtime bindings file (.specify/extensions.yml) directly — duplicating internal ID-derivation logic and creating a fragile coupling to schema internals that the CLI is specifically designed to abstract.

Affected Users & Stakeholders

• Users: Developers building on speckit-wizard-canvas and similar tooling — they experience the problem as ~140 lines of bespoke manifest-parsing code that must be kept in sync with CLI internals, and which silently breaks when manifest schemas evolve.
• Users: Any external tool, CI system, or UI wanting a complete composition graph (commands + templates + scripts + hooks) from a single artifact list --json call — currently impossible.
• Stakeholders: Spec Kit maintainers — they carry the risk that diverging schema interpretations between wizard and CLI cause silent bugs for end users.
• Stakeholders: Consumers of the speckit-wizard-canvas "Composition" tab — they experience incorrect or incomplete hook state if the wizard's parsing drifts from the CLI's interpretation.

Goals

• Hooks exposed as first-class artifacts in specify artifact list --json and artifact info --json with the same top-level shape as other kinds plus hook-specific fields (eventName, targetCommand, optional, priority, registered).
• registered flag accurately reflects runtime binding state from .specify/extensions.yml so consumers don't need to read that file.
• stack[].lookupId for hook layers equals derive_hook_id(...) — no new grammar, no re-derivation in consumers.
• speckit-wizard-canvas can delete composition/hooks.mjs and hook-attribution passes in artifact-cli.mjs once this ships.
• specify artifact info hook:{event}:{command} --json round-trip works correctly, including unknown-artifact error shape.

Non-Goals

• Hook execution runtime changes (dispatch, ordering, triggering)
• A separate specify hook command group
• Changes to command, template, or script artifact shapes
• Wizard UI implementation (follow-up in wizard repo)

Success Metrics

• specify artifact list --json output includes all hook contributions from installed presets and extensions (baseline: 0 hook entries today)
• speckit-wizard-canvas deletes composition/hooks.mjs (~140 lines) and associated attribution passes
• No regression in the existing test suite (1132+ tests per PR feat: add specify artifact introspection #4305)
• All 11 acceptance criteria checkboxes in issue [Feature]: Expose hook contributions and runtime bindings via specify artifact #4343 are green

Cost of Inaction

speckit-wizard-canvas continues to maintain fragile direct manifest parsing for hooks while all other artifact kinds are served by the CLI. Any manifest schema change requires coordinated edits in both CLI and wizard, with no type safety or test coverage at the boundary. The Spec Kit "CLI as source of truth" model remains half-finished until hooks are included.

Open Questions

• [NEEDS CLARIFICATION: PR feat: add specify artifact introspection #4305 (the dependency) is currently open — what is its expected merge date?]
• [NEEDS CLARIFICATION: Does _identifier.py (introduced by feat: add specify artifact introspection #4305) already expose derive_hook_id and _HOOK_LAYERS as the issue claims?]
• [NEEDS CLARIFICATION: Are there production extensions that already declare hooks, making regression testing immediately possible?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4343 · 580 AIC · ⌖ 27.4 AIC · ⊞ 36.5K · ◷

[github-actions]

Feature assessment — hook-artifact-exposure · Stage 4/5: Concept

Concept: Expose Hook Contributions via Artifact CLI

• Slug: hook-artifact-exposure
• Created: 2026-08-26
• Recommended option: Option A — Extend artifact catalog with hook kind

Options

Option A — Extend artifact catalog with hook kind

• Sketch: After PR feat: add specify artifact introspection #4305 lands, extend ArtifactKind to include "hook", remove the filter that currently excludes hooks from _iter_pack_candidates, and wire iter_contributions()'s existing kind:"hook" entries into the stack builder with hook-specific serialization fields (eventName, targetCommand, optional, priority, registered). Top-level id uses shorthand hook:{event}:{command}; stack layer lookupId reuses derive_hook_id. The registered flag is a single map lookup against ExtensionConfig's hooks: binding. Add hook:{event}:{command} to the artifact info unknown-artifact error path. Add documentation in docs/reference/artifacts.md.
• Appetite: small (days — the domain model already exists; this is surfacing it through an established pattern)
• Trade-offs: Wins: eliminates hooks.mjs and attribution passes in wizard; makes composition graph complete; no new grammar. Sacrifices: requires feat: add specify artifact introspection #4305 to land first; adds a fixed strategy: "replace" field that is always the same constant (slightly asymmetric with other kinds).
• Rabbit holes: Correctly matching "registered" state when a binding in .specify/extensions.yml omits command (implicit all-commands) vs. when it names a specific command — the matching logic must handle both cases exactly as enable_hooks/disable_hooks do. Diverging here would produce incorrect registered values.

Option B — Separate specify hook list --json command

• Sketch: Add a new top-level specify hook command group with list and info subcommands, independent of specify artifact. Consumers that want hooks call specify hook list --json; consumers that want everything fan out to both commands.
• Appetite: small-medium (new command scaffolding required; same underlying infrastructure)
• Trade-offs: Wins: no change to artifact command surface. Sacrifices: re-fragments the introspection surface that PR feat: add specify artifact introspection #4305 unified; consumers wanting the full composition graph must merge two JSON streams. Explicitly rejected in the issue's Alternatives Considered section.
• Rabbit holes: Maintaining parity between artifact and hook JSON shapes over time; two separate command surfaces to document and test.

Option C — Do nothing / defer until demand grows

• Sketch: Leave hooks absent from the artifact catalog. The wizard continues using hooks.mjs. Document the gap in docs/reference/artifacts.md as a known limitation.
• Appetite: negligible
• Trade-offs: Wins: zero implementation risk. Sacrifices: leaves wizard manifest-parsing debt in place; violates the "CLI as source of truth" principle established by [Feature]: Add deterministic contribution IDs and stack lookup IDs for resolved artifacts #4210–feat: add specify artifact introspection #4305; technical debt grows with adoption.
• Rabbit holes: None.

Recommendation

Option A. The domain model (hook infrastructure, iter_contributions(), derive_hook_id, ExtensionConfig) already exists; the main work is removing a filter and writing a serialization path that mirrors the established pattern for commands/templates/scripts. The issue is tightly specified with exact acceptance criteria, a concrete consumer waiting to delete ~140 lines of fragile code, and no new conceptual surface to design. Option B was explicitly rejected by the issue author for sound architectural reasons. Option C preserves technical debt the project has committed to eliminating.

The only timing constraint: this cannot land until PR #4305 is merged.

Out of Scope (for Option A)

• Hook execution runtime changes
• A separate specify hook command group
• Changes to command, template, or script shapes
• Wizard UI updates
• Hooks on the core (built-in) layer — _HOOK_LAYERS restricts to preset and extension

Assumptions to Validate

• PR feat: add specify artifact introspection #4305 exposes derive_hook_id, _HOOK_LAYERS, and EnhancedManifest.iter_contributions() with kind:"hook" entries as claimed — these are the exact integration points for Option A.
• ExtensionConfig API provides a clean hooks: map lookup without additional infrastructure.
• The implicit-all-commands binding edge case can be replicated from the existing enable_hooks/disable_hooks behavior with a few lines.

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4343 · 580 AIC · ⌖ 27.4 AIC · ⊞ 36.5K · ◷

[github-actions]

Feature assessment — hook-artifact-exposure · Stage 5/5: Decision — verdict go

Decision: Expose Hook Contributions via Artifact CLI

• Slug: hook-artifact-exposure
• Decided: 2026-08-26
• Verdict: go
• Artifacts reviewed: intake.md | research.md | problem.md | concept.md

Scorecard

Criterion	Rating	Justification
Problem validity	strong	Concrete fragile consumer (hooks.mjs, ~140 lines of manifest-parsing) with an acknowledged header comment stating the gap. Problem is real, scoped, and causing active maintenance risk.
Evidence strength	adequate	Direct codebase evidence (hook infrastructure confirmed in extensions/__init__.py), concrete consumer code confirmed by issue author, PR #4305 as cited dependency. Filed by a maintainer with detailed technical evidence including specific line numbers. _identifier.py paths not directly confirmed in working tree (part of un-merged #4305), but issue author's specificity and confirmed hook infrastructure give adequate confidence.
Value vs. inaction	strong	Deletes ~140+ lines of fragile wizard-side manifest parsing, closes the last gap in the "CLI as source of truth" model, and eliminates a drift risk that grows with adoption. Concrete, measurable cleanup.
Feasibility / appetite	strong	Domain model already exists; work is surfacing it through an established pattern. Issue provides precise acceptance criteria and implementation pointers. Estimated small appetite (days). Hard dependency on #4305, which is open and in review.
Strategic fit	strong	Directly continues the trajectory of #4210 → #4212 → #4305 → this issue. Aligns exactly with the stated "CLI as source of truth" principle. No strategic conflicts.
Risk posture	strong	Key risks identified and manageable: (1) #4305 dependency — tracked, in review; (2) implicit-all-commands registered matching edge case — explicitly called out in concept, matches existing enable_hooks/disable_hooks behavior; (3) strategy: "replace" asymmetry — cosmetic, not functional. No unmitigated risk.

Verdict & Rationale

Go. Problem validity is strong, evidence is adequate (direct codebase confirmation of hook infrastructure, concrete named consumer, maintainer-authored request with line-number specificity), value is concrete (measurable code deletion), feasibility is small appetite, strategic fit is exact, and risks are understood and bounded. The only sequencing constraint — PR #4305 must land first — is a normal dependency, not a blocking unknown. The acceptance criteria are complete and testable; the recommended option (Option A) is a narrowly scoped extension of an established pattern with no new design surface.

Handoff to speckit.specify

• Problem: Hook contributions declared by extensions and presets are invisible to specify artifact list/info --json, forcing external consumers to parse raw manifests directly — duplicating internal ID logic and creating fragile schema coupling.
• Chosen approach: Option A — extend ArtifactKind to include "hook", remove the exclusion filter in _iter_pack_candidates, wire iter_contributions()'s kind:"hook" entries into the stack builder, serialize hook-specific fields (eventName, targetCommand, optional, priority, registered), and add artifact info unknown-hook error handling. Reuse derive_hook_id for stack[].lookupId; shorthand hook:{event}:{command} for top-level id.
• In scope: ArtifactKind extension; hook serialization in list and info; registered computation from ExtensionConfig; unknown-artifact error shape for hooks; docs/reference/artifacts.md coverage.
• Out of scope: Hook execution runtime; specify hook command group; changes to other artifact kind shapes; wizard UI updates.
• Success metrics: artifact list --json returns hook entries; speckit-wizard-canvas deletes hooks.mjs; no regression in existing test suite; all 11 acceptance criteria checkboxes green.
• Carried-forward open questions:
  • [NEEDS CLARIFICATION: Confirm PR feat: add specify artifact introspection #4305 exposes derive_hook_id, _HOOK_LAYERS, and EnhancedManifest.iter_contributions() with kind:"hook" entries exactly as claimed — these are the integration points.]
  • [NEEDS CLARIFICATION: Confirm feat: add specify artifact introspection #4305 merge timeline so this issue can be sequenced immediately after.]
  • [NEEDS CLARIFICATION: Are there existing hook-declaring extensions in production for regression testing?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4343 · 580 AIC · ⌖ 27.4 AIC · ⊞ 36.5K · ◷