A multi-skill repository — each subdirectory under skills/ is a self-contained Claude skill. The layout follows Anthropic's skill-repo convention (one repo, many skills), but distribution and discovery go entirely through the Liatrio skills platform: every skill is published as an OCI artifact to GHCR, and browseable at https://skills.liatr.io/. Claude Code's plugin marketplace is intentionally not used here.
.
├── .github/workflows/
│ ├── release.yml # Per-skill semantic-release on push to main
│ ├── publish.yml # Tag-triggered publish to GHCR via reusable workflow
│ ├── pr-smoke.yml # Static-per-skill smoke jobs, on every PR
│ └── templates/ # Parameterized scaffolds (not auto-executed)
│ ├── release.yml # ↑ skill-publish-github copies these
│ ├── publish.yml # ↑ into consumer repos with substitutions
│ ├── pr-smoke.yml # ↑ for {{SKILL_NAME}} and {{PLATFORM_TAG}}
│ ├── .releaserc.cjs #
│ └── README.md # Placeholder reference + dogfood notes
├── .releaserc.cjs # Shared semantic-release config (driven by $SKILL)
├── skills/ # Skill content (one subdirectory per skill)
│ └── <skill-name>/
│ ├── SKILL.md # Frontmatter + body (required); metadata.version is auto-bumped
│ ├── references/ # Optional: long-form docs Claude can pull on demand
│ └── scripts/ # Optional: helper scripts the skill invokes
├── template/SKILL.md # Starter for new skills (copy + rename)
└── README.md
Each skills/<name>/SKILL.md follows the agentskills.io spec. The spec places version under metadata.version; the release workflow maintains it automatically based on the conventional-commit history scoped to that skill. See Adding a new skill.
The files in .github/workflows/*.yml are the dogfood form of the templates under .github/workflows/templates/ — this repo publishes its own skill-publish-github using the same scaffolds it asks other repos to adopt. When you update one side, mirror the change to the other. See .github/workflows/templates/README.md.
| Name | Description |
|---|---|
| none yet | Copy template/ to skills/<your-skill>/ and follow the steps below. |
- Copy the template:
cp -R template skills/my-new-skill
- Edit
skills/my-new-skill/SKILL.md. Required frontmatter:--- name: my-new-skill # Must match the directory name, kebab-case lowercase. description: One-line description Claude uses to decide when to load this skill. ≤ 1024 chars. metadata: version: "0.1.0" # Maintained by release.yml — bumped automatically from commit history. ---
- (Optional) Add
references/for long-form docs Claude can pull on demand, andscripts/for helper scripts. - Open a PR. The
pr-smoke.ymlmatrix runs a dry-run publish for every skill changed in the PR — broken frontmatter, missing fields, or contract violations fail the PR. - Once merged,
release.ymlcuts the next tag for any skill whose scoped commits warrant a release (see Releasing).
Releases are fully automated and per-skill. There is no manual tag step; merging to main is the release trigger.
Write Conventional Commits scoped to the skill you are changing:
feat(skill-publish-github): add support for monorepo onboarding
fix(skill-publish-github): tolerate trailing whitespace in frontmatter
feat(skill-publish-github)!: rename `onboard` command to `publish` # major bump
The scope (skill-publish-github above) selects which skill's history the release engine analyses. Unscoped commits, or commits scoped to non-skill paths (docs:, chore:, feat(template):, etc.) do not trigger any release.
release.yml runs semantic-release once per skill, in matrix:
- Discovers every
skills/<name>/SKILL.md. - For each skill, reads commits since its last
<skill>-v*tag, filtered to commits that touched files underskills/<skill>/(viasemantic-release-monorepo). - If those commits warrant a release (
feat:→ minor,fix:→ patch,feat!:orBREAKING CHANGE→ major), semantic-release:- Stamps the new semver into
skills/<skill>/SKILL.mdundermetadata.version. - Commits the updated SKILL.md back to
mainwith[skip ci](so this workflow does not re-trigger itself). - Creates the tag
<skill>-v<semver>(e.g.skill-publish-github-v0.2.0) and a GitHub release with notes.
- Stamps the new semver into
The tag push then fires publish.yml, which:
- Parses
<skill>and<version>from the tag. - Verifies the tagged commit's
metadata.versionmatches. - Invokes
liatrio/skills-platform/.github/workflows/publish-skill.ymlwithskill-name,version, andskill-path: skills/<skill>. - The reusable workflow pushes
ghcr.io/liatrio/skills/<skill-name>:<version>to GHCR with a SLSA build-provenance attestation.
When a skill has no <skill>-v* tag yet, semantic-release defaults the first release to 1.0.0. If you want to preserve the metadata.version you seeded in the SKILL.md (e.g. 0.1.0), pre-tag the current main once before merging the first feature commit:
git tag skill-publish-github-v0.1.0 origin/main
git push origin skill-publish-github-v0.1.0After that, every release is derived automatically from commit history.
Skills are distributed as OCI artifacts. Pull one directly from GHCR:
# Inspect what's available
skills-discover inspect ghcr.io/liatrio/skills/<skill-name>
# (Installation CLI / consumer-side tooling: see liatrio/skills-platform.)Published skills are listed at https://skills.liatr.io/. The platform's discovery walks skills/<name>/SKILL.md and emits one catalog entry per skill in this repo.
Follow Conventional Commits and scope every skill-affecting commit to the skill name (feat(<skill-name>): ...). PR title is enforced by the platform's pr-title.yml. Releases are fully automated — no manual version stamping or tagging.
To be determined.