Apm vendor skills
Skill pngdeity/apm-user-repository/packages/apm-vendor-skills/.apm/skills/apm-vendor-skills
Personal APM marketplace — skills, prompts, agents, and instructions for AI coding agents
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.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
5.9 KB, 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>"