action-audit

## Rules - **This skill is strictly read-only.** Do not modify, create, or delete any files. - **No mutating API calls.** `gh api` GET requests are allowed freely. Do not use `-X POST`, `-X PUT`, `-X PATCH`, or `-X DELETE`. - **Flag uncertainty.** If a finding is ambiguous, note it in the report rather than guessing. ## Pin Compliance Rules Before classifying any action reference, read `${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md` and apply the `step_pinned` rule as the compliance definition for all steps below. That skill is the single source of truth for what is and is not compliant. ## Modes - **`incident`** (default): Targeted search for a specific action — used when an action is compromised or deprecated. - **`audit`**: Sweep all workflow files org-wide for any non-compliant action references. ## Step 1: Parse Context Determine the mode from the user's request: - If the user names a specific action (e.g., `tj-actions/changed-files`), use **incident** mode. - If the user asks for a general sweep of unpinned actions, use **audit** mode. - If a replacement action is mentioned, note it for the remediation step (handled separately by the `action-remediate` skill). ## Step 2: Search Org-Wide **Incident mode** — search for the specific action: ```bash gh search code "uses: <action-name>" --owner <org> --path .github/workflows/ --limit 100 ``` Also search without the `uses:` prefix to catch indirect references: ```bash gh search code "<action-name>" --owner <org> --path .github/workflows/ --limit 100 ``` **Audit mode** — find all workflow files and extract `uses:` references: ```bash gh search code "uses:" --owner <org> --path .github/workflows/ --limit 100 ``` Then apply the `step_pinned` compliance filter from `${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md` to each reference. > **Note:** GitHub code search indexes can lag by minutes to hours after a recent push. Results may not reflect the very latest commits. Flag this caveat in the output. ## Step 3: Parse and Display Results For each `uses:` reference (excluding local `./` paths), determine: 1. **Repo** and **file path** 2. **Current `uses:` value** (full line) 3. **Action type:** - `internal` — starts with `bitwarden/` - `third-party` — all others (excluding local) 4. **Pin status:** - `hash` — pinned to a full 40-char SHA - `tag` — pinned to a version tag (e.g., `@v3`, `@v1.2.3`) - `branch` — pointing to a named branch (e.g., `@main`, `@master`) - `none` — no ref at all 5. **Compliant:** Apply the `step_pinned` rule from `${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md` — ✅ if compliant, ❌ otherwise. Display a table: | Repo | File | Current Reference | Type | Pin Status | Compliant | | ---- | ---- | ----------------- | ---- | ---------- | --------- | | ... | ... | ... | ... | ... | ... | In `incident` mode, include all rows. In `audit` mode, omit compliant (✅) rows. If there are no non-compliant findings, inform the user and stop. ## Step 4: Resolve Remediation Targets Apply the correct fix approach based on action type and mode. Do **not** treat all non-compliant references the same way. **Incident mode — replacement action provided:** If the user mentioned a replacement action in Step 1, do not resolve a SHA for the compromised action. Instead, resolve the SHA for the replacement action: ```bash gh api repos/<owner>/<repo>/commits/<ref> --jq '.sha' ``` Present the resolved replacement SHA and a verification link (`https://github.com/<owner>/<repo>/commit/<sha>`) to the user. Ask for confirmation before finalizing. **Internal actions** (`bitwarden/`): - The expected fix is to change the ref to `@main`. No SHA resolution needed. - If the action is currently on a SHA, do not automatically treat this as non-compliant — a SHA pin is more restrictive than `@main` and may be intentional (e.g., frozen during a security incident or pinned for reproducibility). Inform the user and ask whether to change it to `@main` before including it in the remediation list. **Third-party actions:** - Resolve the current SHA for each unique non-compliant action: ```bash gh api repos/<owner>/<repo>/commits/<ref> --jq '.sha' ``` Where `<owner>/<repo>` is the action's repo and `<ref>` is the target tag or `main`. Present to the user: - Resolved SHA - Verification link: `https://github.com/<owner>/<repo>/commit/<sha>` Ask: "Does this SHA look correct? Type `yes` to confirm, or provide a different SHA." Wait for confirmation before finalizing the report. > In **audit mode**, group unique third-party actions and resolve each once rather than per-occurrence. ## Step 5: Summary Report Output a final summary: | Repo | File | Current Reference | Type | Compliant | Remediation | | ---- | ---- | ----------------- | ---- | --------- | ----------- | | ... | ... | ... | ... | ... | ... | The **Remediation** column should contain: - For internal actions: `change ref to @main` - For third-party actions: the resolved 40-char SHA + inline comment to add (e.g., `@abc123...def456 # v4.1.1`) Inform the user that they can use the `action-remediate` skill to apply fixes based on these findings.