Apm vendor skills
Skill pngdeity/apm-user-repository/packages/apm-vendor-skills/.apm/skills/apm-vendor-skills
Step-by-step procedural skill for vendoring external SKILL.md files into an APM marketplace. Use when importing skills, prompts, instructions, or agents from a non-APM GitHub repository (skills.sh, Claude Code plugins, or raw SKILL.md collections) into this marketplace.From its SKILL.md
npx -y skills add pngdeity/apm-user-repository --skill apm-vendor-skillsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.9 KB, ~1.4k tokens by cl100k_base, as published. Nobody here has run it
APM Skill Vendoring
Vendors external SKILL.md content from a non-APM repository into this Agent Package Manager marketplace. Assumes the source repo is not already set up as an APM marketplace.
Phase 1: Discovery
Explore the source repository to identify all vendorable content.
Step 1.1: Map the repo structure
Fetch the GitHub tree or clone the repo. Identify:
- Every
SKILL.mdfile (the primary primitive) - Every
references/*.mdfile (progressive disclosure) - Every
scripts/*.shfile (automation) - Every
assets/*file (templates) - Any
prompts/*.prompt.md,instructions/*.instructions.md, oragents/*.agent.mdfiles
Step 1.2: Understand the naming conventions
Note how skills are named, how they cross-reference each other, and what frontmatter fields they use. Common source layouts:
| Source Layout | Key Files |
|---|---|
skills/<name>/SKILL.md | skills.sh convention |
claude/<name>/skills/<name>/SKILL.md | Claude Code plugin structure |
SKILL.md at repo root | Single-skill repo |
Phase 2: Mapping
Map source locations to APM .apm/ directory conventions.
| Source Path | APM Path |
|---|---|
skills/<name>/SKILL.md | packages/<name>/.apm/skills/<name>/SKILL.md |
skills/<name>/references/*.md | packages/<name>/.apm/skills/<name>/references/*.md |
skills/<name>/scripts/*.sh | packages/<name>/.apm/skills/<name>/scripts/*.sh |
skills/<name>/assets/* | packages/<name>/.apm/skills/<name>/assets/* |
skills/<name>/evals/ | packages/<name>/.apm/skills/<name>/evals/ |
For multi-skill packages (hybrid type), group related skills under
packages/<bundle>/.apm/skills/<skill-name>/.
Phase 3: Frontmatter Normalization
Adapt upstream YAML frontmatter to this marketplace's conventions.
Fields to keep
name— always preserveddescription— preserved; may be shortened for theapm.ymlentrycompatibility— preserved if presentmetadata— preserve the block, add atagsfield
Fields to add
metadata.tags— space-separated keywords derived frommetadata.sourcesor skill content. Use lowercase, use spaces as separators.
Example:
# From upstream:
metadata:
sources: "Effective Go, Google Style Guide, Uber Style Guide"
# Normalize to:
metadata:
tags: "go style effective-go google-style uber-style"
Fields to drop
license— not used in this marketplace's frontmatter conventionmetadata.sources— converted tometadata.tags
Tool name conversion
Platform-specific tool syntax must be normalized:
| Upstream Syntax | OpenCode Syntax |
|---|---|
Bash(bash:*) | bash |
Read, Grep | Read, Grep (already compatible) |
Platform-specific features
Remove or adapt features that don't exist in the target platform:
!command`` (Claude Code inline shell execution) → Replace with instructions to use thebashtoolAskUserQuestion(Claude Code) → Replace withUse the question tool- Junie/Claude Code-specific directives → Remove
Phase 4: Cross-References
Upstream skills often cross-reference each other with relative paths:
See [go-error-handling](../go-error-handling/SKILL.md) when...
Options:
- Remove them — Simplest. Skills become self-contained.
- Convert to name references — Change to "See the go-error-handling skill."
- Keep as relative links — Works within multi-skill hybrid packages since
all skills live under the same
.apm/skills/directory.
For skills bundled into a single hybrid package, option 3 works. For skills split across separate packages, options 1 or 2 are safer.
Phase 5: Packaging
Create the APM package structure.
Single-skill package (type: skill)
packages/<name>/
apm.yml
.apm/skills/<name>/
SKILL.md
references/ (optional)
scripts/ (optional)
assets/ (optional)
Multi-skill bundle (type: hybrid)
packages/<bundle>/
apm.yml
.apm/skills/
<skill-1>/
SKILL.md
references/
<skill-2>/
SKILL.md
references/
apm.yml template
name: <package-name>
version: 0.1.0
description: <one-line description>
type: <skill | hybrid | instructions>
includes: auto
Phase 6: Registration
Add the package to the root apm.yml under marketplace.packages.
Entry template
- name: <package-name>
description: <same as package description>
source: pngdeity/apm-user-repository
subdir: packages/<package-name>
version: ">=0.0.1"
Placement rules
- Insert in alphabetical order among existing packages
- Bundle packages (e.g.,
pngdeity-defaults) always go last
Phase 7: Validation
Run these commands in order:
just fmt # Auto-format all YAML files
just sync-check # Verify package versions satisfy root constraints
just sync-fix # Auto-fix mismatched versions (if sync-check fails)
just yaml-validate # Validate against JSON Schema
apm marketplace check # Validate all refs resolve
apm pack --dry-run # Validate marketplace.json generation
just ci # Full CI check (read-only)
Fix any failures before committing.
Phase 8: Commit
apm pack # Regenerate marketplace.json
git add packages/<name>/ apm.yml .claude-plugin/
git commit -S -m "vendor: add <name> from <source-url>"
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most operations skills give in ~1.4k tokens
Counted across 483 of the 484 authors here whose files we hold, read 2026-08-07
- Collect monitoring data throughout the simulationin 14 of 483, across 6 files
- Set the random seed for reproducibilityin 14 of 483, across 6 files
- Validate simulations against analytical solutionsin 12 of 483, across 4 files
- Clarify goals, constraints, and inputsin 11 of 483, across 2 files
- Implement contract tests for integration pointsin 11 of 483, across 2 files
- Implement strangler fig infrastructure with API gatewayin 11 of 483, across 2 files
- Audit modernized components for security vulnerabilitiesin 11 of 483, across 2 files
- Avoid Python blocking calls in processesin 10 of 483, across 3 files
- Use resource context managers for automatic cleanupin 9 of 483, across 2 files
- Maintain consistent time unitsin 9 of 483, across 2 files
- Validate outcomes against success criteriain 8 of 483, across 1 file
- Analyze the legacy codebase for technical debtin 8 of 483, across 1 file
Said here and by no other author read
- explore source repository to identify vendorable content
- map source paths to APM directory conventions
- preserve name and description frontmatter fields
- add space-separated lowercase tags to metadata
- drop license and metadata sources fields
- normalize platform-specific tool syntax
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.