Small follow-ups from the reviews of the leak checks, CodeArtifact stub, adoption docs and skill #31

🤖 AI text below 🤖

Small findings from the reviews of the leak checks, the CodeArtifact stub, the adoption docs and the adopt-release-tools skill, triaged as able to wait.

Leak checks (tests/test_leaks.py, scripts/check_internal_names.py)

• tracked_files() raises on a tracked file deleted in the working tree but not staged (filter with is_file()).
• The two repository-wide tests each read every tracked file.
• The hook says "skipped" also when gh succeeds but lists no non-public repositories.
• json.loads sits outside the try: non-JSON output from gh crashes the hook (it fails closed).
• Paths git quotes (spaces, non-ASCII) are reported quoted.

CodeArtifact stub (examples/stubs/deploy-codeartifact.yml)

• No attest-build-provenance, unlike the PyPI stub: added in feat(examples): ✨ add a publish workflow for AWS CodeArtifact #27 (0dd0df2).
• TWINE_PASSWORD is exported from a shell variable (masked first) rather than passed in a step env: moot, the upload uses uv publish since feat(examples): ✨ add a publish workflow for AWS CodeArtifact #27 (0dd0df2).
• pipx run twine==7.0.0 pins twine but not its dependencies: moot, replaced by uv publish in feat(examples): ✨ add a publish workflow for AWS CodeArtifact #27 (0dd0df2).

Per-repository setup (docs/repository-setup.md, step 2)

• The warning about tag-push workflows sits only under the v0.0.0 case; tagging an untagged published version also pushes a tag.
• The history snippet leaves its temporary directory, and the worktree stays registered if git-cliff fails.

The skill (skills/adopt-release-tools/)

• Comparing inlined CodeArtifact values with the organisation variables happens only in publish-workflow.md and the PR description, not in the facts table and phase 2.
• gh release list reads 30 releases by default.
• The visibility row has no target for a public repository, and the introduction still says the adopting repository is private or internal.
• The old-process docs row covers only docs that say "create a release on GitHub"; widen it to any step of the old process (manual version bump, force upload, manual tag).
• An organisation ruleset handed to an owner has no matching done state; no guidance for rulesets with enforcement disabled or evaluate.
• The release/* checks rule covers branches-ignore only implicitly.
• Phase 4 step 1 relies on REPO being set in the admin's shell (it fails loudly), and payload paths assume the agent's machine (the content is shown alongside).
• The file-tool rule could name command substitution ($(cat <<'EOF' …)) as a heredoc too.
• The "Commands run that were not reads" ending is required of the phase 6 report only.

Follow-up of #29 (and #26–#28).