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 an architect or toolkit consumer, I want a coherent catalog of the toolkit's architecture knowledge, skills, templates, schemas, generators, and adapters, so that both humans and automated tools can discover, understand, and use the available capabilities.
Context
The repository already acts as a Git-based knowledge library. Its content is useful for human architecture work and can also be consumed by AI agents and other tooling. What is still missing is one stable, machine-readable catalog that exposes the available assets without replacing their human-readable source documents.
The catalog must therefore support two equally important usage modes:
human architects browsing and selecting guidance, methods, skills, templates, and examples;
tools and AI agents discovering suitable assets, metadata, relations, and executable capabilities.
Human-readable architecture knowledge remains canonical. Machine-readable catalog entries describe and link to that knowledge rather than turning the toolkit into an AI-only protocol.
For skills, the catalog is also the metadata source for portable Agent Skills-compatible projections, task-oriented routing, starter bundles, conformance checks, and evaluation fixtures. It must describe how a skill is discovered and composed without duplicating the canonical instructions in SKILL.md.
Goals
Define a catalog model covering at least skills, contracts, templates, schemas, generators, adapters, examples, and relevant documentation assets.
Generate a deterministic catalog from canonical repository metadata.
Make catalog entries useful to both human-facing documentation and automated consumers.
Preserve stable IDs and relations across releases.
Expose enough metadata for discovery without duplicating canonical knowledge content.
Describe portable skill capabilities, compatibility, package policy, and composition metadata.
Support task-oriented routing and curated skill bundles without hard-coding them independently in multiple consumers.
Validate catalog completeness and consistency during the build.
Acceptance Criteria
A documented catalog schema exists.
The build generates a deterministic machine-readable catalog, initially as JSON or YAML.
Every catalog entry has a stable ID, asset type, title, description, canonical source location, and lifecycle status.
Relevant entries can declare relations, dependencies, supported tasks, required inputs, and produced outputs.
Skill entries can declare an Agent Skills-compatible profile or standard version, invocation mode, role or workflow category, runtime compatibility, and package policy.
Skill entries distinguish canonical guidance from generated portable packages, executable assets, references, adapters, and optional runtime-specific metadata.
Skill dependencies identify whether they are bundled, referenced externally, generated, installed, or optional.
As an architect or toolkit consumer, I want a coherent catalog of the toolkit's architecture knowledge, skills, templates, schemas, generators, and adapters, so that both humans and automated tools can discover, understand, and use the available capabilities.
Context
The repository already acts as a Git-based knowledge library. Its content is useful for human architecture work and can also be consumed by AI agents and other tooling. What is still missing is one stable, machine-readable catalog that exposes the available assets without replacing their human-readable source documents.
The catalog must therefore support two equally important usage modes:
Human-readable architecture knowledge remains canonical. Machine-readable catalog entries describe and link to that knowledge rather than turning the toolkit into an AI-only protocol.
For skills, the catalog is also the metadata source for portable Agent Skills-compatible projections, task-oriented routing, starter bundles, conformance checks, and evaluation fixtures. It must describe how a skill is discovered and composed without duplicating the canonical instructions in
SKILL.md.Goals
Acceptance Criteria
Candidate User Stories
Relationship to Other Epics
Out of Scope