| name | adopt-repo |
| description | Integrate git-slop into a consumer repository through durable plugin source metadata, local configuration and wrapper conventions, and the advisory GitHub Action contract. Use when a user wants repository or CI adoption; use install-update instead when the outcome is only a native CLI installation. |
Adopt Git Slop In A Repository
Use this skill when a repository should start consuming git-slop.
Adoption Contract
- Add
git-slop Agent Plugin source metadata alongside any existing shared
workflow plugin sources. For Codex consumers, retain the stable
git-slop-marketplace distribution name while pinning a release that carries
the root Agent Plugins 1.0.0 plugin.json.
- Treat the published crates.io package as the canonical source identity for a
release. The Homebrew Formula installs that exact crate; a bottle is only its
faster prebuilt transport. The public Action and external Scoop bucket install
checksummed GitHub Release archives built from and verifiably bound to the
same crate; Scoop publishes only after trusted Windows x64 and ARM64
qualification.
- Verify that the intended version exists on crates.io and on the selected
distribution surface before pinning it. Until publication is confirmed,
describe that surface as pending rather than available.
- For local use, prefer a repo wrapper such as
./scripts/git_slop.sh and
require the native git-slop executable on PATH, usually from Homebrew on
macOS/Linux or Scoop on Windows.
- Pin the expected minimum CLI version in a repo-owned tool contract when the
consumer needs an explicit version gate.
- Verify installed release provenance with
git-slop build-info --format json.
Require the expected version and full source revision with
source_dirty: false; git-slop version alone is not a provenance proof.
- Commit
.slop/config.yaml when the repository intentionally configures Git
Slop, and commit .slop/.gitignore so generated state stays untracked.
- Do not commit
.slop/latest/, .slop/runs/, .slop/cache/, prompt packs,
SARIF exports, plan JSON, or compare JSON as routine adoption output.
- After the requested crates.io package, GitHub Release, and Action tag are
published, check out full history with
fetch-depth: 0, then use the exact
immutable coreycoto/git-slop@v<version> Action reference.
- Treat the Action's
source-revision, crate-sha256, and
release-manifest-sha256 outputs as distribution evidence. Its installer also
runs build-info --format json and rejects a binary that does not match the
release manifest's version and source revision.
- Keep the Action at its safe defaults initially: advisory policy, at most 10
annotations,
health.md-only artifact, 14-day retention, and no pull request
comment. Treat the experimental path-based surface ledger in the job summary
as review evidence, never as a composite score or gate. Reassess it after 10
pull requests and remove or consolidate it if it has not changed a reviewer
decision or its path dimensions routinely mislead.
- Preserve the Action sequence: install the verified binary; run
find once;
append its generated health.md and the Action's advisory surface-area
ledger to the job summary; render bounded annotations with health --format github; upload allowlisted artifacts and optionally update one pull request
comment; then run check only when policy: enforce. Advisory findings do
not fail, but setup, analysis, stable rendering, or publication failures do.
Experimental surface-ledger unavailability stays advisory and must be stated
in the job summary.
- Opt into
artifact-contents: report only for schema-5 automation. Do not
upload .slop/latest/ or .slop/runs/ as broad directories.
- Keep
git-slop observational until the repository explicitly promotes checks
into required gates with policy: enforce.
Minimal CI adoption after 0.16.1 and its matching release assets are published:
permissions:
contents: read
steps:
- uses: actions/checkout@v7
with:
fetch-depth: 0
- uses: coreycoto/git-slop@v0.16.1
