prpm-json-best-practices
Best practices for structuring prpm.json package manifests with required fields, tags, organization, multi-package management, enhanced file format, eager/lazy activation, and conversion hints
npx skills add AgentWorkforce/relay --skill prpm-json-best-practices-skill --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
The skill provides best practices for structuring prpm.json manifests, covering when to apply the file, core purpose, and detailed guidance for single-package, multi-package, and collections repositories. It defines required fields for top-level and multi-package definitions, optional fields, and how to organize packages and collections within a repository. It also outlines formatting conventions, activation (eager vs lazy), tagging, organization strategies, versioning, and file management expectations.
How it works
The skill describes concrete scenarios for when to apply a prpm.json manifest, including publishing a package, organizing multiple packages, and bundling collections. It enumerates required fields for top-level single-package manifests, and for each package within a multi-package setup, including names, versions, descriptions, formats, subtypes, and files. It details optional fields (repository, organization, tags, dependencies, scripts, eager) and how collections are structured (collection-level fields and per-package package entries with packageId, version, required, reason). It specifies how to reference collections (by package IDs) and how to handle versioning (semantic or ranges) within collections. It provides guidance on tag structure, naming conventions, and file paths, emphasizing full paths from project root and kebab-case usage. It also includes guidance on eager vs lazy activation precedence and applicable subtypes.
When to use it
Use this skill when creating or maintaining prpm.json manifests for publishing packages, organizing multi-package repositories, adding or updating package metadata, or managing collections within a repository. It is not intended for user configuration files, lockfiles, regular installations, or dependencies tracked only in lockfiles.
What it can touch
- prpm.json manifests for single packages, multi-package repositories, and collections (top-level and nested package entries)
- Package definitions including required fields like name, version, description, author, license, format, subtype, and files
- Optional fields such as repository, organization, homepage, documentation, license_text, license_url, tags, keywords, category, private, dependencies, scripts, eager
- Structure of collections referencing packages by packageId and optional fields like version, required, reason
- File path conventions for including files in manifests (full paths from project root, e.g., .claude/skills/... or .cursor/...)
Caveats
- The skill outlines conventions and requirements for prpm.json manifests but does not guarantee registry behavior or publishing outcomes.
- It specifies that prpm.json is primarily for publishing packages; regular users installing packages do not require it.
- Guidance assumes standard semantic versioning and typical repository structures as described in the examples.
# PRPM JSON Best Practices You are an expert at creating and maintaining `prpm.json` package manifests for PRPM (Prompt Package Manager). You understand the structure, required fields, organization patterns, and best practices for multi-package repositories. ## When to Apply This Skill **Use when:** - Creating a new `prpm.json` manifest for publishing packages - Maintaining existing `prpm.json` files - Organizing multi-package repositories - Adding or updating package metadata - Ensuring package manifest quality and completeness **Don't use for:** - User configuration files (`.prpmrc`) - those are for users - Lockfiles (`prpm.lock`) - those are auto-generated by PRPM - Regular package installation (users don't need `prpm.json`) - Dependencies already tracked in lockfiles ## Core Purpose `prpm.json` is **only needed if you're publishing packages**. Regular users installing packages from the registry don't need this file. Use `prpm.json` when you're: - Publishing a package to the PRPM registry - Creating a collection of packages - Distributing your own prompts/rules/skills/agents - Managing multiple related packages in a monorepo ## File Structure ### Single Package See `examples/sin
- When to Apply This Skill
- Core Purpose
- File Structure
- Single Package
- Multi-Package Repository
- Collections Repository
- Packages + Collections (Combined)
- Required Fields
- Top-Level (Single Package)
- Optional Top-Level Fields
- Multi-Package Fields
- Collection Fields
- Format and Subtype Values
- Format (Target AI Tool)
Check all files in prpm.json exist for file in $(cat prpm.json | jq -r '.packages[].files[]'); do if [ ! -f "$file" ]; then echo "Missing: $file" fi done Check for duplicate package names cat prpm.json | jq -r '.packages[].name' | sort | uniq -d Test your prepublishOnly script manually cd /path/to/prpm.json/directory
What does the prpm-json-best-practices skill do?
Best practices for structuring prpm.json package manifests with required fields, tags, organization, multi-package management, enhanced file format, eager/lazy activation, and conversion hints
How do I install it?
Run `npx skills add AgentWorkforce/relay --skill prpm-json-best-practices-skill --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From AgentWorkforce/relay, a repository with 784 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.