workflow-audit

name	workflow-audit
description	Run the Bitwarden workflow linter (bwwl) against one or more repos and report findings. Strictly read-only — does not modify any files. Categorizes findings as mechanical or judgment using the bitwarden-workflow-linter-rules skill. Supports single repo, multiple repos, or single file/directory scope. <example> User: Run the workflow linter on the server repo Action: Trigger workflow-audit for that repo </example> <example> User: Lint the workflows across server, clients, and android Action: Trigger workflow-audit in multi-repo mode </example>
allowed-tools	Read, Glob, Grep, Skill, Bash(bwwl:*)

Rules

• This skill is strictly read-only. Do not modify, create, or delete any files.
• Flag uncertainty. If a finding is ambiguous, note it in the report rather than guessing.

Step 1: Verify Prerequisites

Check if bwwl is available:

bwwl --version

If the command is not found, stop and inform the user that bwwl must be installed before continuing. Do not attempt to install it.

Step 2: Determine Scope

Parse the user's request to determine what to lint:

• Single file or directory (e.g., .github/workflows/build.yml or .github/workflows/): Operate on the current repo only.
• Multiple repos (e.g., "server, clients, android"): Operate on each repo sequentially. Ask the user for the base directory where their repos are cloned. For each repo, look for its local clone at <base-dir>/<repo>. If a clone is not found, inform the user and skip that repo.
• No specific target: Lint all files in .github/workflows/ of the current directory.

Step 3: Run the Linter

For each repo in scope, run:

bwwl lint -f .github/workflows/

Capture both stdout and stderr. If operating on multiple repos, announce which repo is being linted.

Step 4: Parse and Categorize Findings

From the linter output, produce a structured list of findings. Group by file and rule. Consult the bitwarden-workflow-linter-rules skill to categorize each finding:

Mechanical (can be auto-fixed):

• name_capitalized, permissions_exist, pinned_job_runner, step_pinned, underscore_outputs, job_environment_prefix, check_pr_target
• Simple run_actionlint findings (single-line shell fixes)

Judgment (requires user input):

• name_exists, step_approved, complex run_actionlint findings

Step 5: Report

Output a summary table per repo:

File	Finding	Rule	Category
...	...	...	...

Include totals: mechanical findings, judgment findings, and repos with no issues.

Inform the user that they can use the workflow-fix skill to apply fixes based on these findings.