github

github

A Claude Code plugin for the GitHub settings/admin plane: audit, review, advise, and guided setup/management for the authenticated user across organizations, repositories, and enterprises. It covers consistency, drift, standards conformance, and cost control.

Everything is grounded at runtime: live state comes from the consumer's own gh CLI session, and mechanics come from freshly fetched official GitHub documentation. The plugin ships zero vendored GitHub knowledge: no endpoint tables, scope lists, or prices, so it cannot go stale against GitHub's weekly-moving surface. Where a fetch fails or an area is out of the current credential's reach, the skills say so honestly instead of guessing.

Skill	Status	What it does
/github:audit <area…> [--apply]	shipped	Read-only findings over one, several, or all coverage areas: current-state review, drift vs declared conventions, standards conformance, cost signals.
/github:advise <topic> [--apply]	shipped	Forward-looking guidance and hand-holding ("how should I configure X", "walk me through Y"), plus proactive in-session suggestions.
/github:setup	shipped	Verify prerequisites (gh present and authenticated, config layers) and write consumer config. check and apply, user-invoked only.

Areas are arguments, not skills. The coverage matrix (rulesets, billing, security model, Actions policy, webhooks, packages, and the rest) lives in reference/areas.md, and every area routes through the same reference/method-ladder.md. Primary-tier areas additionally carry a dedicated method recipe under reference/recipes/. Those recipes hold curated audit checklists, drift procedures, and posture heuristics, still with zero vendored GitHub mechanics.

Verb contract

This plugin follows the marketplace verb grammar: audit is a read-only findings report. A bare invocation performs zero mutations (no write-capable gh api flags, no non-GET methods, no GraphQL mutations). It additionally declares one new verb at this coupling site:

• advise is read-only advisory guidance. Distinct discovery intent from audit: design/forward-looking ("how should I…") where audit is current-state/backward-looking ("what is…", "what drifted…").

Mutation is only ever reachable behind the explicit --apply override argument, resolves through the consumer's declared change routing (the --apply resolution flow in reference/change-routing.md), and keeps the user in the loop for every write.

Prerequisites

• gh CLI, authenticated by you. The plugin uses your own gh session and never stores credentials. When a token scope or credential modality cannot reach an area, the skill names the gate and recommends the remediation for you to run yourself.

Consumer configuration

Unconfigured consumers work read-only out of the box: change routing defaults to propose-only (proposed changes are emitted as exact commands or diffs, never executed). Consumer config lives in .claude/github/ and layers user-global → team → local overlay:

• reference/change-routing.md. routing.yaml: how proposed changes leave the session (propose / guided-apply / handoff), with a team policy floor on write-posture keys that personal layers can tighten but never loosen.
• reference/conventions-file.md. conventions.md: the declared standards your audits compare against.

For settings surfaces that turn out to be UI-only (no CLI, no API), the skills may offer opt-in browser automation over your own authenticated session. Never auto-fired, every action individually confirmed, mechanics in reference/browser-automation.md. One plugin setting, offer_browser_automation (boolean, default true, prompted when you enable the plugin), suppresses the offer when false. That is an advisory gate honored by the skills, not a runtime kill-switch; the hard gate is the per-action user confirm. Guided manual steps with a deep link remain the always-available fallback.

/github:setup writes both files interactively and recommends the one-line recursive overlay gitignore (.claude/**/*.local.*); it never edits your .gitignore.

Install

From whichever marketplace distributes this plugin:

/plugin marketplace add <marketplace-owner>/<marketplace-repo>
/plugin install github@<marketplace-name>

Configuration

Options reference

Generated from this plugin's .claude-plugin/plugin.json. Every option Claude Code will prompt for when the plugin is enabled, with the environment variable each hook reads it from.

Option	Type	Default	Environment variable	Description
offer_browser_automation	boolean	true	CLAUDE_PLUGIN_OPTION_OFFER_BROWSER_AUTOMATION	When a settings surface is UI-only, offer opt-in browser automation (never auto-fired; every action individually confirmed). Set false to suppress the offer entirely. Advisory: honored by the skills' prose, layered under the per-action confirm.

How to set these

Three supported routes, in the order most people want them:

1. Interactively. Claude Code prompts for declared options when you enable the plugin. To change them later: /plugin configure github@<marketplace>.

2. Headless. Repeat --config for each option. Replace <marketplace> with the marketplace you installed this plugin from:

   claude plugin install github@<marketplace> -s <scope> --config offer_browser_automation=<value>

   The same command reconfigures a plugin that is already installed: it prints already installed and still writes the value. The short-circuit message is about the install, not the config write. Do not claude plugin uninstall to reconfigure: uninstalling drops this plugin's whole stored pluginConfigs entry, resetting every option in the table above to its default. -s defaults to user, so pass the scope claude plugin list reports for this plugin. The verified-version record lives in this marketplace's plugin-reconfiguration convention (docs/conventions/plugin-reconfiguration/README.md).

   The value is stored immediately; the session you are in does not change. Hooks are handed their CLAUDE_PLUGIN_OPTION_* when the session starts, so start a fresh Claude Code session before expecting new behavior. A check run in the old session still reports the old value, and that is not a failed write.

3. By hand, in settings. Add the value under pluginConfigs in your user settings (~/.claude/settings.json):

   {
     "pluginConfigs": {
       "github@<marketplace>": {
         "options": {
           "offer_browser_automation": <value>
         }
       }
     }
   }

   Plugin option values are read from user, --settings, and managed settings only, not from a project's .claude/settings.json. To vary behavior per repository, enable or disable the plugin in that project's enabledPlugins instead of setting an option there.

Do not set the CLAUDE_PLUGIN_OPTION_* variables yourself. They are how Claude Code hands a configured value to a hook process; the value comes from the routes above.

Upstream documentation

• User configuration: the userConfig schema and the CLAUDE_PLUGIN_OPTION_<KEY> export
• Plugin install options: the --config flag's reference entry
• Plugins and skills settings: enabledPlugins, extraKnownMarketplaces, pluginConfigs
• Settings files and who they affect: user vs project vs local precedence
• Manage installed plugins: enabling, disabling, /plugin list