Skills Sh Webmaxru Ai Native Dev Agent Package Manager

---
name: agent-package-manager
description: Installs, configures, audits, and operates Agent Package Manager (APM) in repositories. Use when initializing apm.yml, installing or updating packages, validating manifests, managing lockfiles, compiling agent context, browsing MCP servers, setting up runtimes, or packaging resolved context for CI and team distribution. Don't use for writing a single skill by hand, generic package managers like npm or pip, or non-APM agent configuration systems.
license: MIT
metadata:
  author: webmaxru
  version: "1.5"
---

# Agent Package Manager

## Procedures

**Step 1: Assess the repository and the requested APM outcome**
1. Inspect the repository root for `apm.yml`, `apm.lock.yaml`, `.github/`, `.claude/`, `.codex/`, `.cursor/`, `.gemini/`, `.opencode/`, `.windsurf/`, and `apm_modules/`.
2. Execute `apm --version` and `apm config` to confirm the installed CLI and current configuration.
3. If `apm.yml` exists, read `references/manifest-and-lockfile.md` before changing dependencies, scripts, or compilation settings.
4. If the request is about package installation, updates, pruning, or removal, read `references/command-workflows.md` before executing APM commands.
5. If no `apm.yml` exists and the user wants APM in the repository, initialize the project with `apm init` or `apm init --yes`.
6. If the repository already uses another agent configuration flow and the user did not ask to migrate it, limit the change to the requested APM scope instead of replacing the existing setup.

**Step 2: Shape or repair the manifest deliberately**
1. Read `assets/apm.yml.template` when the repository needs a fresh or repaired manifest structure.
2. Keep `name` and `version` present at the top level; treat them as required contract fields.
3. Add APM package dependencies under `dependencies.apm` and MCP servers under `dependencies.mcp`.
4. Prefer canonical dependency forms in `apm.yml` after installation. Default to the repository shorthand `owner/repo/path` for GitHub-hosted skills and packages, for example `webmaxru/web-ai-agent-skills/skills/webmcp`, and preserve explicit `path`, `ref`, and `alias` only when they are needed.
5. Use pinned refs for shared team packages when reproducibility matters more than automatic drift.
6. Keep local path dependencies only for active local development. Replace them with remote references before recommending bundle distribution.
7. If the request includes scripts, define them under `scripts` and verify that each script can be previewed or executed through `apm list`, `apm preview`, or `apm run`.

**Step 3: Manage dependencies with verification, not guesswork**
1. Preview risky changes with `apm install --dry-run`, `apm uninstall --dry-run`, or `apm prune --dry-run` when the repository already has installed packages.
2. Install or update packages with `apm install`, `apm install <package>`, `apm install --update`, or `apm deps update` according to the requested scope.
3. After running `apm install --update` or `apm deps update`, verify the lockfile `resolved_commit` actually changed. If packages were served from a stale cache, follow the "Stale packages after update" workflow in `references/troubleshooting.md`.
4. When the request is to install a single skill from a repository, provide the package path down to that skill directory instead of a vague repo-only placeholder, for example `apm install webmaxru/web-ai-agent-skills/skills/webmcp`.
5. Verify the resolved state with `apm deps list`, `apm deps tree`, or `apm deps info <package>` after dependency changes.
6. Treat `apm.lock.yaml` as the source of truth for resolved commits and deployed files. Recommend committing it for team and CI reproducibility.
7. If the repository needs MCP discovery or selection, use `apm mcp list`, `apm mcp search <query>`, and `apm mcp show <server>` before editing MCP entries by hand.
8. If installation output reports collisions or skipped files, read `references/troubleshooting.md` before retrying with forceful options.
9. If the repository consumes packages from itself (self-referencing dependency), remind the user that changes must be committed and pushed before APM can fetch them. Read `references/troubleshooting.md` for the "Self-referencing dependencies" section.
10. Note that `apm install` scans packages for security threats before deployment. If the scan raises warnings or blocks installation, address the flagged content rather than bypassing the check.
  11. If the repository is in an organization that enforces `apm-policy.yml`, policy is applied at install time and can block transitive MCP servers or restrict dependency sources. If install is blocked by policy, inspect the policy file or contact the org administrator; do not attempt to bypass the enforcement.

**Step 4: Compile and validate only when it adds value**
1. Read `references/command-workflows.md` before changing compilation strategy or target selection.
2. Use `apm compile --validate` to validate primitives when the goal is correctness rather than output generation.
3. Use `apm compile --dry-run` before large compilation changes or when checking placement decisions.
4. Explain that `apm install` already deploys prompts, agents, skills, hooks, and MCP integrations for supported tools; `apm compile` mainly exists to generate instruction files such as `AGENTS.md` or `CLAUDE.md`.
5. Use explicit targets when the repository serves more than one runtime or tool family.
6. Keep `compilation.exclude` aligned with build and dependency directories so compilation does not re-scan generated output.
7. If the project needs continuous regeneration during authoring, use `apm compile --watch` only after the one-shot validation path is clean.

**Step 5: Operate scripts, runtimes, and distribution flows professionally**
1. List project scripts with `apm list` before invoking them.
2. Preview prompt-driven scripts with `apm preview <script> -p key=value` before using `apm run <script> -p key=value` in an automation or debugging workflow.
3. Use `apm runtime status`, `apm runtime list`, and `apm runtime setup <runtime>` when the repository depends on an APM-managed runtime.
4. If the goal is CI fan-out, air-gapped delivery, or release traceability, read `references/command-workflows.md` and use `apm pack` only after a successful install has produced `apm.lock.yaml` and deployed files.
5. Use `apm unpack` only for additive extraction of a previously packed bundle. Do not present it as a replacement for dependency authoring.
6. Recommend `apm-action` or a prebuilt bundle when repeated installs create avoidable CI cost or network risk.

## Error Handling
* If `apm` is missing, install or update it first, then verify with `apm --version` before editing project files.
* If `apm install` is blocked by an organization policy (`apm-policy.yml`), do not bypass the policy; report the block and ask the administrator to adjust the policy or allowlist the dependency.
* If `apm install` reports authentication failures, read `references/troubleshooting.md` and fix host authentication before retrying.
* If `apm install` reports file collisions, inspect the diagnostic summary, retry with `--verbose` when needed, and use `--force` only when overwriting local files is clearly intended.
* If `apm compile` is unnecessary for the user’s toolchain, avoid adding it as busywork; prefer the lighter install-only path.
* If `apm pack` fails because `apm.lock.yaml` is missing or deployed files are absent, rerun `apm install` before retrying.
* If the repository depends on local path packages, do not recommend `apm pack` until those dependencies are replaced with remote references.