Stop Scattering AI Resources: Managing Skills, Rules and MCP With Bear.CTXPM

When AI files pile up

Work with coding agents for long enough and the repository fills with more than prompts. There are rules that constrain code style, skills for routine jobs, specs describing product boundaries, MCP configs wiring in outside services and memories of past decisions. Some of it comes from open source communities, some belongs to the team, and some matters only for one project.

Dropping everything into the repo works at first. The trouble shows up later, when the project grows, you change agents or you come back after months. Which files belong in Git? Has any outside resource moved on? Is a given rule meant for the team or just this one repo? Without clear boundaries, the whole setup turns into a mess.

That mess is the starting point for Bear.CTXPM. The name abbreviates Context Package Manager. It's an open source protocol for handling AI resources, paired with a ctxpm command-line tool. It arranges the context and capabilities an AI uses the way you already arrange project code.

Classic package managers expect you to type commands for installing, updating and validating. CTXPM takes an AI-first route instead. Protocol rules and operating logic are injected through the agent entry documents, and together with built-in skills and CLI tools they let agents check, upgrade, validate and tidy resources while doing ordinary coding, review and debugging. You don't have to learn subcommand flags. The agent reads the protocol, calls the tools and asks you when a decision is needed.

A protocol before a tool

CTXPM doesn't ask you to rewrite your existing skills, rules or prompts, and it doesn't tie the project to one agent. It first settles questions every real project hits:

• Which AI resources does the project contain?
• Are they external, or maintained by the project itself?
• Where do they live, and should they be under version control?
• Which entry point should each agent read them from?
• How are they installed, validated, migrated and updated?

Those agreements get written down in the ctxpm.yaml manifest, in the .ctxpm/ folder structure and in the entry documents for agents at the project root. The CLI makes installing, detecting and validating more dependable, but the protocol doesn't rely on it. Where the tool can't run, an AI can still understand the project from the manifest and the directories.

Two kinds of ownership

Only two ownership terms exist: dependency and package.

A dependency is an external AI resource the project consumes. It might come from a Git repository, an OCI registry, a file path or elsewhere. Its full content usually isn't committed, but ctxpm.yaml records the source, path and a stable version, much like third-party dependencies in application code.

A package is something the project looks after on its own. It ties into the project's business logic, code layout or working methods, so it gets committed, reviewed next to the source and edited whenever the project changes.

Ownership is separate from type. Either kind can be a skill, rule, spec, prompt, memory or mcp. A commit skill imported from GitHub is a dependency plus skill. A release workflow specific to one repository is a package plus skill. The project's own limits on editing source code could be a package plus rule. That way, who maintains a resource and who you ask when it breaks stay distinct.

What the directory holds

A project that adopts CTXPM typically has ctxpm.yaml as its resource manifest. Installed external resources go into .ctxpm/dependencies/, which is normally listed in .gitignore. Resources the project maintains go into .ctxpm/packages/, usually tracked in version control.

.ctxpm/AGENTS.md is the shared source for agent entry files. Depending on which agent profiles are enabled, the root can receive generated copies named AGENTS.md, CLAUDE.md, GEMINI.md or whatever else an agent expects, and each one points at the same text. Rules are maintained once, while the entry files adapt to each agent's conventions.

The entry document also tells the AI how to discover things. Start from the manifest, move to the project's own packages, then to external dependencies, and pull in memory only when a task requires history. The context doesn't fill up with every file from the start. That's what makes the design AI-driven: the protocol is an operating guide and not static configuration. The agent reads resources by priority, decides which rules apply to the task at hand and runs checks and maintenance at suitable moments, so developers don't stop coding to do it by hand.

The repository as its own example

The project's own repo is run by these rules. ctxpm itself and an outside git-commit skill count as external dependencies. The release workflow that serves only this repo is a package plus skill. A reminder not to mix product source code with the repository's own managed resources is a package plus rule. A simplified manifest looks like this:

version: 1.0

project:
  name: Bear.CTXPM

agents:
  - generic
  - claude-code

dependencies:
  - name: ctxpm
    type: skill
    path: .ctxpm/dependencies/skills/ctxpm
    source:
      type: git
      url: https://github.com/gBearBest/Bear.CTXPM

packages:
  - name: ctxpm-release
    type: skill
    path: .ctxpm/packages/skills/ctxpm-release

  - name: ctxpm-source-boundary
    type: rule
    path: .ctxpm/packages/rules/ctxpm-source-boundary.md

The manifest's purpose is to write responsibilities down. An AI entering the repo later can tell which content follows upstream, which content the project answers for and which rules to read before touching source.

From one-off install to AI-run upkeep

Ordinary package managers make you remember commands, consult docs and trigger checks yourself. CTXPM turns those steps into a protocol an AI can follow. You can run the commands manually or pass them to the agent. Once a project has adopted the protocol, agents doing routine work will:

• find AI resources that aren't managed yet and ask whether to migrate them
• check for updates to external dependencies at sensible times
• confirm the manifest matches the real directories and repair entry symlinks automatically
• ask you when resources conflict or ownership is unclear

The AI isn't running fixed scripts. It understands the protocol's semantic boundaries and judges what to do, when, and whether to confirm first. detect and migrate deal with legacy resources through a read-only scan followed by your confirmation about what to move. check-updates and update are separated on purpose too: discover and report changes first, update after confirmation.

For ordinary external Git resources, CTXPM records the commit where the resource's path last changed, not necessarily the repository's newest HEAD. If a large repository only changes other directories, a dependent skill won't show a false upgrade, since the version matches the resource root actually installed.

Division of labor

The protocol comes first because a project can't count on a binary being present for an AI to understand its environment. Entry documents tell the AI where resources are stored, which ones are managed and which are scattered, where the boundaries of external dependencies lie and when to check them, which rules to read before an edit and which manifests to sync after it, and whether to ask or ignore when ownership is unclear.

Fixed steps suit the CLI: creating directories, repairing symlinks, installing dependencies, computing versions, finding unmanaged resources, validating manifests. Judgment calls belong to the AI: deciding who owns a resource, explaining risks, choosing whether to ask for confirmation, and handling migration conflicts. So the protocol sets the rules, the CLI keeps repeatable steps stable, and the AI handles whatever needs interpretation. You stay at the decision layer.

In practice, the AI scans the project for unmanaged resources, reads ctxpm.yaml for ownership and dependencies, checks upstream updates, fixes entry symlinks and loads resources by priority to save context. You decide whether scattered resources become packages or get marked as dependencies, whether to upgrade when a new version appears, and which rule wins when two conflict. That differs from npm install, where you remember the command and trigger it. Here the agent watches project state in the background while you code, review and debug, and speaks up only when it needs a decision.

Who benefits

A one-off AI demo probably doesn't need it. Long-lived projects tend to run into these situations:

• several agents must read one set of project rules
• teams want shared skills without copying them into every repository
• the project's own prompts, specs and memories need review next to the source
• external resources need known sources, versions and update boundaries
• old, scattered AI files need an inventory before migration

CTXPM won't write your prompts and has no opinion on which agent is smarter. It clarifies where resources belong, who owns them and how long they live, so AI workflows can be maintained along with the project.

Getting started

Give your agent this instruction:

Follow the guide at https://raw.githubusercontent.com/gBearBest/Bear.CTXPM/latest/INSTALL.md to inspect this project, set it up and restructure it so AI resources and dependencies are managed through Bear.CTXPM.

The agent identifies which agents and existing resources the project uses, prepares a project-local CLI and creates the directories and manifest. If ownership or migration questions come up, it stops and asks. From then on, ordinary work triggers background upkeep: finding scattered resources and asking whether to manage them, reporting dependency updates and waiting for approval, repairing symlinks, and reading the protocol to decide what to load.

If your project already has rules, skills, prompts or memories, setting boundaries early saves cleanup later. That's the step CTXPM focuses on: giving existing context a home and a known maintainer. The repository lives at https://github.com/gBearBest/Bear.CTXPM