repo-org-policy

Codex form of the /repo:org-policy command. Other commands appear as $repo-<verb> skills. Helper scripts and .claude/ paths below are relative to the repository root and exist when the Claude Code surface is installed alongside this one.

$repo-org-policy — Organization Preferences

Manage an organization's policy from any of its client repositories. The authoritative files live in rjwalters/repo, on its default branch:

• policies/default.json: shared defaults.
• policies/organizations/<lowercase-owner>.json: optional owner overrides.

Objects merge recursively; arrays and scalar values replace the shared value. Use the same convention for a personal GitHub account. Change preferences in the canonical source, then redeploy; organization copies and client installs are not independent sources of truth.

Usage

$repo-org-policy                     # Preview source, effective policy, and org drift
$repo-org-policy --check             # Same read-only report
$repo-org-policy --install           # Preview, then publish the authorized policy PR
$repo-org-policy --install --repo OWNER/PROJECT

The deterministic implementation is scripts/repo/repo-org-policy.py in the source checkout, installed to .claude/skills/repo/scripts/repo-org-policy.py. It needs Python 3.9+, git, and authenticated gh. It always uses github.com; other forges are unsupported. A local source checkout is not required on the client: the helper fetches canonical JSON at one immutable GitHub commit.

Preview and publish

1. Derive the client owner from origin, or use an explicitly supplied --repo OWNER/PROJECT. Display the target OWNER/.github: this operation affects shared organization policy, not just the invoking repository.
2. Run the helper's plan command. For --check, omit --output and stop after the report. An absent/inaccessible target is not proof that creation is needed; verify access first. The helper does that disambiguation itself (see "Absent versus inaccessible target" below) and reports which case its evidence favors — read its verdict rather than re-deriving it by hand, and treat a cannot tell which/inconclusive verdict as "still unverified". If creating .github is intended, establish public/private visibility and use --create-repository public|private. Shared policy contains no credentials. A public preset is easiest to reuse across public and private clients; private presets require appropriate app access and cannot be consumed from public repositories — so --create-repository private is refused when the invoking client is public, rather than producing an extends reference that fails at Renovate runtime. When the client's own visibility cannot be read, the helper warns instead of refusing; confirm it by hand before continuing.
3. For an install, save a plan at a new temporary path. Show its complete diff, source revision, target, and repository creation/visibility if applicable. Use existing authorization when it covers that target and these changes; otherwise request approval of this concrete plan. Do not repeatedly ask for steps already authorized. --install never authorizes unrelated settings, app installation, or migrating every client repository.
4. Apply that saved plan with --yes. It rechecks source and target before any mutation. A changed source or target requires a fresh preview. It preserves unrelated files, creates a separate branch, and opens a policy PR. A retry reuses an unchanged existing branch/PR; it never force-pushes. If repository creation succeeded but publishing failed, report that partial result and generate a fresh plan before continuing.
5. Report the PR URL and whether it is merged. The policy becomes active on the default branch after merge; opening a PR is not an installed policy. Follow the repository's normal merge workflow when merging is authorized. apply closes its own output with the next command for the invoking client ($repo-deps --install) and whether the organization PR still has to merge first — include that line in the report, and do not substitute a hand-written client renovate.json for it (that skips Dependabot reconciliation, ignorePaths for installer-owned roots, and security-PR ownership). The same closing line appears on a no-op apply, saying no organization PR is pending.
6. When the provider is the opt-in renovate (not the Dependabot default; see #655), every plan and apply invocation also prints a Renovate GitHub App installation line (see "Renovate App installation check" below) — include it verbatim in the final report. A Dependabot policy needs no App, so no such line is printed. For Renovate, a published/merged policy proves nothing about whether the App that reads it is actually installed on the target organization/user; treat "policy published" and "policy published, app NOT installed" as distinct outcomes, not the same success.