[jacobpevans-claude]

Summary

• Removes the reusable workflows, scripts and tests that callers now take from JacobPEvans/.github (_ci-gate.yml, _flake-lock-fresh.yml, _release-please.yml and their helpers).
• Points the README and AGENTS.md at the JacobPEvans/.github workflows.
• Replaces chore: remove retired shared CI from the org .github repo #412 on a branch cut from current main.

Test plan

• Org code search finds no remaining caller of the removed workflows
• CI green

🤖 Generated with Claude Code

https://claude.ai/code/session_01WyipjowtZGZps1bYUGaNRk

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Inconsistent workflow reference The release-please workflow is referenced inconsistently within the same file. Lines 40, 60, and 104 refer to JacobPEvans/.github/.github/workflows/_release.yml@v1, while the README (line 115) and the "When in doubt" section (line 218) refer to _release-please.yml. This inconsistency will cause confusion for developers trying to wire up release automation or find the authoritative documentation. | Release automation | release-please | `JacobPEvans/.github/.github/workflows/_release.yml@v1` | | Dependency updates | Renovate | Policy mastered in `JacobPEvans/.github`; this repo's presets pass through to it | The canonical `biome.jsonc` and `.markdownlint-cli2.yaml` live in this repo. Repos copy biome/markdownlint at scaffold time; periodic sync is handled by Renovate's custom manager (or manual update for now — see the biome `customManagers` entry in `JacobPEvans/.github`'s `renovate-presets.json`). File-size defaults and their shared checker live in `JacobPEvans/.github` and are **not** copied. ### File-size gate (org defaults + per-repo overrides) Org-wide byte limits live in `JacobPEvans/.github` (`configs/file-size-defaults.yml`, enforced by `_file-size.yml`). **Do not add a repo-root `.file-size.yml` unless the repo needs `extended`, `exempt`, or `scan` overrides.** Never commit a `defaults:` block — that is global policy, not a per-repo knob. Split large files rather than widening org defaults. ## Release-please (org-native) Every dryvist repo runs release-please through the shared `JacobPEvans/.github/.github/workflows/_release.yml@v1` workflow. It opens the release PR for every bump type, which merges like any bot PR (below). A dryvist repo's `release-please.yml` caller forwards a single secret: | dryvist org secret | Reusable workflow secret | | --- | --- | | `GH_ACTION_RELEASE_PLEASE_PRIVATE_KEY` | `GH_ACTION_RELEASE_PLEASE_PRIVATE_KEY` | Auth is the dryvist release App: app-id from the `GH_ACTION_RELEASE_PLEASE_APP_ID` org variable, private key from the `GH_ACTION_RELEASE_PLEASE_PRIVATE_KEY` org secret. The App must be installed on the org with Contents + Pull requests write. (Owner sets these manually after installing the App; the agent should not attempt to install it. See `README.md` for setup steps.) ### Canonical release config The canonical `release-please-config.json` lives here at `configs/release-please-config.json` (single source of truth, same model as `biome.jsonc` / `.markdownlint-cli2.yaml`). Repos copy it; they only diverge when they **must**, and such deltas are intentional, e.g.: - `claude-code-plugins` adds `extra-files` to bump its many `plugin.json` versions. - Pre-1.0 / beta repos (e.g. `nix-ai-server`) add `bump-minor-pre-major: true` so breaking changes stay in the `0.x` range instead of auto-jumping to `1.0`. The reusable workflow also supports **config-free (non-manifest) mode** via its inputs (`release-type` + blank `config-file`/`manifest-file`) for repos that need no per-repo config at all; manifest mode (with the file above) is the default. Do not hand-tweak a repo's `release-please-config.json` away from canonical without a recorded reason. ## New repo checklist A repo that skips any of these is *born ungoverned*: org rulesets still bind it (they select every repo by name or custom property), but nothing else does. Work through this in order when creating a dryvist repo. 1. **Create it with its custom properties.** A bare `gh repo create` is rejected in this org — repo creation must supply the org's custom properties, including the `gitflow` boolean. Set `gitflow` to match the branching model you actually intend; the `org-gitflow-*` rulesets bind on that property, not on the default branch. 2. **Add release automation.** A thin `.github/workflows/release-please.yml` calling `JacobPEvans/.github/.github/workflows/_release.yml@v1` and