Labsco
bitwarden logo

action-audit

★ 121

by bitwarden · part of bitwarden/ai-plugins

Determine the mode from the user's request:

🔥🔥FreeQuick setup
#git
🧩 One of 7 skills in the bitwarden/ai-plugins package — works on its own, and pairs well with its siblings.

Determine the mode from the user's request:

Inspect the full instructions your agent will receiveExpand

This is the exact playbook injected into your agent when the skill activates — shown here so you can audit it before installing. You don't need to read it to use the skill.

name: action-audit description: > Audit GitHub Actions action usage across an org. Searches for a specific action (incident mode) or sweeps all workflow files for non-compliant action references (audit mode). Produces a read-only report of findings with compliance status and resolved SHAs. Does not modify any files.

<example> User: We need to check if any repos are using tj-actions/changed-files Action: Trigger action-audit in incident mode for that action </example> <example> User: Can you find all unpinned actions across the org? Action: Trigger action-audit in audit mode </example> allowed-tools: Read, Glob, Grep, Bash(gh search code:*), Bash(gh api:*) ---

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:

Copy & paste — that's it
gh search code "uses: <action-name>" --owner <org> --path .github/workflows/ --limit 100

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

Copy & paste — that's it
gh search code "<action-name>" --owner <org> --path .github/workflows/ --limit 100

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

Copy & paste — that's it
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:

RepoFileCurrent ReferenceTypePin StatusCompliant
..................

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:

Copy & paste — that's it
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:
Copy & paste — that's it
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:

RepoFileCurrent ReferenceTypeCompliantRemediation
..................

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.