[Feature]: Agent Package Manager Support

Problem Statement

We have started using speckit at work but the major issue we have is a consistent way to manage extensions and presets in a extensible way thats easy to manage so that we can have a library of skills that can be used to initialize a new repository, or add skills from a library to an existing repo.

The current format for creating extensions seems limited.

All we need is a recommended way to host an internal library of agents that can be added to a speckit project after its setup.

Proposed Solution

If APM https://microsoft.github.io/apm/consumer/ is going to become a standard then could this be supported or is their another way this can be supported.

Another solution would be ok as long as it works in a similar way.

Alternatives Considered

No response

Component

Agent integrations (command files, workflows)

AI Agent (if applicable)

No response

Use Cases

Companies with multiple internal teams how want to make a library of internal agents available.

Acceptance Criteria

A new speckit setup can be initialised with a list of extensions and presets form a library based on a configuration file setup in the repository.

Additional Context

No response

AI Disclosure

N/A

@psanderson-da

@psanderson-da You are aware of our catalog support for each of our primitives where you can host your own?

Feature assessment — agent-package-manager · Stage 1/5: Intake

Idea Intake: Agent Package Manager Support

Slug: agent-package-manager
Created: 2026-10-15T13:41:15Z
Source: GitHub issue [Feature]: Agent Package Manager Support #4965 (labeled feature-assess)
Type: new-capability

Idea (as captured)

We have started using speckit at work but the major issue we have is a consistent way to manage extensions and presets in a extensible way thats easy to manage so that we can have a library of skills that can be used to initialize a new repository, or add skills from a library to an existing repo.

The current format for creating extensions seems limited.

All we need is a recommended way to host an internal library of agents that can be added to a speckit project after its setup.

If APM (microsoft.github.io/redacted) is going to become a standard then could this be supported or is their another way this can be supported.

Another solution would be ok as long as it works in a similar way.

Use case: Companies with multiple internal teams want to make a library of internal agents available.

Acceptance criterion: A new speckit setup can be initialised with a list of extensions and presets from a library based on a configuration file setup in the repository.

The issue also identifies “Agent integrations (command files, workflows)” as the component and includes one follow-up comment asking whether the requester is aware of the existing catalog support for primitives.

The linked APM URL is recorded but not fetched: [UNVERIFIED — fetch skipped: host not on safe list: microsoft.github.io]. Sanitized URL: (microsoft.github.io/redacted) host: microsoft.github.io; policy branch: auto-refused: host not on safe list`.

Restated

Organizations want a repeatable, centrally managed way to distribute internally maintained agent skills, extensions, and presets into both newly initialized and already existing Spec Kit repositories. The proposal asks whether APM or a similar mechanism could provide repository-configured package selection and installation.

Origin & Context

Raised by: psanderson-da, in GitHub issue [Feature]: Agent Package Manager Support #4965
Trigger: Reported workplace adoption friction and a request for a consistent internal library/distribution mechanism; exact scale and current workflow are [NEEDS CLARIFICATION].

First-Glance Unknowns

[NEEDS CLARIFICATION: Which package types must be supported first: extensions, presets, bundles, standalone skills, or all of them?]
[NEEDS CLARIFICATION: Is the desired library private, public, or both, and what authentication/access controls are required?]
[NEEDS CLARIFICATION: What does the current workflow fail to provide despite the existing default and community catalogs?]
[NEEDS CLARIFICATION: Must initialization be reproducible/offline and version-pinned, including transitive dependencies?]
[NEEDS CLARIFICATION: What APM interoperability, if any, is required beyond a similar user experience?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4965 · copilot · gpt52codex · 3.89 AIC · ⌖ 0.688 AIC · ⊞ 24.4K · ◷

Feature assessment — agent-package-manager · Stage 2/5: Research

Idea Research: Agent Package Manager Support

Slug: agent-package-manager
Created: 2026-10-15T13:41:15Z
Evidence confidence (overall): medium

Users & Demand

The requester reports a workplace need for a shared internal library used by multiple teams — [source: GitHub issue [Feature]: Agent Package Manager Support #4965] (confidence: medium; stated demand, not observed usage).
The issue names one use case: companies with multiple internal teams making internal agents available — [source: GitHub issue [Feature]: Agent Package Manager Support #4965] (confidence: medium).
No usage telemetry, number of teams, support volume, or additional customer reports were available in the issue or its single comment — [UNVERIFIED] (confidence: high).

Prior Art

Spec Kit already supports modular extensions intended to integrate external tools, automate tasks, customize workflows, and share solutions; the user guide describes independent versioning and catalog search/install flows — [source: extensions/EXTENSION-USER-GUIDE.md] (confidence: high).
The current extension user guide documents installing from a catalog, URL, or local development directory, plus automatic agent skill registration for skills-based integrations — [source: extensions/EXTENSION-USER-GUIDE.md] (confidence: high).
The repository has a first-party extension catalog and a separate community extension catalog, indicating an existing public distribution path — [source: extensions/catalog.json, extensions/catalog.community.json] (confidence: high).
Presets also have a community catalog with version, compatibility, download, documentation, and provided-component metadata — [source: presets/catalog.community.json] (confidence: high).
The publishing guide says community extensions are submitted through an issue and then reviewed/validated before a generated catalog pull request, while maintainers do not audit extension code — [source: extensions/EXTENSION-PUBLISHING-GUIDE.md] (confidence: high).
The issue's linked APM page was not fetched because microsoft.github.io is outside the assessment URL allowlist — [UNVERIFIED — fetch skipped: host not on safe list: microsoft.github.io] (confidence: high).

Market & Context

Today, teams can use the documented catalog, URL, or local installation paths; an internal library would need to add an organization-controlled distribution/configuration layer rather than replace the existing extension package format — [source: extensions/EXTENSION-USER-GUIDE.md] (confidence: high).
The cost of doing nothing is continued manual coordination for organizations with internal packages and possible inconsistency between new initialization and later repository setup — [source: GitHub issue [Feature]: Agent Package Manager Support #4965] (confidence: medium; reported impact, not measured).
Whether APM is an adopted standard, and whether users need interoperability rather than a Spec Kit-native registry, remains [UNVERIFIED] because the linked page was not fetched (confidence: high).

Data & Constraints

Existing extension manifests include Spec Kit version requirements, command inventories, tags, repository, license, and release metadata; any library mechanism must preserve compatibility and provenance checks already expected by the publishing guide — [source: extensions/EXTENSION-PUBLISHING-GUIDE.md] (confidence: high).
Existing catalogs are JSON documents with explicit schema/version and catalog URLs; the repository demonstrates separate first-party/community catalog boundaries — [source: extensions/catalog.json, extensions/catalog.community.json, presets/catalog.community.json] (confidence: high).
Private-library authentication, package signing/integrity, update policy, dependency resolution, and offline behavior are not specified — [NEEDS CLARIFICATION] (confidence: high).

Evidence Against the Idea

The repository already provides catalogs plus install-from-URL and local development workflows, so the proposed capability may overlap with existing mechanisms; the incremental gap is not yet demonstrated — [source: extensions/EXTENSION-USER-GUIDE.md, GitHub issue [Feature]: Agent Package Manager Support #4965] (confidence: high).
The request has one stated organization/use case and no measured adoption or failure data, so demand breadth is uncertain — [source: GitHub issue [Feature]: Agent Package Manager Support #4965] (confidence: medium).
Supporting multiple package types, private registries, authentication, pinning, and APM compatibility could materially expand scope beyond a simple configuration file — [source: issue acceptance criteria and existing catalog metadata] (confidence: medium).

Gaps & Open Questions

[NEEDS CLARIFICATION: What exact workflow is missing from current catalog support?]
[NEEDS CLARIFICATION: What package types and dependency relationships must a repository configuration select?]
[NEEDS CLARIFICATION: What private-hosting, authentication, trust, signing, and version-pinning requirements apply?]
[NEEDS CLARIFICATION: What measurable setup-time, consistency, or adoption improvement defines success?]
[NEEDS CLARIFICATION: Is APM a hard compatibility requirement or only an example of the desired experience?]

Sources

GitHub issue [Feature]: Agent Package Manager Support #4965 and its comment (repository-local issue context; host: github.com, policy: allowlisted)
extensions/EXTENSION-USER-GUIDE.md (repository source)
extensions/EXTENSION-PUBLISHING-GUIDE.md (repository source)
extensions/catalog.json (repository source)
extensions/catalog.community.json (repository source)
presets/catalog.community.json (repository source)
`(microsoft.github.io/redacted) (host: microsoft.github.io, policy: auto-refused: host not on safe list)

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4965 · copilot · gpt52codex · 3.89 AIC · ⌖ 0.688 AIC · ⊞ 24.4K · ◷

Feature assessment — agent-package-manager · Stage 3/5: Problem

Problem Definition: Agent Package Manager Support

Slug: agent-package-manager
Created: 2026-10-15T13:41:15Z
Inputs used: intake.md and research.md

Problem Statement

Organizations using Spec Kit across multiple internal teams lack a demonstrated, repeatable way to declare and distribute a trusted set of internal agent capabilities for both new and existing repositories. The resulting setup process may be inconsistent or manual, but the scale, failure modes, and impact are not yet measured.

Affected Users & Stakeholders

Users: Teams adopting Spec Kit inside an organization — may need to discover and install the same internal capabilities across repositories.
Users: Repository maintainers — may need consistent setup after initialization and predictable package versions.
Stakeholders: Internal platform or developer-experience teams — may own the library, compatibility policy, and distribution process [NEEDS CLARIFICATION].
Stakeholders: Spec Kit maintainers — decide how any capability aligns with existing catalogs and package boundaries.

Goals

Make the desired internal capabilities discoverable and repeatably provisionable for new and existing Spec Kit repositories.
Reduce manual coordination and configuration drift between repositories, if those costs are confirmed.
Preserve clear package identity, compatibility, provenance, and version expectations.
Establish a measurable way to determine whether setup consistency and effort improve.

Non-Goals

Choosing APM as the implementation or standard before its required interoperability is clarified.
Replacing the existing public/community catalog model without evidence that it cannot serve the need.
Designing package formats, APIs, registry infrastructure, or dependency algorithms at this stage.
Auditing the contents or security of every internal agent package.

Success Metrics

A repository configuration can reproduce the required internal capability set for a new repository and an existing repository (baseline: unknown).
Median setup effort/time and number of manual steps for the target workflow decrease (baseline: unknown).
Repeated setups converge on the same package versions and package types (baseline: unknown).
Adoption and failure rate among the requesting organization/team(s) are measured after rollout (baseline: unknown).

Cost of Inaction

Teams may continue using a mixture of catalog, URL, and local installation paths, with manual instructions and possible drift between repositories. The magnitude of that cost is unknown; existing catalog support may already cover part of the request.

Open Questions

[NEEDS CLARIFICATION: What current workflow and measured pain make existing catalogs insufficient?]
[NEEDS CLARIFICATION: Which package types are in scope and what is the minimum viable internal library?]
[NEEDS CLARIFICATION: What are the private registry, authentication, integrity, offline, and version-pinning requirements?]
[NEEDS CLARIFICATION: What baseline and target values should be used for setup time, manual steps, consistency, and failures?]
[NEEDS CLARIFICATION: Is APM compatibility required or merely illustrative?]

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4965 · copilot · gpt52codex · 3.89 AIC · ⌖ 0.688 AIC · ⊞ 24.4K · ◷

Feature assessment — agent-package-manager · Stage 4/5: Concept

Concept: Agent Package Manager Support

Slug: agent-package-manager
Created: 2026-10-15T13:41:15Z
Recommended option: none

Options

Option A — Repository Capability Manifest

Sketch: Let a repository declare a set of named, version-constrained Spec Kit packages or capabilities in a checked-in configuration, then use the existing catalog/install mechanisms to bring that set into new or existing repositories.
Appetite: medium
Trade-offs: Wins reproducible onboarding and a familiar repository-owned workflow; sacrifices centralized policy and may duplicate existing catalog configuration. Risks ambiguity across extensions, presets, bundles, and standalone skills.
Rabbit holes: Dependency ordering, lockfiles, private sources, credentials, integrity verification, upgrades, rollback, and behavior when packages conflict.

Option B — Organization-Hosted Catalog

Sketch: Allow an organization to publish a private catalog compatible with Spec Kit's existing catalog concepts, so teams can discover and install approved internal packages through a controlled source.
Appetite: medium
Trade-offs: Wins centralized ownership, discoverability, and policy control; sacrifices simplicity and introduces hosting, authentication, trust, and availability concerns. It may solve distribution without solving one-command initialization.
Rabbit holes: Catalog protocol/versioning, auth providers, package signing, private downloads, access scoping, mirroring, and support for every package type.

Option C — Use Existing Catalog/URL Workflows

Sketch: Do not add a package-manager capability; document how an organization can maintain a private or mirrored catalog where supported, or use versioned package URLs and repository setup automation around the current install commands.
Appetite: small
Trade-offs: Wins speed and avoids overlapping mechanisms; sacrifices a unified first-class experience and may leave the reported manual coordination unresolved.
Rabbit holes: Private hosting details, drift in scripts, undocumented assumptions, and limitations of current catalog visibility or initialization.

Recommendation

Do not recommend a build option yet. Option A or B could address the stated goal, while Option C may already cover much of it, but the evidence does not establish the gap between current catalog/install support and the requested workflow. The decisive questions are the exact missing behavior, package scope, private distribution requirements, and measurable baseline. Under the assessment gate, this should return to research/define before committing to a concept.

Out of Scope (for the recommended option)

No detailed package schema, registry API, authentication implementation, lockfile format, or installer design.
No commitment to APM interoperability.
No replacement of existing public/community catalogs.
No broad expansion to every agent ecosystem until the minimum package set is known.

Assumptions to Validate

The requester needs capabilities beyond the existing catalog, URL, and local development installation paths.
A checked-in configuration is acceptable for declaring organization-approved packages.
Internal packages can expose stable identity, compatibility, and version metadata.
The organization can define trust and access requirements for its library.
Setup consistency and effort can be measured with a representative pilot.

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4965 · copilot · gpt52codex · 3.89 AIC · ⌖ 0.688 AIC · ⊞ 24.4K · ◷

Feature assessment — agent-package-manager · Stage 5/5: Decision — verdict needs-clarification

Decision: Agent Package Manager Support

Slug: agent-package-manager
Decided: 2026-10-15T13:41:15Z
Verdict: needs-clarification
Artifacts reviewed: intake.md | research.md | problem.md | concept.md

Scorecard

Criterion	Rating	Justification
Problem validity	adequate	A workplace adoption problem and multi-team use case are stated, but the current failure mode and impact are not measured.
Evidence strength	weak	The request has one reporter and repository evidence of existing catalogs/install paths, but no usage data, interviews, or validated APM requirement.
Value vs. inaction	unknown	Consistency and manual effort may be costly, but baselines and target improvements are unknown; existing mechanisms may already cover the need.
Feasibility / appetite	adequate	A repository manifest or organization catalog is conceptually plausible, but private distribution, trust, and dependency scope could expand the appetite.
Strategic fit	adequate	The request concerns extensions, presets, and agent integrations, which are existing Spec Kit primitives and documented distribution surfaces.
Risk posture	weak	Major scope and security/trust questions are identified but not yet answered or mitigated.

Verdict & Rationale

Needs clarification. The problem is plausible and aligned with existing Spec Kit primitives, but the evidence is too thin for a go: the issue does not show why current catalogs, URL installs, or local development installs are insufficient, and the desired package scope and private-library constraints are undefined. Revisit research and define with a concrete current workflow, baseline measurements, target package set, and explicit APM interoperability requirement (if any); then reshape the concept.

If needs-clarification

Blocking questions:
- [NEEDS CLARIFICATION: Which current catalog/install workflow fails, and what manual steps or drift does it cause?]
- [NEEDS CLARIFICATION: Which package types must be selected and installed: extensions, presets, bundles, standalone skills, or a subset?]
- [NEEDS CLARIFICATION: Is the library private, what authentication and integrity guarantees are required, and must it work offline?]
- [NEEDS CLARIFICATION: Is APM compatibility mandatory or only an example of the desired user experience?]
- [NEEDS CLARIFICATION: What are baseline and target values for setup time, manual steps, consistency, adoption, and failure rate?]
  +- Revisit stage: research | define | shape

Generated by 💡 Assess a Feature Request by Installing and Running Spec Kit for #4965 · copilot · gpt52codex · 3.89 AIC · ⌖ 0.688 AIC · ⊞ 24.4K · ◷

3. @psanderson-da You are aware of our catalog support for each of our primitives where you can host your own?

Is this https://github.github.com/spec-kit/reference/bundles.html#manage-catalog-sources ? That might work, didn't realise that had been added.

apm is still worth keeping an eye on though, especially if it becomes popular.

[Feature]: Agent Package Manager Support #4965

Description

Problem Statement

Proposed Solution

Alternatives Considered

Component

AI Agent (if applicable)

Use Cases

Acceptance Criteria

Additional Context

AI Disclosure

Activity

mnriem commented on Oct 15, 2026

github-actions commented on Oct 15, 2026

Idea Intake: Agent Package Manager Support

Idea (as captured)

Restated

Origin & Context

First-Glance Unknowns

github-actions commented on Oct 15, 2026

Idea Research: Agent Package Manager Support

Users & Demand

Prior Art

Market & Context

Data & Constraints

Evidence Against the Idea

Gaps & Open Questions

Sources

github-actions commented on Oct 15, 2026

Problem Definition: Agent Package Manager Support

Problem Statement

Affected Users & Stakeholders

Goals

Non-Goals

Success Metrics

Cost of Inaction

Open Questions

github-actions commented on Oct 15, 2026

Concept: Agent Package Manager Support

Options

Option A — Repository Capability Manifest

Option B — Organization-Hosted Catalog

Option C — Use Existing Catalog/URL Workflows

Recommendation

Out of Scope (for the recommended option)

Assumptions to Validate

github-actions commented on Oct 15, 2026

Decision: Agent Package Manager Support

Scorecard

Verdict & Rationale

If needs-clarification

psanderson-da commented on Oct 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions