RepoMan

RepoMan runs automated maintenance programs (PR review, link health, dependency bumps, weekly reports, repo sync, doc drift) across a set of GitHub repos you enroll once. It handles the capability checks and output wiring for you, so you install once and enable programs on the fly.

/repoman is a single intent-dispatching entrypoint: it reads your ~/.repoman/ state and your message and infers whether you are setting up, enabling a program, or running one.

Built to the Agent Skills specification.

Installation

Claude Code (plugin marketplace)

/plugin marketplace add rossoctl/repoman
/plugin install repoman@rossoctl-repoman

That one install is the whole system — the repoman plugin is self-contained: it bundles the /repoman entrypoint, every program skill (scanner and fixer), and the engine scripts. Enabling more programs later needs no further installs.

Updating

Refresh the marketplace and update the plugin (a Claude Code restart applies updates):

/plugin marketplace update rossoctl-repoman
/plugin update repoman@rossoctl-repoman

Updating repoman refreshes the bundled engine too, so engine fixes reach every user through a single plugin update.

A single program (standalone skill)

Each program is also published as its own standalone plugin in the same marketplace, so you can install just one without the full repoman bundle or its /repoman entrypoint:

/plugin marketplace add rossoctl/repoman
/plugin install github-pr-review@rossoctl-repoman

Swap github-pr-review for the plugin id of any program — run /plugin after adding the marketplace to see the authoritative list. The ids mostly match the Programs table, except the GitHub-facing ones carry the github- prefix: github-pr-review and github-weekly-report (the table lists them as pr-review and weekly-report). Installing a single program is the right choice for a one-off, chat-driven run (for example reviewing a single PR) or for calling an RM program from an external script, where the /repoman entrypoint isn't needed.

Installing a single program skips the /repoman entrypoint, but most programs still need their own inputs at run time: github-pr-review and github-weekly-report act on a repo you name directly, while link-health, dep-bump, repo-sync, and automation-health read the enrolled set from ~/.repoman/repos.json and ~/.repoman/config.json (created by repoman-setup.sh) and fail loud without them. Each program's SKILL.md lists its prerequisites.

Programs

The repoman bundle ships these programs, each ready to enable:

Program	What it does
repoman	The entrypoint: first-time setup, enabling a program, enrolling repos or an org, running a program across enrolled repos
link-health	Scan repos for broken links and file issues (fixer re-verifies and opens fix PRs)
dep-bump	Monitor Dependabot PRs, classify by severity, flag SLA breaches (fixer posts commentary to accelerate review)
pr-review	Automated PR review: conventions, security, CI status, inline comments
repo-sync	Keep local clones of enrolled repos current; read-only toward GitHub
automation-health	Generate an executive-facing dashboard combining all program metrics
weekly-report	Weekly org activity reports with merged PRs, CI health, and active-epic tracking
doc-drift	Scan repos for documentation drift and draft changelog notes from merged PRs (fixer re-verifies and opens mechanical doc fix PRs)

Every program also works as a standalone skill — usable on its own, without the /repoman entrypoint. This supports LLM chat-based one-off runs of a single program (for example a one-off PR review) and scriptable RM program calls from external tooling. (The link-health, dep-bump, repo-sync, and automation-health programs still read their enrolled repo set from ~/.repoman/ even when run standalone, and fail loud without it — see each program's SKILL.md.) See A single program (standalone skill) for how to install one.

Prerequisites

• bash 3.2+ — runs on the macOS system default; no bash-4 features are used.
• gh (GitHub CLI, authenticated with org access)
• jq

Individual programs may have additional requirements documented in their SKILL.md.

Development

RepoMan is developed across three repositories:

Repository	Role
rossoctl/automation	Engine source of truth: the flat scripts in scripts/, plus tests and specs. All engine changes are made and tested there first.
rossoctl/agent-skills	Skills designed to work standalone as well as with RepoMan.
rossoctl/repoman (this repo)	Distribution (rossoctl-repoman marketplace) and the canonical home for RepoMan-specific SKILL.mds. The engine is not authored here.

See the [CHANGELOG.md](https://github.com/rossoctl/repoman/blob/main/CHANGELOG.md) for release history.

Contributor workflow

1. Place the work. A skill that is useful on its own → author it in agent-skills. A RepoMan-specific program (keeps state under ~/.repoman) → deterministic scripts in automation, SKILL.md in this repo. New programs start from automation's docs/program-template.md. A new program also needs repoman-side wiring that is not engine code: a .claude-plugin/marketplace.json entry, a row in the README ## Programs table, and the program → skill mapping in skills/repoman/SKILL.md.
2. Test in automation, next to the existing tests in tests/. Bash 3.2 only: no mapfile, no associative arrays, BSD fallbacks for GNU-only flags. If the skill writes to ~/.repoman, give its SKILL.md a machine-readable ### Requirements block so repoman-check.sh can gate the run.
3. Keep real state out of test runs. Point REPOMAN_CONFIG_FILE / REPOMAN_REPOS_FILE at scratch files; never hand-edit ~/.repoman (repoman-setup.sh is its only writer); drive first runs through repoman-run.sh <program> owner/repo --dry-run and drop --dry-run only once the output looks right.
4. Vendor the engine into this repo (below) — a new engine script must be added to both the vendor manifest and its test fixture in tests/test-vendor-engine.sh, including the expected counts — then run that test. To try the plugin without reinstalling from the marketplace: claude plugin marketplace add <this-repo> then claude plugin install repoman@rossoctl-repoman.
5. Before the PR: git config core.hooksPath scripts/hooks, sign off with git commit -s (DCO), use a conventional title, one purpose per PR.

Vendoring the engine

Both skills/repoman/scripts/ (the plugin bundle) and the standalone skills/{link-health,dep-bump}-{scanner,fixer}/scripts/ dirs are generated output — vendored copies of the automation engine, each stamped with its source commit in a _vendor.json. Never edit those files directly: an in-place fix bypasses automation's tests and is silently overwritten on the next vendor. To pick up engine changes, run the vendor script from this repo against a clean automation checkout — the stamp records the source HEAD SHA, so vendoring uncommitted changes would produce a stamp that does not match the copied bytes (the script rejects a dirty source unless --allow-dirty is passed):

# The plugin bundle:
scripts/vendor-engine.sh --source <path-to-automation-checkout> \
  --dest skills/repoman/scripts

# The standalone skill dirs:
scripts/vendor-engine.sh --source <path-to-automation-checkout> \
  --skills skills

The two modes are mutually exclusive. Each copies an explicit manifest (never a glob): --dest populates only the plugin dir, and --skills populates only the listed standalone skill dirs with the modular lib set plus each skill's own scripts — so the script only ever writes the paths its manifests name. Both pre-validate the whole source set before copying anything and rewrite each _vendor.json with the automation HEAD SHA vendored from. tests/test-vendor-engine.sh is the regression test for both modes.

License

Apache-2.0. See LICENSE.