Create rulepack.json

This page walks you through creating rulepack.json for a real repository. For the complete field-by-field reference, use /rulepack.json.

1. Start from the files your agent already reads

Look for the Markdown files that already guide your coding agents:

your-project/

.
├── AGENTS.md
├── CLAUDE.md
├── .cursor/
│   └── rules/
│       └── main.mdc
├── docs/
│   └── plan.md
└── README.md

In rulepack, these are memories. Some are tied to a specific tool, such as CLAUDE.md; others are general project context, such as docs/plan.md.

2. Let an agent draft the manifest

Paste this into Claude Code, Cursor, Codex, or any coding agent:

Paste into your agent

Set up rulepack.json for this project.

rulepack.json is like package.json, but instead of shipping code it bundles
this repo's AI memory files (AGENTS.md, CLAUDE.md, .cursor/rules, .clinerules,
.windsurfrules, GEMINI.md, Copilot instructions, and custom Markdown docs)
into one reusable, versioned pack.

Please:
1. Scan the repo and list every existing AI memory file.
2. Create rulepack.json at the project root with:
   - "name": "@your-scope/short-pack-name" (ask me for my scope)
   - "version": "0.1.0"
   - "license": "MIT" unless I choose another license
   - "visibility": "public" unless I choose private or pay
   - "description": one line on what these memories help an agent do
   - "memories": map existing files to standard keys: agents, claude, cursor,
     cline, windsurf, gemini, copilot. Put other Markdown files under "custom"
     with path and optional description/readWhen/tags.
   - "files": include rulepack.json, LICENSE, README.md, and every memory path.
3. Show me the file and explain each field in plain language.

Reference: https://rulepack.lyrra.net/rulepack.json

Why the placeholder is concrete

Use @your-scope/short-pack-name, not angle-bracket placeholders. Some docs and translation systems treat <...> as tags, and concrete placeholders are easier for agents to copy safely.

3. Review the generated rulepack.json

A typical output should look like this:

rulepack.json

{
  "name": "@ichi/nextjs",
  "version": "0.1.0",
  "description": "Next.js project memory for AI coding agents",
  "license": "MIT",
  "visibility": "public",
  "keywords": ["nextjs", "typescript"],
  "memories": {
    "agents": "AGENTS.md",
    "claude": "CLAUDE.md",
    "cursor": ".cursor/rules/main.mdc",
    "custom": {
      "plan": {
        "path": "docs/plan.md",
        "description": "Project plan and implementation notes",
        "readWhen": "before planning major implementation work",
        "priority": "high",
        "tags": ["planning", "handoff"]
      }
    }
  },
  "files": [
    "rulepack.json",
    "README.md",
    "LICENSE",
    "AGENTS.md",
    "CLAUDE.md",
    ".cursor/rules/**",
    "docs/plan.md"
  ]
}

Check three things before publishing:

Every path in memories exists.
files includes README, LICENSE, and any extra supporting files.
visibility matches your intent: public, private, or pay.

4. Understand standard vs custom memories

Standard memory keys point to files that specific tools conventionally read:

Key	File
`agents`	`AGENTS.md`
`claude`	`CLAUDE.md`
`cursor`	`.cursor/rules/main.mdc`
`cline`	`.clinerules`
`windsurf`	`.windsurfrules`
`gemini`	`GEMINI.md`
`copilot`	`.github/copilot-instructions.md`

Use memories.custom for project-level Markdown that is useful across agents: plans, handoffs, architecture notes, launch docs, prompts, research summaries, or runbooks.

Custom entries can be short:

{
  "custom": {
    "plan": "docs/plan.md"
  }
}

Or they can include metadata:

{
  "custom": {
    "launch": {
      "path": "docs/launch-plan.md",
      "description": "Launch and social media plan",
      "readWhen": "when planning launch posts",
      "priority": "normal",
      "tags": ["marketing", "launch"]
    }
  }
}

5. Publish or keep it local

Publish when you want the pack to be installable elsewhere:

terminal

npx rulepack publish

If you only want to record packs installed into a project, rulepack add will maintain a consumer-side manifest for you:

consumer rulepack.json

{
  "dependencies": {
    "@rulepack/nextjs": "^0.1.0"
  }
}

That consumer manifest can be minimal. It does not need name, version, or memories unless the project is also publishing its own pack.

Visibility and access

visibility is the registry's access policy. The pack format is identical for all three values — only who can read the memory files and install differs.

value	who can read the files & install
`public`	Anyone. Listed and searchable.
`private`	Only you, the scope owner. Hidden from listings, search, and other users.
`pay`	Anyone can see the metadata, README, and linked articles; the memory files and tarball require a purchase.

Change a pack's policy by editing visibility and publishing a new version.

Pay purchases are a stub today — buying grants access without charging — so the buy / install flow is testable end to end. Real billing plugs in later without changing how access is decided.

Next steps

Quickstart — run through login, init, publish, and add.
CLI commands — learn the commands available in rulepack.
/rulepack.json — complete manifest reference.