adam-s-daniel/acsi-coding-anywhere

Configure and enforce GitHub repository security settings as code: require actions to be pinned to full-length commit SHAs, require approval for all outside collaborators' fork pull-request workflow runs, and protect the default branch via a repository ruleset. The settings-as-code engine, its schema, and the fleet fan-out live in the repo-settings repo, which this skill points to; it also carries manual gh api recipes. Trigger when: setting up a new repo, running a security audit, onboarding a repo to org standards, enforcing settings across a fleet, or when asked to configure or harden Actions security settings. Trigger on mentions of "actions settings", "repo security settings", "repo settings as code", "settings drift", "fork approval", "outside collaborators", "actions policy", "branch protection", "ruleset", "harden repo", "actions event policy", or "pull_request_target policy".

Diagnose skill DELIVERY health for the current session: name the surface, diff the expected set in skills.lock against what actually loaded (the session's own skill listing, ~/.claude/skills/, the account synced/manifest.json, claude plugin list), attribute every skill to the registry and bundle it came from by reading the bootstrap hook's own install record rather than guessing, and flag silent shadowing and dangling payload references. Reports only — it never installs, copies, deletes or repairs anything. Use when a skill you expected is missing or won't trigger, when a repo-owned skill looks overridden, when the session-start skills: verdict reads DEGRADED, when you need to know where a skill came from or whether the hook installed it, or when the user says "why didn't that skill load", "which skills do I actually have", "is my registry stale", "audit my skills", "skills doctor".

File or rewrite GitHub issues that track how a vendor's or upstream project's release notes may affect your repos. Each issue covers one group of related changes for one affected repo, and carries exact quotes with release links and publish times, the files, pins or settings touched, the checks to run, and a fixed block for behavior that contradicts the notes. Use when asked to go through a CLI, SDK, agent, GitHub Action or library changelog and open issues for what affects you, or when a routine does. Not for reviewing a single dependency bump or Dependabot PR, or for writing your own project's release notes.

Audit GitHub Actions workflows for salient-path conditionals — every workflow that triggers on pull_request or push must filter on the files and directories its steps actually depend on, and skip with success when nothing salient changed. Use when adding a new workflow, modifying an existing one's steps, renaming/moving files a workflow depends on, or when a CI bill spike points at workflows running on irrelevant changes.