---
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` bumps the
resolved package's `apm.yml` itself 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>`."