Star16
9
代码
代码
Issues
Pull Requests6
项目讨论
Wiki
分析
Star16
9

Contributing a Plugin

Two ways in, matching the two tiers. Pick the one that fits.

Before you start

A plugin is a directory with a manifest plus asset folders:

my-plugin/
├── .atomcode-plugin/plugin.json   # manifest (name, version, asset paths)
├── README.md                      # what it does, how to use
├── skills/<skill>/SKILL.md        # a skill = frontmatter + markdown body
└── commands/<cmd>.md              # a slash command = a prompt template

Currently AtomCode loads skills and commands from plugins. Hooks parse but aren't executed from plugins yet; agents and MCP servers are not loaded from plugins yet. The validator will warn if your plugin's only assets are types the engine can't load today — don't ship those as verified until the engine catches up.

Skills and commands follow the same format AtomCode uses everywhere (Claude Code-compatible). A SKILL.md needs YAML frontmatter with at least name and description; a command .md is a prompt template that can use $ARGUMENTS, $1, ${CLAUDE_SKILL_DIR}, and !`shell` preprocessing.

Path A — Verified (source lives here)

Best for small, general-purpose, audited plugins.

  1. cp -r templates/plugin-template plugins/<your-plugin>
  2. Edit the manifest, README, and assets.
  3. Add a catalog entry to .atomcode-plugin/marketplace.json:
    {
  "name": "<your-plugin>",
  "source": "plugins/<your-plugin>",
  "description": "One line.",
  "tier": "verified",
  "version": "0.1.0",
  "keywords": ["..."],
  "author": { "name": "you", "url": "https://..." }
}
  4. python3 scripts/validate.py — must exit 0.
  5. Open a PR. A code owner reviews plugins/**; CI must be green.

By submitting verified, you agree your plugin is MIT-licensed like this repo, and that maintainers may edit or remove it.

Path B — Community (source stays in your repo)

Best when you want to keep ownership/release cadence in your own repo.

  1. Publish your plugin in your own git repository.
  2. Tag a release (or pick a commit) — you must pin it.
  3. Add a catalog entry pointing at it, with tier:"community":
    {
  "name": "<your-plugin>",
  "source": { "source": "github", "repo": "you/your-repo", "tag": "v1.0.0" },
  "description": "One line.",
  "tier": "community",
  "version": "1.0.0",
  "keywords": ["..."],
  "author": { "name": "you", "url": "https://github.com/you" }
}
    (source also accepts {"source":"url","url":"...","commit":"<sha>"} for non-GitHub hosts. A tag or commit is required — bare branches are rejected.)
  4. python3 scripts/validate.py — must exit 0.
  5. Open a PR. A maintainer reviews your pinned revision.

To ship a new version later, open a PR that bumps the tag/commit. We re-review at the new pin. We will not advance your pin for you, and users never auto-track your branch — see SECURITY.md.

Naming

name must match ^[a-zA-Z0-9._-]+$ and be unique in the catalog. Use a clear, specific name (commit-craft, not tools).

Checklist