arcships plugins

Plugin marketplace catalog for arcships agent plugins, serving Claude Code (.claude-plugin/marketplace.json) and Codex (.agents/plugins/marketplace.json) from the same repo.

This repo contains catalogs only — no plugin content. Each entry points at the plugin's home repo via a git-subdir source, so installing a plugin sparse-fetches just that plugin's directory: neither this catalog nor an install ever brings a plugin's full source tree onto your machine.

Install

Claude Code — inside a claude session:

/plugin marketplace add arcships/plugins
/plugin install opendoc@arcships

Codex — in your terminal:

codex plugin marketplace add arcships/plugins
codex plugin add opendoc@arcships

Update

Claude Code refreshes added marketplaces in the background automatically, so plugin updates normally arrive on their own. To pull one immediately:

/plugin marketplace update arcships

then /reload-plugins (or start a new session) to switch the running session to the new version.

Codex — refresh the marketplace first, then re-add the plugin to install the new version:

codex plugin marketplace upgrade arcships
codex plugin add opendoc@arcships

After an update, expect a one-time re-download of a plugin's engine binary (if it ships one, like opendoc): binaries aren't part of the plugin package, and an update installs into a fresh directory. The skill notices and re-offers the checksum-verified download on next use. Codex users who set up opendoc's scheduled sync should also re-run opendoc schedule afterwards — the launchd job points at the old version's absolute path.

Plugins

Plugin	What it does	Home
opendoc	One-way mirrors your authorized Notion/Feishu docs into a local, read-only Markdown tree that agents search directly with Grep/Glob/Read — no API, no credentials, no network at query time.	arcships/open-doc-cli

Release / versioning convention (maintainers)

Catalog entries track each plugin's home repo via ref, which sets what an update delivers:

• Once the home repo cuts releases, bump the ref to the release tag (e.g. v0.2.0, optionally with a sha pin) in both catalog files here. That commit is the publish action: this repo's git history doubles as the release log, users only ever move between pinned releases, and installs stay reproducible.