Only 12 of 39 skills carried metadata.version, and adoption tracked which plugin a skill lived in rather than any stated rule: core, gitea and lint were consistent adopters, bin and kyberforge were consistent non-adopters, git was split with one outlier. There was no documented convention, and skill-author's own bump logic was already written as if presence were conditional. metadata.version is now required on every skill. The 19 skills here that never carried one (bin, kyberforge, gitea-files) are seeded at 1.0.0, not 0.1.0 -- that value stays reserved for a skill's actual creation point under skill-author's existing convention. The skill-frontmatter pre-commit hook now fails a SKILL.md missing the field, the same class of failure as a missing name/description. Full rationale in the new ADR. The git-plugin skills that also need this field follow in the next commit, bundled with issue #113's rtk normalization since both touch the same files. Refs: #127 ADR: 0022 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
2.3 KiB
2.3 KiB
name, description, metadata
| name | description | metadata | |||||||
|---|---|---|---|---|---|---|---|---|---|
| apm-workflow | Use when authoring, installing, or publishing an apm package, its apm.yml and the dependencies it declares, or an apm marketplace — even when the user does not say "apm". Not the apm binary or an agent runtime -> `apm-install`. |
|
Gotchas
- MCP server secrets in
apm.yml(headers, env vars) must use${VAR}indirection, never literal values, so they resolve at install or runtime and are never committed. apm experimental enable registriesmust run before aregistries:block orregistry.*config takes effect anywhere — configure, install or publish. Without it, declaring one silently does nothing: no error, no warning.apm.yml'stype:selects which primitives are processed and is never checked against what.apm/holds, soapm installandapm compilecan exit 0 having shipped none of the ones you expected. Set it to cover every primitive the package ships, and confirm the deployed output, not the exit code. Mechanics:references/configure.md.
Step 1 — Dispatch
| Condition | Flow | Reference |
|---|---|---|
Author or edit apm.yml, or scaffold a new package (apm plugin init) |
configure | references/configure.md |
Resolve or fetch the dependencies apm.yml declares (apm install, apm install [PACKAGE_REF]) |
install | references/install.md |
Build a marketplace, register a package into it (local: hand-edit apm.yml; remote: apm marketplace package add), or register someone else's as a consumer (apm marketplace init/check/package add/add) |
marketplace | references/marketplace.md |
Generate per-target output, bundle, or publish (apm compile, apm pack, apm publish) |
compile | references/compile.md |
Validate integrity/policy or wire a CI gate (apm audit, apm audit --ci) |
audit | references/audit.md |
Read the reference file matching the resolved flow — it carries that flow's own traps, and names a sibling file wherever one flow genuinely depends on another's detail.
Step 2 — Execute
Follow the matched reference file's instructions. Report back which apm command(s) were run (or drafted, if the user asked for a plan rather than execution) and their outcome.