Skip to content

[EPIC] Publish the toolkit as a versioned consumable distribution #63

Description

@dieterbaier

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.
  • Require published skill packages to satisfy the applicable conformance checks from [EPIC] Establish Agent Skills conformance and evaluation #65.
  • Support both human users and automated consumers.

Acceptance Criteria

  • Tagged releases produce downloadable release artifacts, for example ZIP and/or TAR archives.
  • Each release contains a manifest with toolkit version, commit SHA, build timestamp, catalog version, and included asset versions.
  • Each release includes the generated knowledge and skill catalog from [EPIC] Publish a machine-readable knowledge and skill catalog #62.
  • 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.
  • Portable skill packages and bundles pass the required structural conformance checks from [EPIC] Establish Agent Skills conformance and evaluation #65 before publication.
  • 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.
  • Validate package self-containment and conformance through [EPIC] Establish Agent Skills conformance and evaluation #65.
  • Publish checksums and provenance information.
  • Document semantic versioning and compatibility guarantees.
  • Automate release creation through GitHub Actions.
  • Verify that a release can be consumed without relying on mutable branch content.
  • Verify that generated portable packages can be reproduced from the tagged canonical sources.

Relationship to Other Epics

Out of Scope

  • Selecting and installing assets into a downstream repository; that belongs to the consumer CLI epic.
  • Duplicating the complete human-readable knowledge base into every consumer repository.
  • Maintaining portable skill packages manually alongside canonical skills.
  • Replacing Git references or published documentation as the canonical source of knowledge.
  • Defining the complete conformance and evaluation framework; that belongs to [EPIC] Establish Agent Skills conformance and evaluation #65.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions