You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a toolkit consumer, I want versioned and verifiable toolkit distributions, so that projects and teams can consume a known toolkit version reproducibly without copying the entire knowledge base into each repository.
Context
The toolkit already follows a deliberate reference, don't copy strategy for canonical knowledge. At the same time, selected executable assets such as schemas, validators, generators, templates, and adapter support may need to be installed or vendored into downstream projects in a controlled way.
A release distribution should make this boundary explicit. It must package what consumers need for reproducible use while preserving references to canonical human-readable knowledge wherever possible.
Canonical skills remain maintained under skills/. A release may additionally contain generated, portable Agent Skills-compatible projections whose references, assets, scripts, dependencies, and provenance are resolved for installation. These packages are derived release artifacts, not a second manually maintained source of skill truth.
This epic depends on the machine-readable knowledge and skill catalog introduced by #62 and the conformance and evaluation requirements introduced by #65.
Goals
Define an explicit release artifact for the toolkit.
Make releases reproducible, identifiable, and integrity-checkable.
Document which assets are referenced and which assets may be installed or copied.
Publish portable, self-contained skill packages and curated skill bundles where appropriate.
Generate portable packages from canonical skills and catalog metadata instead of maintaining copies manually.
Establish versioning and compatibility rules for catalog, skills, schemas, generators, templates, adapters, bundles, and consumer tooling.
Each release identifies the canonical source path and source revision for every generated portable skill package.
The distribution can include Agent Skills-compatible packages with the expected SKILL.md structure plus required references/, scripts/, and assets/ content.
Portable skill packages are generated deterministically from canonical sources and are never maintained as an independent source tree.
Every portable skill package is self-contained or declares each external dependency explicitly in the catalog and release manifest.
The release build fails when a package contains broken relative references or undeclared dependencies on repository-local files outside the package.
The distribution can publish curated bundles, for example a minimal architecture set, a project-bootstrap set, and an architecture-SDLC set.
Bundle membership and dependency closure are derived from the catalog rather than duplicated in release scripts.
The release records which model-dependent routing or behavioural evaluations were run, their status, and the evaluation metadata version, without making those evaluations a hidden prerequisite for deterministic package creation.
Release assets have published checksums.
The release process is deterministic and covered by automated tests or reproducibility checks.
The distribution clearly separates canonical referenced knowledge, generated portable skill packages, installable executable assets, and engine-specific adapters.
Compatibility rules and semantic versioning expectations are documented.
Breaking changes to skills, schemas, catalog structure, bundle composition, CLI contracts, adapters, or generated output are identifiable.
Consumers can determine which adapters, Agent Skills-compatible runtimes, and execution environments are supported by a release.
GitHub Actions can build and publish the release artifacts from a version tag.
Candidate User Stories
Define the distribution layout and release manifest.
Generate portable Agent Skills-compatible packages from canonical skills.
Resolve and package skill references, scripts, assets, and declared dependencies.
Define minimal architecture, bootstrap, and SDLC skill bundles.
Package schemas, validators, generators, templates, and supported adapters.
As a toolkit consumer, I want versioned and verifiable toolkit distributions, so that projects and teams can consume a known toolkit version reproducibly without copying the entire knowledge base into each repository.
Context
The toolkit already follows a deliberate
reference, don't copystrategy for canonical knowledge. At the same time, selected executable assets such as schemas, validators, generators, templates, and adapter support may need to be installed or vendored into downstream projects in a controlled way.A release distribution should make this boundary explicit. It must package what consumers need for reproducible use while preserving references to canonical human-readable knowledge wherever possible.
Canonical skills remain maintained under
skills/. A release may additionally contain generated, portable Agent Skills-compatible projections whose references, assets, scripts, dependencies, and provenance are resolved for installation. These packages are derived release artifacts, not a second manually maintained source of skill truth.This epic depends on the machine-readable knowledge and skill catalog introduced by #62 and the conformance and evaluation requirements introduced by #65.
Goals
Acceptance Criteria
SKILL.mdstructure plus requiredreferences/,scripts/, andassets/content.Candidate User Stories
Relationship to Other Epics
Out of Scope