Files
holocron/plugins/kyberforge/.apm/skills/apm-workflow/SKILL.md
Defame1297 60be7b3232 refactor(skills): mandate metadata.version on every skill's frontmatter
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
2026-09-07 20:36:24 +00:00

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`.
version category source_keys
1.0.0 apm
context7-microsoft-apm

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 registries must run before a registries: block or registry.* config takes effect anywhere — configure, install or publish. Without it, declaring one silently does nothing: no error, no warning.
  • apm.yml's type: selects which primitives are processed and is never checked against what .apm/ holds, so apm install and apm compile can 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.