[Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle)

[mnriem]

Status: Proposal
Effort: Low–Medium (≈90% assembly of existing primitives)
Priority: High — closes the emit↔ingest loop and makes Spec Kit the portable hub for the skills ecosystem

Summary

Ship a skill-importer bundle that lets a user point Spec Kit at a directory, repo, or URL full of skills — each a SKILL.md together with the scripts, references, assets, and templates it bundles in its enclosing directory — and expose them all as native Spec Kit commands, automatically distributed to whichever of the 41 supported coding agents they use.

The unit of import is the whole skill directory, not just the markdown. A SKILL.md typically references sibling files (scripts/, references/, assets/, templates); the importer must carry those along, and — because bundled scripts are executable content — treat them as a first-class part of the trust surface (see Trust & Compliance).

The capability is mostly assembly of primitives that already exist:

• Extensify (a community-catalog extension) already converts a single skill — a SKILL.md plus every file/subdirectory in its enclosing directory (scripts/, references/, assets/, templates) — into a Spec Kit extension (create-extension-from-skill), and already generates a catalog.json from a directory of extensions (create-catalog), with validate-extension / validate-catalog as QA.
• Core already renders commands → SKILL.md in skills mode (agents.py:render_skill_command, _invocation_style.py) and distributes to all agents via CommandRegistrar.
• Bundles already support provides: {extensions, presets, steps, workflows} (bundler/models/manifest.py: COMPONENT_KINDS).

The only genuinely new work is a bulk discovery step and a workflow that orchestrates the existing commands, packaged as a bundle.

---

Problem Statement

I'm frustrated that widely-used community agent-skills live as raw SKILL.md files spread across separate, independently-maintained repositories, each locked to one or two agents, with no one-step way to bring them into my project and my coding agent. To use them today I copy/fork files by hand, they don't compose with each other, they carry no org context, no versioning, and no quality gate — and the moment upstream changes, my copy drifts.

The deeper motivation is not just "import a file" — it's what a skill becomes once it's a Spec Kit command. Spec Kit already has the composition, distribution, and governance machinery; a raw skill has none of it. Absorbing a SKILL.md into Spec Kit upgrades it from a static, single-agent prompt into a first-class, governed capability:

• Multi-agent portability — rendered to all 41 supported agents via skills mode, not locked to Claude Code.
• Workflow orchestration — the skill becomes a step that can be chained, gated, fanned-out, and sequenced in a Spec Kit workflow.
• Preset layering — org standards, compliance, and conventions overlay the skill via the preset composition algebra (prepend/append/wrap/replace over a named target) — without forking upstream.
• Catalog hosting & distribution — installable via specify extension add, discoverable, shareable through public or private catalogs.
• Governance — organizations vet and host approved skills in private/internal catalogs, with review gates and recorded license + provenance in each extension.yml.
• Versioning — skills become versioned extensions with update/rollback semantics, instead of a floating upstream file that silently drifts.
• Validation / quality gate — validate-extension/validate-catalog enforce a quality bar the raw skill never had.
• Lifecycle-hook activation — skills can be wired to SDD phases (before/after specify, plan, tasks, implement, …) for phase-aware, on-demand activation.
• Reproducibility — tag-pinned, bounded, offline-installable — no dependence on a moving remote file.
• Stable, named contract — the skill becomes a /speckit-<name> command with deterministic invocation and (with the artifact/--json work) introspectable metadata.

This is the "absorb, don't delegate" thesis: Spec Kit doesn't merely coordinate with a skill — it has the skill, wrapped in orchestration, composition, distribution, and governance. That's the value the importer unlocks; the ingest step is just the on-ramp.

---

Motivation

Demand is proven at the very top of GitHub

Cross-referencing GitHub's top-100 most-starred repositories (stars:>114000, assessed 2026-09-10) against confirmed SKILL.md presence and license shows that several of the most-starred repositories on GitHub are now SKILL.md skill collections — instantly-citable, license-clean ingest sources:

⭐	Repo	License	SKILL.md	Fit
284K	obra/superpowers	MIT	14	Flagship methodology skills — golden-path demo
258K	mattpocock/skills	MIT	38	Reputable author, clean structure
255K	affaan-m/ECC	MIT	856	Bulk-import showcase
136K	Shubhamsaboo/awesome-llm-apps	Apache-2.0	9	Curated agent-skills collection
132K	garrytan/gstack	MIT	131	Real-world curated Claude Code setup
126K	nextlevelbuilder/ui-ux-pro-max-skill	MIT	13	Single high-value design skill

Below the top-100 but strong: Fission-AI/OpenSpec (67K, MIT, 16).

License gating is non-negotiable

Two of the highest-profile skill repos cannot be legally ingested/redistributed — the single most important design constraint:

⭐	Repo	SKILL.md	Blocker
175K	anthropics/skills	20	No license (all rights reserved) — canonical Agent Skills, yet un-ingestable
74K	ComposioHQ/awesome-claude-skills	854	No license

The importer must reject NONE/copyleft sources by default and surface the SPDX id, or it ships a legal liability.

Format diversity (SKILL.md-first)

Not all skill content is SKILL.md: f/prompts.chat (prompts/CSV), multica-ai/andrej-karpathy-skills (CLAUDE.md), VoltAgent/awesome-design-md (DESIGN.md), msitarzewski/agency-agents (agent files). SKILL.md is the dominant, canonical format — ship that first; a normalization layer opens the door to others later.

---

What already exists vs. what's new

Capability	Where	Status
SKILL.md (single) → Spec Kit extension/command	Extensify create-extension-from-skill	✅ exists (local path)
Directory of extensions → catalog.json	Extensify create-catalog	✅ exists (bulk)
Validate extension / catalog	Extensify validate-extension / validate-catalog	✅ exists
Command → SKILL.md, render to 41 agents	core CommandRegistrar, skills mode	✅ exists
Bundle carrying extension + workflow + steps + preset	bundler COMPONENT_KINDS	✅ supported
Discover every SKILL.md in a tree	—	❌ new
Fetch a remote source (repo/url) with provenance	—	❌ new
License/compliance gate	—	❌ new
Workflow orchestrating the above	—	❌ new

Net-new code shrinks to: a discovery step, a fetch/license-check step, and a workflow — everything else is reuse.

---

Proposed Solution

1. The workflow (skills-to-catalog)

The workflow is the bulk layer — fan_out/fan_in provide "for every skill" natively, so no new bulk command is required. (Field names below are illustrative, not the final schema.)

workflow:
  id: skills-to-catalog
  steps:
    - id: gather
      type: init
      # inputs: source (dir|repo|url), catalog_url, output_dir

    - id: fetch
      type: shell            # remote clone/download — gated by shell-step opt-in (#2440/#2443)
      when: "{{ source.is_remote }}"
      # provenance: tag-pinned ref only (see #4185); bounded read

    - id: license_gate
      type: gate
      # reject NONE / copyleft SPDX ids unless --allow-license explicitly set

    - id: discover
      type: shell            # NEW: list every SKILL.md under the source tree
      # emits: skills[] — each entry = the SKILL.md AND its enclosing directory (scripts/refs/assets)

    - id: convert
      type: fan_out
      over: "{{ discover.skills }}"
      steps:
        - type: command       # Extensify create-extension-from-skill (per skill)
        - type: command       # Extensify validate-extension
        - type: gate          # drop skills that fail validation

    - id: assemble
      type: fan_in
      steps:
        - type: command       # Extensify create-catalog over generated dirs
        - type: command       # Extensify validate-catalog

    - id: report
      type: gate
      # summary: N imported / M skipped (invalid) / K blocked (license); default output = LOCAL catalog for review

2. The bundle (skill-importer)

# bundle.yml
bundle:
  id: skill-importer
  name: "Skill Importer"
provides:
  extensions: [extensify]              # the convert/catalog/validate commands
  workflows:  [skills-to-catalog]      # the orchestration above
  steps:      [discover-skills]        # the new custom discovery step (if not inlined as shell)
  presets:    [skill-import-defaults]  # optional: strict-validate, output paths, license policy

One specify bundle add skill-importer installs the whole capability.

3. User story

"Here's a repo full of skills — expose them all to Spec Kit and to the agent I use."

specify bundle add skill-importer
specify workflow run skills-to-catalog --source https://github.com/obra/superpowers@<tag>
# → validates + imports the MIT skills, writes a local catalog for review
specify extension catalog add ./catalog.json
specify extension add <skill>            # rendered to Copilot/Claude/Cursor/… via --skills

---

Trust & Compliance Model (the crux)

1. License gate (hard requirement). Read the source repo's SPDX license; reject NONE and copyleft (GPL/AGPL) by default. Surface the license in the import report. Require an explicit --allow-license <spdx> override to proceed. Record provenance + license in each generated extension.yml.
2. Provenance / pinning. Remote sources are fetched by tag-pinned ref only (reuse the download_url tag-pin policy, Community catalog workflows: make tag-pinned download_url a MUST and reject releases/latest/ #4185); no latest/floating refs. Bounded reads throughout.
3. Shell-step opt-in. The fetch/discover shell steps inherit the existing workflow shell-step opt-in gate ([Security hardening] Require explicit opt-in for workflow shell steps #2440/[Security hardening] Require explicit opt-in for shell workflow steps #2443) — no silent code execution.
4. Validate-as-gate. validate-extension / validate-catalog run as mandatory gate steps; invalid/loose-frontmatter skills are flagged and skipped, never silently shipped. Bulk amplifies the loose-format problem, so this gate is essential.
5. Bundled executable content. A skill is imported with its enclosing directory (scripts/, references/, assets/, templates) — which can include executable scripts. Import copies and records these but never runs them; they are size-bounded, surfaced in the import report, and left for explicit review before any use. This is the largest reason the import is a trust boundary, not a plain file copy.
6. Local-first, no auto-install. Default output is a local catalog.json the user reviews; installing to the agent is a separate, explicit step.
7. Attribution. Preserve upstream author/source/license in the generated extension metadata.

---

Fidelity & Limitations

• SKILL.md is a loose format; frontmatter conventions differ across ecosystems (Anthropic, Composio, etc.). The importer normalizes frontmatter but is lossy for execution-harness skills that assume a specific runtime — it imports procedural/prompt content cleanly, harness-coupled skills partially.
• The import unit is the whole skill directory: bundled scripts/, references/, assets/, and templates are carried into the generated extension (and mapped to provides.scripts/provides.templates where applicable). Skills whose scripts assume a specific host/runtime may need manual adjustment after import.
• Bulk conversion of hundreds of skills (e.g. ECC's 856) will surface quality variance — the validate gate + a per-import report set expectations.
• Non-SKILL.md formats (CLAUDE.md, DESIGN.md, agents, prompt CSVs) are out of scope for v1; the normalization layer is the future extension point.

---

Delivery / Phasing

• Phase 1 (v1): discovery step + skills-to-catalog workflow + license/provenance gate, packaged as a community bundle (proving ground, like sicario-spec/specassay). Local-catalog output only.
• Phase 2: remote fetch with tag-pinned provenance; import report; preset defaults.
• Phase 3: promote to first-party bundled (shipped by default, still modular).

Decomposition into Sub-Issues

This is best filed as an umbrella / tracking issue, then delivered through a set of small, tightly-scoped, independently-reviewable sub-issues (and PRs) — consistent with the project's small-PR / mega-PR-breakup norms and the per-filer throttle. Each sub-issue should stand on its own with its own acceptance criteria; none should depend on the whole landing at once. Candidate slices:

1. Bulk skill discovery — a step/utility that lists every SKILL.md under a local tree (no fetch, no convert).
2. skills-to-catalog workflow — orchestrate the existing Extensify commands (fan_out convert → validate gate → fan_in catalog), local sources only.
3. License/compliance gate — read source SPDX, block NONE/copyleft by default, explicit override + recorded acknowledgment; stamp license/provenance into generated extension.yml.
4. Remote fetch with provenance — tag-pinned clone/download as an opt-in shell step, bounded reads.
5. Import report — summarize imported / skipped-invalid / blocked-by-license, default output = local catalog.json for review.
6. skill-importer bundle — the bundle.yml packaging (extension + workflow + optional step/preset).
7. Docs + example corpus — golden-path (obra/superpowers) and bulk (affaan-m/ECC / garrytan/gstack) walkthroughs; cross-platform.
8. First-party promotion — move from community bundle to shipped-by-default (separate, later).
9. (Stretch) format plugins — normalization for CLAUDE.md / agent-file / prompt sources.

Scoping this way keeps each change reviewable, lets the security-sensitive slices (3, 4) get focused review, and allows the low-risk pieces (1, 2, 6, 7) to land independently.

Acceptance Criteria

• specify bundle add skill-importer installs the Extensify extension + the skills-to-catalog workflow (and any custom step/preset it ships).
• Running the workflow against a local source discovers every SKILL.md in the tree and converts each skill directory (the SKILL.md + its bundled scripts//references//assets//templates) to a Spec Kit extension, then validates them.
• Bundled scripts are copied and recorded but never executed during import; they're size-bounded and surfaced in the import report for review.
• Skills that fail validation (loose/invalid frontmatter) are reported and skipped, never written into the catalog.
• Remote sources are fetched only by tag-pinned ref (no floating/latest); bounded reads throughout.
• License gate: unlicensed (NONE) and copyleft sources are blocked by default; proceeding requires an explicit override with a recorded acknowledgment. The source SPDX id and provenance are recorded in each generated extension.yml.
• Default output is a local catalog.json for review — no automatic install to the agent.
• Imported skills render to all supported agents via skills mode (--skills / CommandRegistrar).
• Fetch/discover run as opt-in shell steps (inherit the workflow shell-step gate); no silent code execution.
• Documentation updated; works cross-platform (bash + PowerShell).

Open Questions

• Should the discovery step be a first-class custom step type (reusable) or an inline shell step in the workflow?
• Do we want a thin convenience command (specify skills import <source>) that wraps the workflow, or keep it workflow-only?
• License policy default: hard-block copyleft, or allow with a prominent warning + recorded acknowledgment?

---

Alternatives Considered

• Per-source bridge extensions (the current community pattern). The community catalog already ships bridge extensions that each delegate to one upstream skill source — e.g. superb (Superpowers Bridge), speckit-superpowers-bridge (Superpowers Implementation Bridge), and squad (Squad Bridge). They work, but each couples Spec Kit to a specific upstream tool and must be authored and maintained per source; any source without a bespoke bridge is unreachable. A single generic importer absorbs any SKILL.md source into first-class Spec Kit extensions, so no per-source bridge is needed.
• Manual copy/fork (today's default). Copying skill files by hand gives none of the composition, versioning, validation, or multi-agent distribution above, and drifts from upstream.
• A dedicated bulk specify command instead of a workflow. Rejected for v1: the workflow's fan_out/fan_in already provide the bulk loop, so no new command surface is required (a thin convenience wrapper remains an open question).

---

AI Assistance Disclosure

This issue was researched and drafted with AI assistance — GitHub Copilot (model: Claude Opus 4.8) — and was directed, reviewed, and edited by @mnriem, who understands and endorses the proposal. AI was used for the full initial draft and the supporting research (the top-100 star/license analysis and capability verification); all design decisions and final wording were reviewed by the human maintainer.

[github-actions]

Feature assessment — skill-importer-bundle · Stage 1/5: Intake

Idea Intake: Skill Importer bundle

• Slug: skill-importer-bundle
• Created: 2026-09-11T12:08:08Z
• Source: GitHub issue #4524 (issue body and comments; no comments were present)
• Type: new-capability

Idea (as captured)

Ship a skill-importer bundle that lets a user point Spec Kit at a local directory, repository, or URL containing agent skills. Each import unit is a complete skill directory: its SKILL.md plus sibling scripts/, references/, assets/, and templates. The imported skills should become native Spec Kit commands and be distributed to the user's supported coding agents.

The proposal describes this as an assembly of existing primitives. Extensify can convert one skill directory into an extension, create a catalog from extension directories, and validate extensions and catalogs. Core can render commands as SKILL.md files and distribute them through CommandRegistrar. Bundles can already carry extensions, presets, steps, and workflows. The new pieces proposed are bulk SKILL.md discovery, remote fetching with provenance, license/compliance gating, and an orchestration workflow.

The proposed skills-to-catalog workflow would gather a source, optionally fetch a remote tag-pinned source, apply a license gate, discover every SKILL.md, fan out conversion and validation per skill, fan in catalog creation and validation, and produce an import report. The proposed skill-importer bundle would package the Extensify dependency, workflow, discovery step, and optional defaults.

The trust model is central. Unlicensed and copyleft sources should be rejected by default with an explicit override required. Remote sources should be tag-pinned and bounded. Fetch and discovery shell steps should remain opt-in. Bundled executable files should be copied and recorded but never executed during import, size-bounded, and surfaced for review. Validation failures should be reported and skipped. Output should default to a local catalog for review rather than automatically installing imported skills. Upstream author, source, license, and provenance should be retained.

Version 1 is proposed to support SKILL.md sources and local-catalog output, with later phases for remote fetching, reports/defaults, and first-party promotion. Other formats such as CLAUDE.md, DESIGN.md, agent files, and prompt CSVs are explicitly out of scope for version 1.

Candidate delivery slices are bulk discovery, the local-only workflow, license/compliance gating, remote tag-pinned fetch, import reporting, bundle packaging, documentation/examples, and later first-party promotion. The issue asks whether discovery should be a custom step or inline shell, whether a convenience specify skills import command is needed, and whether copyleft should be hard-blocked or allowed with a warning and acknowledgment.

Acceptance criteria include: installing the bundle; discovering every local SKILL.md and carrying its enclosing directory; never executing bundled scripts; skipping invalid skills; tag-pinning remote sources; blocking NONE and copyleft licenses by default with an explicit recorded override; producing a reviewable local catalog; rendering to supported agents; using opt-in shell steps; documenting cross-platform behavior; and preserving provenance/license metadata.

Restated

The request proposes a reusable, governance-aware way to bulk-ingest complete SKILL.md directories into Spec Kit extensions and catalogs, so users can review and then distribute those skills across supported agents. It combines local and eventually remote discovery with validation, licensing, provenance, and non-execution safeguards.

Origin & Context

• Raised by: @mnriem, the issue author and collaborator
• Trigger: A proposal to close the gap between community skill collections and Spec Kit's existing extension, catalog, bundle, workflow, and multi-agent distribution primitives. The issue reports demand and repository examples, but no separate user interview, support-ticket data, usage telemetry, or stakeholder comments were attached.
• Triggering event: issues: labeled with feature-assess; this assessment is running against the labeled feature request.

First-Glance Unknowns

• [NEEDS CLARIFICATION: What observed user behavior or demand exists beyond the issue author's stated motivation and cited repository examples?]
• [NEEDS CLARIFICATION: Is the target v1 a local-only workflow, or must remote fetching and license provenance land in the first usable release?]
• [NEEDS CLARIFICATION: Which exact Extensify commands and artifact schema are stable enough to depend on, and what is the compatibility/versioning policy?]
• [NEEDS CLARIFICATION: What SPDX license taxonomy is authoritative for detecting copyleft and unlicensed sources, including mixed-license skill directories?]
• [NEEDS CLARIFICATION: What size, file-count, symlink, archive, and path-traversal limits apply to imported skill directories?]
• [NEEDS CLARIFICATION: How should partial failures, duplicate skill names, name collisions, and provenance for each file be represented in the catalog/report?]
• [NEEDS CLARIFICATION: What does “all supported agents” mean when an integration lacks skills mode or when a skill assumes a host-specific runtime?]
• [NEEDS CLARIFICATION: Who owns review and approval of executable files before a generated catalog is installed?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4524 · 267.1 AIC · ⌖ 32.9 AIC · ⊞ 30.5K · ◷

[github-actions]

Feature assessment — skill-importer-bundle · Stage 2/5: Research

Idea Research: Skill Importer bundle

• Slug: skill-importer-bundle
• Created: 2026-09-11T12:08:08Z
• Evidence confidence (overall): low

Users & Demand

• The issue author states that community SKILL.md collections are spread across repositories, often tied to one or two agents, and require manual copying or forking today — source: GitHub issue #4524 (cited statement, low confidence because it is not corroborated by telemetry or user interviews).
• The issue cites several high-star GitHub repositories as potential import sources and reports their skill counts and licenses — source: GitHub issue #4524 (cited claim from the request, low confidence; the counts and licenses were not independently verified in this assessment).
• No comments, support tickets, adoption metrics, failed-install reports, or user interviews were attached to issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524 — source: issue #4524 comments response: none (confidence: high for this issue's evidence boundary).
• Observed conversion demand, repeat-import frequency, acceptable import failure rate, and the number of users who need multi-agent rendering are unknown — [source: repository and issue evidence] (ASSUMPTION, low confidence).

Prior Art

• The repository's community catalog already lists Extensify as a read-write process extension for creating and validating extensions and extension catalogs; the catalog records version 1.1.0, MIT license, five commands, and a requirement of Spec Kit >=0.8.0 — source: extensions/catalog.community.json:1829-1850 (confidence: high, cited).
• The repository documents Extensify as a community extension whose stated purpose is “Create and validate extensions and extension catalogs” — source: docs/community/extensions.md:71 (confidence: high, cited).
• Bundle manifests natively model extensions, presets, steps, and workflows as component kinds, and non-step component references require pinned versions — source: src/specify_cli/bundler/models/manifest.py:18-21, 67-83, 195-205 (confidence: high, cited).
• Bundle resolution enforces the Spec Kit version gate and integration compatibility, and the installer delegates component installation to existing primitive machinery with provenance records — source: src/specify_cli/bundler/services/resolver.py:43-123 and src/specify_cli/bundler/services/installer.py:1-10, 59-87 (confidence: high, cited).
• Workflow support already includes fan-out over a list, fan-in aggregation, command dispatch, shell execution, and review gates — source: src/specify_cli/workflows/steps/fan_out/__init__.py:11-83, fan_in/__init__.py:11-113, command/__init__.py:13-29, shell/__init__.py:15-21, gate/__init__.py:20-33 (confidence: high, cited).
• The existing primitives are adjacent, not an importer: no repository path currently provides create-extension-from-skill, bulk SKILL.md discovery, a license gate, or a skills-to-catalog workflow — [source: repository search for create-extension-from-skill, create-catalog, validate-extension, validate-catalog, and skills-to-catalog] (confidence: medium, cited search result).

Market & Context

• The proposed alternative to an importer is manual copy/fork or source-specific bridge extensions; the issue reports that these approaches do not provide generic composition, versioning, validation, or multi-agent distribution — source: GitHub issue #4524 (confidence: low, cited proposal claim).
• Spec Kit already has a sizable community-extension catalog, including Extensify and other process extensions, so an importer would enter an ecosystem with existing extension discovery and review surfaces rather than an empty market — source: docs/community/extensions.md:50-85 (confidence: high, cited).
• The cost of doing nothing is plausibly continued manual copying and source-specific bridges, but the frequency and severity of that cost are not measured — [source: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524 plus absence of repository telemetry] (ASSUMPTION, low confidence).

Data & Constraints

• The requested import unit includes arbitrary sibling files and executable scripts. The issue requires copying and recording them without executing them and asks for size bounds and review reporting — source: GitHub issue #4524 (confidence: high for the stated requirement; the actual limits are unspecified).
• The workflow engine's shell step executes commands with shell=True, the user's environment, and the project working directory; repository documentation states there is no shell sandbox and that requires.permissions is not a runtime capability gate — source: src/specify_cli/workflows/steps/shell/__init__.py:51-64 and src/specify_cli/workflows/engine.py:74-85 (confidence: high, cited).
• Workflow expression interpolation is plain substitution, and repository documentation warns that unconstrained values flowing into shell commands can become shell syntax — source: docs/reference/workflows.md:603-627 (confidence: high, cited).
• A non-interactive gate pauses when stdin is not a TTY and can be resumed later, so a workflow that requires review must define its CI/resume behavior explicitly — source: src/specify_cli/workflows/steps/gate/__init__.py:20-31 (confidence: high, cited).
• Bundle components other than steps must be version-pinned, but the proposed generated extensions, source refs, license metadata, and per-file provenance do not yet have a defined schema — source: src/specify_cli/bundler/models/manifest.py:195-205 and issue #4524 (confidence: high for the existing rule; low for the proposed schema gap).
• Spec Kit's catalog download/authentication behavior is opt-in and unauthenticated by default unless configured — source: docs/reference/authentication.md:1-29 (confidence: high, cited). The effect on private skill repositories and tag-pinned fetches remains unspecified.
• License classification, mixed-license directories, symlink handling, path traversal protection, archive bounds, duplicate names, and cross-platform executable semantics are open constraints — [source: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524 and repository evidence above] (ASSUMPTION/open gap, low confidence).

Evidence Against the Idea

• Demand evidence is currently a single authored proposal. Without observed usage or a measurable target population, the value case is not strong enough to distinguish a broadly useful importer from a convenience for a small number of maintainers — [source: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524; no comments or telemetry] (confidence: high for the evidence gap).
• The requested “opt-in shell-step” trust boundary is not an existing enforced workflow capability. Shell steps run with user privileges, and permissions is explicitly not a runtime gate — source: src/specify_cli/workflows/engine.py:74-85, src/specify_cli/workflows/steps/shell/__init__.py:51-64, docs/reference/workflows.md:612-627 (confidence: high).
• The proposed bundle would depend on a community, read-write extension. The catalog marks Extensify as unverified, so the importer cannot treat the dependency as an already-governed first-party primitive — source: extensions/catalog.community.json:1829-1850 (confidence: high).
• Bulk import multiplies validation, naming, licensing, provenance, and review failures. The issue gives no bounded failure budget, performance target, or policy for partial catalogs — source: issue #4524 (confidence: high for the omission).
• Remote fetching, executable-content handling, and legal classification could make the security/compliance surface larger than the stated “assembly of primitives”; no evidence yet shows that the smallest local-only version would validate the demand before those risks are accepted — [source: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524 and workflow security documentation] (confidence: medium).

Gaps & Open Questions

• [NEEDS CLARIFICATION: Provide observed user demand: imports attempted, support requests, extension adoption, or interviews, with a target user segment.]
• [NEEDS CLARIFICATION: Define a local-only v1 boundary and decide whether remote fetch is a separate follow-up rather than a prerequisite.]
• [NEEDS CLARIFICATION: Specify the exact Extensify command contract, version pin, maintenance owner, and behavior when the community dependency is unavailable or changes.]
• [NEEDS CLARIFICATION: Define the SPDX policy for NONE, copyleft, mixed-license trees, missing per-file licenses, and explicit override records.]
• [NEEDS CLARIFICATION: Define size/file-count limits, symlink and traversal rules, duplicate-name behavior, generated metadata, and partial-failure semantics.]
• [NEEDS CLARIFICATION: Explain how the required shell-step opt-in is enforced given the current workflow engine's no-sandbox shell primitive.]
• [NEEDS CLARIFICATION: Define what “all supported agents” means for integrations without compatible skills mode and for host-specific runtime assumptions.]

Sources

• [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524 (host: github.com, policy: allowlisted; primary request)
• extensions/catalog.community.json:1829-1850 (host: repository, policy: local source)
• docs/community/extensions.md:71 (host: repository, policy: local source)
• src/specify_cli/bundler/models/manifest.py:18-21, 67-83, 195-205 (host: repository, policy: local source)
• src/specify_cli/bundler/services/resolver.py:43-123 (host: repository, policy: local source)
• src/specify_cli/bundler/services/installer.py:59-87 (host: repository, policy: local source)
• src/specify_cli/workflows/steps/fan_out/__init__.py, fan_in/__init__.py, command/__init__.py, shell/__init__.py, gate/__init__.py (host: repository, policy: local source)
• src/specify_cli/workflows/engine.py:74-85 (host: repository, policy: local source)
• docs/reference/workflows.md:603-627 (host: repository, policy: local source)
• docs/reference/authentication.md:1-29 (host: repository, policy: local source)

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4524 · 267.1 AIC · ⌖ 32.9 AIC · ⊞ 30.5K · ◷

[github-actions]

Feature assessment — skill-importer-bundle · Stage 3/5: Problem

Problem Definition: Skill Importer bundle

• Slug: skill-importer-bundle
• Created: 2026-09-11T12:08:08Z
• Inputs used: intake.md and research.md

Problem Statement

Spec Kit users who find useful agent skills in independently maintained repositories cannot currently bring those skills into a governed, reviewable, and portable project workflow without manual copying, source-specific bridges, or accepting drift. The problem is made more consequential when a skill directory contains executable or license-sensitive content: users need a dependable way to understand what they are adopting and what risks remain before they distribute it to agents.

Affected Users & Stakeholders

• Users: Spec Kit adopters who work with third-party SKILL.md collections — they face manual effort, uncertain completeness, portability gaps, and upstream drift (research: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524; confidence low).
• Users: Organizations curating approved agent capabilities — they need reviewable provenance, licensing information, and predictable boundaries for imported content (research: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524; confidence low).
• Stakeholders: Spec Kit maintainers — they own the trust boundary, compatibility expectations, and long-term maintenance cost (research: repository bundler/workflow primitives; confidence high).
• Stakeholders: Extension and catalog maintainers — they are affected by the quality, naming, versioning, and validation of new imported artifacts (research: docs/community/extensions.md and bundler manifest model; confidence high).
• Stakeholders: Coding-agent integration maintainers — they are affected by claims of portability across supported agents and by host-specific skill assumptions (research: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524; confidence low).
• Stakeholders: Legal/security reviewers — they are affected by unlicensed, copyleft, executable, malicious, or otherwise unreviewed content (research: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524 and workflow security documentation; confidence high for the risk category).

Goals

• Reduce the manual work required to move a complete skill directory from a known source into a project-managed capability.
• Make the imported content, provenance, license status, validation status, and review state understandable before adoption.
• Prevent silent loss of skill files and make invalid or unsupported content visible rather than implicitly trusted.
• Preserve a predictable path from an approved source to usable capabilities across the project's supported agent integrations.
• Establish measurable safety and quality boundaries for executable content, source retrieval, licensing, path handling, and partial failure.

Non-Goals

• Supporting non-SKILL.md formats such as CLAUDE.md, DESIGN.md, agent files, or prompt CSVs in the initial scope (intake: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524).
• Executing scripts, templates, or other bundled source content as part of adoption or review (intake: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524).
• Automatically installing imported content into an agent without an explicit review/adoption decision (intake: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524).
• Making a judgment about the legal acceptability of every license without an explicit policy owner and defined classification rules.
• Promoting the capability to a first-party, default-shipped feature before a separate readiness decision (intake: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524).
• Solving every agent host's runtime incompatibility or converting skills that depend on a host-specific execution environment (intake: issue [Feature]: Skill Importer bundle — ingest any SKILL.md into Spec Kit (Extensify workflow + bundle) #4524).

Success Metrics

• Time to reviewed adoption: measure the median elapsed time from a source being selected to a reviewer having a complete, usable catalog/report; baseline: unknown.
• Completeness: percentage of eligible SKILL.md directories whose required files are represented in the reviewed result; baseline: unknown.
• Safety invariant: number of bundled source files executed during import/review; target: zero; baseline: unknown.
• Transparency: percentage of accepted entries with source, revision, license status, and validation outcome recorded; target: 100%; baseline: unknown.
• Failure visibility: percentage of invalid, blocked, duplicate, or unsupported entries surfaced with a reason; target: 100%; baseline: unknown.
• Portability: percentage of accepted skills that render or are explicitly classified as unsupported for each selected integration; baseline: unknown.
• Demand validation: number of independent users or teams who complete the reviewed adoption flow and repeat it; baseline: unknown.

Cost of Inaction

Users continue to copy skills manually or maintain source-specific bridges, increasing drift and repeated maintenance. Organizations may adopt bundled scripts or license-sensitive content without a consistent review record, while Spec Kit's existing extension, catalog, bundle, and multi-agent primitives remain disconnected from a growing skill ecosystem. The scale of this cost is not currently measured.

Open Questions

• [NEEDS CLARIFICATION: What observed demand, target user segment, and repeat-use threshold justify solving this problem?]
• [NEEDS CLARIFICATION: What is the smallest initial boundary: local sources only, or local plus remote sources and provenance?]
• [NEEDS CLARIFICATION: Which component owns license classification, and how are mixed-license directories and explicit overrides recorded?]
• [NEEDS CLARIFICATION: What exact limits and policies govern files, symlinks, paths, archives, duplicates, executable bits, and partial failure?]
• [NEEDS CLARIFICATION: How can a required shell-step opt-in be enforced when the current workflow shell primitive is not sandboxed or permission-gated?]
• [NEEDS CLARIFICATION: What portability contract applies to integrations without skills mode or to skills with host-specific runtime assumptions?]
• [NEEDS CLARIFICATION: Who reviews and approves imported executable content, and what evidence is sufficient to mark an entry adoptable?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4524 · 267.1 AIC · ⌖ 32.9 AIC · ⊞ 30.5K · ◷

[github-actions]

Feature assessment — skill-importer-bundle · Stage 4/5: Concept

Concept: Skill Importer bundle

• Slug: skill-importer-bundle
• Created: 2026-09-11T12:08:08Z
• Recommended option: Option A — Local-first reviewed importer pilot

Options

Option A — Local-first reviewed importer pilot

• Sketch: Let a user select a local skill tree, discover complete SKILL.md directories, and produce a reviewable local result with per-skill validation, provenance, license status, and explicit skipped/blocked reasons. Start with local inputs and a deliberately narrow SKILL.md contract; adoption into an agent remains a separate user decision. The pilot should prove demand and safety before adding remote retrieval or first-party distribution claims.
• Appetite: medium
• Trade-offs: It tests the core user value with a smaller trust boundary and avoids making remote fetching part of the first release. It does not immediately serve users whose skills live only in remote repositories, and it still needs a credible non-execution and license policy. The existing Extensify dependency and the current workflow shell model remain compatibility risks.
• Rabbit holes: Treating every sibling file as portable; defining mixed-license semantics; supporting host-specific runtime assumptions; resolving duplicate names; promising universal agent compatibility; turning a pilot into a general package manager.

Option B — Full remote, governed skill supply chain

• Sketch: Offer a complete source-to-adoption flow for local and tag-pinned remote repositories, with license/compliance decisions, bounded retrieval, provenance, validation, import reporting, catalog generation, and multi-agent distribution as one governed capability.
• Appetite: large
• Trade-offs: It most closely matches the issue's strategic vision and could create the strongest long-term portability and governance value. It also combines the highest-risk concerns before demand is measured: remote content retrieval, executable files, legal classification, dependency stability, workflow shell safety, and cross-platform behavior.
• Rabbit holes: Building a license database, remote repository client, archive and symlink policy, approval workflow, rollback/update semantics, per-file provenance, large-tree performance, and compatibility adapters for every agent.

Option C — Continue with manual adoption and source-specific bridges

• Sketch: Do not add a generic importer now. Keep using existing extension/catalog/bundle primitives, manual copying, and community bridges for sources that justify dedicated maintenance. Revisit a generic flow when repeated demand or operational pain is demonstrated.
• Appetite: small
• Trade-offs: It avoids new security, legal, and maintenance surface and preserves focus on existing primitives. It leaves the reported manual effort, drift, and source-specific maintenance in place and provides no generic path for unrepresented skill sources.
• Rabbit holes: Repeated bridge duplication, inconsistent quality gates, and fragmented provenance policies across independently maintained extensions.

Recommendation

Recommend Option A — Local-first reviewed importer pilot, conditional on resolving the evidence and safety gaps before a go decision. It offers the smallest boundary that can test the stated value: completeness, transparent failure handling, provenance/license visibility, and a zero-execution invariant. It also gives maintainers a way to measure repeat use and time to reviewed adoption before committing to remote fetching, broad agent claims, or first-party promotion. Option A should not be treated as ready for specification until the demand signal and the current workflow shell-step mismatch are clarified.

Out of Scope (for the recommended option)

• Remote repository or URL fetching, including tag-pinning and network authentication.
• Automatic installation or update tracking for imported skills.
• Non-SKILL.md input formats.
• Execution, testing, or sandboxing of imported scripts or templates.
• A universal guarantee that every imported skill works on every supported agent.
• First-party/default shipping and a general-purpose skill package manager.
• Final legal approval of licenses without an explicitly owned policy.

Assumptions to Validate

• At least one independent Spec Kit user or team will use a local importer pilot and repeat the flow if it is safe and reviewable.
• Extensify's skill conversion and catalog validation contracts are stable, version-pinnable, and maintained for the pilot's lifetime.
• A local-only flow can preserve the complete enclosing skill directory without executing or silently dropping files.
• License detection and provenance can be made sufficiently explicit for review without claiming legal advice or universal license correctness.
• The workflow runtime can enforce or avoid the proposed shell-step trust boundary; the current documented no-sandbox shell behavior is otherwise a blocker.
• Imported skills can be classified honestly when their content assumes a host-specific runtime or lacks portable agent semantics.

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4524 · 267.1 AIC · ⌖ 32.9 AIC · ⊞ 30.5K · ◷

[github-actions]

Feature assessment — skill-importer-bundle · Stage 5/5: Decision — verdict needs-clarification

Decision: Skill Importer bundle

• Slug: skill-importer-bundle
• Decided: 2026-09-11T12:08:08Z
• Verdict: needs-clarification
• Artifacts reviewed: intake.md, research.md, problem.md, concept.md

Scorecard

Criterion	Rating	Justification
Problem validity	adequate	The issue describes a coherent problem around manual skill copying, drift, portability, and unreviewed bundled content, but independent user evidence is absent.
Evidence strength	weak	The evidence is one authored proposal plus repository capability inspection; there is no observed usage, telemetry, support signal, or interview evidence.
Value vs. inaction	unknown	Manual bridges and copying are plausible costs, but their frequency, severity, and effect on adoption are unmeasured.
Feasibility / appetite	weak	Existing bundle and workflow primitives support parts of the concept, but the proposed trust boundary conflicts with the documented unsandboxed shell model and the conversion dependency is an unverified community extension.
Strategic fit	adequate	A governed importer aligns with existing extension, catalog, bundle, workflow, and multi-agent distribution primitives; project-level strategic priorities and constitution evidence were not available.
Risk posture	weak	The request identifies important risks, but license classification, executable-content handling, path/file bounds, provenance, partial failure, and shell opt-in enforcement are not yet resolved.

Verdict & Rationale

Needs clarification. The idea is coherent and a local-first concept could plausibly test meaningful value, so the evidence does not justify killing it. However, the decision gate requires evidence strength of adequate or better for a go verdict, and the current evidence is weak. In addition, the concept depends on resolving a material security mismatch: the current workflow shell primitive runs with user privileges and is not permission-gated, while the proposal treats shell fetch/discovery as an opt-in trust boundary. The request should return to research and shape, with targeted problem clarification, before /speckit.specify receives it.

If needs-clarification

• Blocking questions:
  • [NEEDS CLARIFICATION: What independent user demand supports this capability? Provide observed imports, support requests, adoption data, or interviews and identify the target segment.]
  • [NEEDS CLARIFICATION: Is a local-only reviewed pilot sufficient for v1, with remote fetching explicitly deferred?]
  • [NEEDS CLARIFICATION: How will the workflow enforce the required shell-step opt-in despite the current unsandboxed, user-privileged shell execution model?]
  • [NEEDS CLARIFICATION: What exact Extensify contract and pinned version are supported, and who owns compatibility when that community dependency changes or is unavailable?]
  • [NEEDS CLARIFICATION: What are the license, mixed-license, provenance, symlink, path, size, duplicate, and partial-failure policies?]
  • [NEEDS CLARIFICATION: What portability guarantee is intended for integrations without skills mode or skills with host-specific runtime assumptions?]
  • [NEEDS CLARIFICATION: Who reviews executable content and what evidence changes an imported entry from discovered to adoptable?]
    +- Revisit stage: research for demand and dependency/security evidence; shape for a bounded local-first concept; define for owners, baselines, and measurable thresholds.

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for issue #4524 · 267.1 AIC · ⌖ 32.9 AIC · ⊞ 30.5K · ◷