action-audit

规则

• 此技能严格为只读。 不要修改、创建或删除任何文件。
• 不得调用会修改数据的 API。 可自由使用 gh api GET 请求。不要使用 -X POST、-X PUT、-X PATCH 或 -X DELETE。
• 标明不确定之处。 如果某项发现存在歧义，请在报告中注明，不要猜测。

固定版本合规规则

在对任何操作引用进行分类之前，请先阅读 ${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md，并将 step_pinned 规则作为以下所有步骤的合规判定标准。该技能是判断合规与否的唯一依据。

模式

• incident（默认）：针对特定操作进行定向搜索，适用于操作遭到入侵或已弃用的情况。
• audit：全面扫描整个组织中的所有工作流文件，查找不合规的操作引用。

步骤 1：解析上下文

根据用户的请求确定模式：

• 如果用户指定了某个操作（例如 tj-actions/changed-files），请使用 incident 模式。
• 如果用户要求全面扫描未固定版本的操作，请使用 audit 模式。
• 如果提到了替代操作，请记下并在修复步骤中处理（由 action-remediate 技能另行负责）。

步骤 2：全组织搜索

Incident 模式 — 搜索指定操作：

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

同时搜索不带 uses: 前缀的内容，以查找间接引用：

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

Audit 模式 — 查找所有工作流文件并提取 uses: 引用：

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

然后，对每条引用应用 ${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md 中的 step_pinned 合规筛选规则。

注意： GitHub 代码搜索索引可能会在近期推送后延迟数分钟至数小时更新。搜索结果可能无法反映最新提交。请在输出中注明此限制。

步骤 3：解析并显示结果

对于每条 uses: 引用（不包括本地 ./ 路径），确定：

1. 仓库和文件路径
2. 当前 uses: 值（完整行）
3. 操作类型：
   • internal — 以 bitwarden/ 开头
   • third-party — 其他所有类型（本地路径除外）
4. 固定状态：
   • hash — 固定到完整的 40 位 SHA
   • tag — 固定到版本标签（例如 @v3、@v1.2.3）
   • branch — 指向命名分支（例如 @main、@master）
   • none — 未指定引用
5. 是否合规： 应用 ${CLAUDE_PLUGIN_ROOT}/skills/bitwarden-workflow-linter-rules/SKILL.md 中的 step_pinned 规则 — 合规标记 ✅，否则标记 ❌。

显示表格：

仓库	文件	当前引用	类型	固定状态	是否合规
...	...	...	...	...	...

在 incident 模式下，包含所有行。在 audit 模式下，省略合规（✅）的行。

如果没有发现不合规项，请告知用户并停止。

第 4 步：确定修复目标

根据操作类型和模式应用正确的修复方法。不要对所有不合规引用一视同仁。

事件模式 — 已提供替换操作：

如果用户在第 1 步提到了替换操作，不要解析受影响操作的 SHA，而应解析替换操作的 SHA：

gh api repos/<owner>/<repo>/commits/<ref> --jq '.sha'

向用户提供解析出的替换 SHA 和验证链接（https://github.com/<owner>/<repo>/commit/<sha>）。在最终确定前请用户确认。

内部操作（bitwarden/）：

• 预期的修复方式是将 ref 更改为 @main。无需解析 SHA。
• 如果操作当前使用的是 SHA，不要自动将其视为不合规——SHA 固定比 @main 限制更多，可能是有意为之（例如，在安全事件期间冻结，或为确保可复现性而固定）。请告知用户，并询问是否要将其更改为 @main，然后再将其列入修复清单。

第三方操作：

• 为每个唯一的不合规操作解析当前 SHA：

gh api repos/<owner>/<repo>/commits/<ref> --jq '.sha'

其中 <owner>/<repo> 是操作的仓库，<ref> 是目标标签或 main。

向用户提供：

• 解析出的 SHA
• 验证链接：https://github.com/<owner>/<repo>/commit/<sha>

询问：“这个 SHA 看起来正确吗？输入 yes 确认，或提供其他 SHA。”

等待用户确认后再完成报告。

在审计模式下，按唯一的第三方操作分组，每个操作只解析一次，而不是按出现次数解析。

第 5 步：汇总报告

输出最终汇总：

Repo	File	Current Reference	Type	Compliant	Remediation
...	...	...	...	...	...

Remediation 列应包含：

• 对于内部操作：change ref to @main
• 对于第三方操作：解析出的 40 位 SHA + 要添加的行内注释（例如，@abc123...def456 # v4.1.1）

告知用户，他们可以使用 action-remediate skill，根据这些发现应用修复。