Files
holocron/plugins/kyberforge/.apm/skills/forge/references/version-bump.md
T
Defame1297andClaude Code c52e351954 feat(kyberforge): add instructions-author skill for .apm/instructions files
Scaffolds and revises apm instructions files, with a throwaway-package
verification recipe because `apm compile --validate` always exits 0 and
Claude Code drops `description`. Routed from forge and linked from
apm-workflow's compile reference. Bumps kyberforge to 2.1.0 and the catalog
to 0.5.2.

Fixes #148

Co-Authored-By: Claude Code <[email protected]>
Claude-Session: https://claude.ai/code/session_01KkT7RSDwDbmrM9T34b6sTi
2026-10-01 06:46:39 +00:00

1.9 KiB

source_keys
source_keys
claude-code-subagents-docs

Bumping the package version after a route

Reached from SKILL.md Step 3 after a route has finished. A skill route always lands here: skill-author moves only a skill's own metadata.version, which is not the package manifest's number, so the package version is still behind when it reports done. agent-author and instructions-author bump the resolved package's apm.yml themselves (agent-author at plugin/APM scope), and apm-workflow's configure flow carries the same policy — read those routes' output before acting here, because a second bump for one change is wrong.

Find the owning package

Walk up from the artifact's path to the nearest ancestor apm.yml that declares a top-level type: field (instructions, skill, hybrid or prompts).

An apm.yml with no type: field is a marketplace-only manifest: it lists packages rather than declaring one, so it does not count as a match. Skip it and keep walking up.

Skip this step entirely if no ancestor apm.yml carries a type: field: the artifact is then standalone or scoped to a user agent directory, and there is no package to version.

Delegate the bump

Invoke apm-workflow as a clean-context subagent — fresh, not forked — with this brief:

"The package at <package-path> gained a new <artifact-type> (<artifact-name>). Bump the version field in that package's apm.yml. Determine whether to bump minor (0.1.0) or patch (0.0.1) based on whether this is a new capability (minor) or a fix/refactor (patch). Do not release or tag — just update apm.yml and commit."

Clean context rather than a fork is the point: the bump decision is made independently, without anchoring on the authoring conversation that just argued for the artifact's significance.

Then report to the user: "Updated <package-name> version from <old> to <new> to reflect the new <artifact-name>."