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:

gh search code "uses: <action-name>" --owner <org> --path .github/workflows/ --limit 100

Also search without the uses: prefix to catch indirect references:

gh search code "<action-name>" --owner <org> --path .github/workflows/ --limit 100

Audit mode — find all workflow files and extract uses: references:

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:

• Repo and file path
• Current uses: value (full line)
• Action type:
• internal — starts with bitwarden/
• third-party — all others (excluding local)
• 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
• 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:

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:

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.