prpm-json-best-practices-skill

Name: prpm-json-best-practices-skill
Author: AgentWorkforce

769stars58forks

How to install prpm-json-best-practices-skill?

agentworkforce/relay/prpm-json-best-practices-skill

$npx -y skills add AgentWorkforce/relay --skill prpm-json-best-practices-skill

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# PRPM JSON Best Practices
2
3	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.
4
5	## When to Apply This Skill
6
7	Use when:
8
9	- Creating a new `prpm.json` manifest for publishing packages
10	- Maintaining existing `prpm.json` files
11	- Organizing multi-package repositories
12	- Adding or updating package metadata
13	- Ensuring package manifest quality and completeness
14
15	Don't use for:
16
17	- User configuration files (`.prpmrc`) - those are for users
18	- Lockfiles (`prpm.lock`) - those are auto-generated by PRPM
19	- Regular package installation (users don't need `prpm.json`)
20	- Dependencies already tracked in lockfiles
21
22	## Core Purpose
23
24	`prpm.json` is only needed if you're publishing packages. Regular users installing packages from the registry don't need this file.
25
26	Use `prpm.json` when you're:
27
28	- Publishing a package to the PRPM registry
29	- Creating a collection of packages
30	- Distributing your own prompts/rules/skills/agents
31	- Managing multiple related packages in a monorepo
32
33	## File Structure
34
35	### Single Package
36
37	See `examples/single-package.json` for complete structure.
38
39	Key fields: `name`, `version`, `description`, `author`, `license`, `format`, `subtype`, `files`
40
41	### Multi-Package Repository
42
43	See `examples/multi-package.json` for complete structure.
44
45	Use when: Publishing multiple related packages from one repo
46	Key difference: Top-level `packages` array with individual package definitions
47
48	### Collections Repository
49
50	See `examples/collections-repository.json` for complete structure.
51
52	Use when: Bundling existing published packages into curated collections
53	Key points:
54
55	- `collections` array references packages by `packageId` (not files)
56	- Each collection has `id`, `name`, `description`, `packages`
57	- Packages can be `required: true` (default) or `false` (optional)
58	- Use version ranges (`^1.0.0`) or `latest`
59	- Add `reason` to explain why package is included
60
61	### Packages + Collections (Combined)
62
63	See `examples/packages-with-collections.json` for complete structure.
64
65	Use when: Publishing packages AND creating collections that bundle them
66	Key points:
67
68	- Define packages in `packages` array with files
69	- Define collections in `collections` array referencing those packages
70	- Collections can reference both local packages and external ones
71	- Publish both individual packages and collection bundles from same repo
72
73	## Required Fields
74
75	### Top-Level (Single Package)
76
77	\| Field \| Type \| Required \| Description \|
78	\| ------------- \| -------- \| -------- \| ------------------------------------------------------------------------------- \|
79	\| `name` \| string \| Yes \| Package name (kebab-case, unique in registry) \|
80	\| `version` \| string \| Yes \| Semver version (e.g., `1.0.0`) \|
81	\| `description` \| string \| Yes \| Clear description of what the package does \|
82	\| `author` \| string \| Yes \| Author name and optional email \|
83	\| `license` \| string \| Yes \| SPDX license identifier (e.g., `MIT`, `Apache-2.0`) \|
84	\| `format` \| string \| Yes \| Target format: `claude`, `cursor`, `continue`, `windsurf`, etc. \|
85	\| `subtype` \| string \| Yes \| Package type: `agent`, `skill`, `rule`, `slash-command`, `prompt`, `collection` \|
86	\| `files` \| string[] \| Yes \| Array of files to include in package \|
87
88	### Optional Top-Level Fields
89
90	\| Field \| Type \| Description \|
91	\| --------------- \| -------- \| ------------------------------------------------------------- \|
92	\| `repository` \| string \| Git repository URL \|
93	\| `organization` \| string \| Organization name (for scoped packages) \|
94	\| `homepage` \| string \| Package homepage URL \|
95	\| `documentation` \| string \| Documentation URL \|
96	\| `license_text` \| string \| Full text of the license file for proper attribution \|
97	\| `license_url` \| string \| URL to the license file in the repository \|
98	\| `tags` \| string[] \| Searchable tags (kebab-case) \|
99	\| `keywords` \| string[] \| Additional keywords for

People who liked this also viewed

6 picks

Type

prpm-json-best-practices-skill

769stars58forks

View on GitHub

How to install prpm-json-best-practices-skill?

agentworkforce/relay/prpm-json-best-practices-skill

$npx -y skills add AgentWorkforce/relay --skill prpm-json-best-practices-skill

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# PRPM JSON Best Practices
2
3	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.
4
5	## When to Apply This Skill
6
7	Use when:
8
9	- Creating a new `prpm.json` manifest for publishing packages
10	- Maintaining existing `prpm.json` files
11	- Organizing multi-package repositories
12	- Adding or updating package metadata
13	- Ensuring package manifest quality and completeness
14
15	Don't use for:
16
17	- User configuration files (`.prpmrc`) - those are for users
18	- Lockfiles (`prpm.lock`) - those are auto-generated by PRPM
19	- Regular package installation (users don't need `prpm.json`)
20	- Dependencies already tracked in lockfiles
21
22	## Core Purpose
23
24	`prpm.json` is only needed if you're publishing packages. Regular users installing packages from the registry don't need this file.
25
26	Use `prpm.json` when you're:
27
28	- Publishing a package to the PRPM registry
29	- Creating a collection of packages
30	- Distributing your own prompts/rules/skills/agents
31	- Managing multiple related packages in a monorepo
32
33	## File Structure
34
35	### Single Package
36
37	See `examples/single-package.json` for complete structure.
38
39	Key fields: `name`, `version`, `description`, `author`, `license`, `format`, `subtype`, `files`
40
41	### Multi-Package Repository
42
43	See `examples/multi-package.json` for complete structure.
44
45	Use when: Publishing multiple related packages from one repo
46	Key difference: Top-level `packages` array with individual package definitions
47
48	### Collections Repository
49
50	See `examples/collections-repository.json` for complete structure.
51
52	Use when: Bundling existing published packages into curated collections
53	Key points:
54
55	- `collections` array references packages by `packageId` (not files)
56	- Each collection has `id`, `name`, `description`, `packages`
57	- Packages can be `required: true` (default) or `false` (optional)
58	- Use version ranges (`^1.0.0`) or `latest`
59	- Add `reason` to explain why package is included
60
61	### Packages + Collections (Combined)
62
63	See `examples/packages-with-collections.json` for complete structure.
64
65	Use when: Publishing packages AND creating collections that bundle them
66	Key points:
67
68	- Define packages in `packages` array with files
69	- Define collections in `collections` array referencing those packages
70	- Collections can reference both local packages and external ones
71	- Publish both individual packages and collection bundles from same repo
72
73	## Required Fields
74
75	### Top-Level (Single Package)
76
77	\| Field \| Type \| Required \| Description \|
78	\| ------------- \| -------- \| -------- \| ------------------------------------------------------------------------------- \|
79	\| `name` \| string \| Yes \| Package name (kebab-case, unique in registry) \|
80	\| `version` \| string \| Yes \| Semver version (e.g., `1.0.0`) \|
81	\| `description` \| string \| Yes \| Clear description of what the package does \|
82	\| `author` \| string \| Yes \| Author name and optional email \|
83	\| `license` \| string \| Yes \| SPDX license identifier (e.g., `MIT`, `Apache-2.0`) \|
84	\| `format` \| string \| Yes \| Target format: `claude`, `cursor`, `continue`, `windsurf`, etc. \|
85	\| `subtype` \| string \| Yes \| Package type: `agent`, `skill`, `rule`, `slash-command`, `prompt`, `collection` \|
86	\| `files` \| string[] \| Yes \| Array of files to include in package \|
87
88	### Optional Top-Level Fields
89
90	\| Field \| Type \| Description \|
91	\| --------------- \| -------- \| ------------------------------------------------------------- \|
92	\| `repository` \| string \| Git repository URL \|
93	\| `organization` \| string \| Organization name (for scoped packages) \|
94	\| `homepage` \| string \| Package homepage URL \|
95	\| `documentation` \| string \| Documentation URL \|
96	\| `license_text` \| string \| Full text of the license file for proper attribution \|
97	\| `license_url` \| string \| URL to the license file in the repository \|
98	\| `tags` \| string[] \| Searchable tags (kebab-case) \|
99	\| `keywords` \| string[] \| Additional keywords for

People who liked this also viewed

6 picks

Type