安全审计
- 作者仓库星标 455
- 作者更新于 实时读取
- 作者仓库 console
- 领域
- 安全
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @openshift · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS · Linux · Windows
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-audit
description: Audit all Claude Code skills for stale references, broken paths, and deprecated tool names Audit…
category: 安全
runtime: 无特殊运行时
---
# skill-audit 输出预览
## PART A: 任务判断
- 适用问题:安全审计、密钥扫描、权限检查或风险分析。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于安全审计、密钥扫描、权限检查或风险分析,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/skill-audit`、`/deprecated`、`/skill-name`、`/plugin-api-review` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: skill-audit
description: Audit all Claude Code skills for stale references, broken paths, and deprecated tool names Audit…
category: 安全
source: openshift/console
---
# skill-audit
## 什么时候使用
- 把安全方向的常用动作沉淀成 Agent 可调用的技能 适合处理安全审计、密钥扫描、权限检查和风险分析,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤;通常不…
- 面向安全审计、密钥扫描、权限检查或风险分析,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "skill-audit" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} /skill-audit
Audit .claude/skills/ for drift: broken file paths, missing scripts, and deprecated tool names.
Instructions
Step 1: Discover Skill Files
Find all markdown files under .claude/skills/:
- All
SKILL.mdfiles - Companion files:
DOSSIER-TEMPLATE.md,REPORT-TEMPLATE.md, and any other.mdfiles
If $ARGUMENTS names a specific skill (e.g., test), only audit .claude/skills/$ARGUMENTS/.
Step 2: Extract and Verify File Path References
For each skill file, find references to files/directories. Look for:
- Backtick-quoted paths containing
/or ending in known extensions (.md,.sh,.ts,.tsx,.json,.js,.yaml,.yml) - Bare references to known doc files:
AGENTS.md,CLAUDE.md,STYLEGUIDE.md,TESTING.md,INTERNATIONALIZATION.md
For each path found:
- Resolve relative to the repo root
- If not found, try resolving relative to
frontend/ - Check if the file exists on disk
- Record any missing paths with the skill name, file, and line number
Skip:
- URLs (http/https)
- Glob patterns containing
* - Generic placeholder paths (e.g.,
path/to/Component.tsx,test-file.spec.tsx,<file>,src/feature.tsx) - Paths inside template variables (e.g.,
$ARGUMENTS,<package>)
Step 3: Verify @console/* Import Paths
Skills contain example import statements that reference real packages. Extract all @console/* import paths from import statements.
For each path:
@console/internal→ verify the subpath exists underfrontend/public/(e.g.,@console/internal/module/k8s→frontend/public/module/k8s)@console/shared→ verify the subpath exists underfrontend/packages/console-shared/(e.g.,@console/shared/src/test-utils/unit-test-utils→frontend/packages/console-shared/src/test-utils/unit-test-utils)@console/dynamic-plugin-sdk→ verify underfrontend/packages/console-dynamic-plugin-sdk/- Other
@console/*packages → verify a matching package exists infrontend/packages/
Report any import paths that don't resolve to real files.
Note on @console/internal: Some subpaths resolve through webpack aliases rather than direct filesystem paths. If a path under @console/internal does not resolve directly under frontend/public/, also check frontend/public/module/ and frontend/public/components/ as common alias targets. When a path cannot be verified through either method, report it as a warning rather than an error — it may be alias-resolved at build time.
Skip: Relative imports (../, ./) — these are example-specific and not verifiable without context.
Step 3a: Verify PatternFly Import Paths
Skills may reference PatternFly components in example code. Extract all @patternfly/* import paths.
For each path:
- Check whether the import uses a
/deprecatedsubpath (e.g.,@patternfly/react-core/deprecated) — report as a warning since these are slated for removal in future PF versions - Verify the package exists in
frontend/node_modules/@patternfly/(or checkfrontend/package.jsondependencies) - For specific component imports (e.g.,
@patternfly/react-core/dist/esm/components/Button), verify the path resolves
Skip: Generic PatternFly references in prose (e.g., "use PatternFly components") — only validate actual import statements.
Step 3b: Verify $codeRef and Exposed Module References
Skills may contain examples of console-extensions.json entries with $codeRef values, or reference exposed module patterns. For each $codeRef found:
- Parse the format
moduleName.exportName(e.g.,exampleFlag.handler) - If the skill references a specific plugin, check that plugin's
package.jsonfor a matching exposed module name underconsolePlugin.exposedModules - If a file path is associated with the exposed module, verify the file exists and exports the referenced name
Report unresolvable $codeRef examples as info — they may be intentionally generic illustrations rather than references to real code.
Step 4: Verify yarn/npm Script References
Extract all yarn <script> and npm run <script> references from each skill file.
Compare each script name against the scripts object in frontend/package.json. Report any that do not exist.
Skip: yarn built-in commands (install, add, up, npm info, why, --version).
Step 5: Verify Shell Script References
Extract references matching ./something.sh patterns. Verify each .sh file exists at the repo root. Report missing scripts with skill name and line number.
Step 6: Verify Claude Code Tool Name References
Skills may reference Claude Code tools by name (e.g., in instructions like "use the Read tool" or "call Grep"). Extract all words that appear to be tool references — look for capitalized names matching the pattern of Claude Code tool names, especially when preceded by words like "use", "call", "run", "the … tool", or appearing in backtick-quoted form.
Canonical tool names — self-maintaining approach:
Do NOT rely on a hardcoded list. Instead, introspect the tools available in the current session (they are listed in the system prompt as function definitions). Build the canonical set from those names at runtime. This ensures the audit stays current as Claude Code adds, renames, or removes tools.
As a fallback for known renames, maintain only the deprecated names table:
| Deprecated Name | Current Replacement |
|---|---|
TodoWrite |
TaskCreate |
TodoRead |
TaskGet / TaskList |
TodoUpdate |
TaskUpdate |
For each tool name found in a skill file:
- If it matches a deprecated name, report with the replacement
- If it looks like a tool reference (capitalized, backtick-quoted, or in a tool-context phrase) but does NOT match any tool available in the current session or any deprecated name, report it as an unrecognized tool name — it may be a typo or a tool that was renamed/removed
Skip:
- Tool names inside example code blocks that are clearly application code (not Claude Code instructions)
- MCP tool names (prefixed with
mcp__)
Step 7: Verify Hook Command Path References
.claude/settings.json and .claude/settings.local.json may contain hook definitions with shell commands that reference file paths (e.g., cat .claude/skills/..., bash .claude/scripts/...).
For each hook command:
- Extract file paths from the command string (look for paths starting with
.claude/,frontend/,./, or other repo-relative prefixes) - Verify each referenced path exists on disk
- Report missing paths with the hook name and the full command for context
Skip: Commands that don't reference local file paths (e.g., echo, date, inline scripts with no file references).
Step 8: Cross-Reference Skill Names in Project Config
Skills are referenced by name in CLAUDE.md, AGENTS.md (if present), STYLEGUIDE.md, TESTING.md, and .claude/settings.json / .claude/settings.local.json. Verify that every skill name mentioned in those files actually exists as a directory under .claude/skills/.
How to find skill references:
- Scan each config file for patterns like:
- Backtick-quoted names followed by "skill" (e.g.,
`gen-rtl-test` skill) /skill-nameslash-command invocations (e.g.,/plugin-api-review)- Skill names in settings.json hook commands or descriptions
- Backtick-quoted names followed by "skill" (e.g.,
- Build the list of actual skill directories:
ls .claude/skills/ - For each referenced skill name, check if a matching directory exists under
.claude/skills/ - Report any skill names that are referenced but have no corresponding skill directory
Also check the reverse direction:
- For each skill directory under
.claude/skills/, check whether it is referenced in any of the config files listed above - Report any skills that exist on disk but are never referenced anywhere — these may be orphaned or undiscoverable
Skip:
- Skill names that appear only inside their own SKILL.md (self-references)
- Generic words that happen to match skill names (use context to distinguish)
Step 9: Report Findings
Output a summary grouped by skill, using severity levels to help prioritize fixes:
| Severity | Meaning | Examples |
|---|---|---|
| ERROR | Broken reference that will cause the skill to malfunction or give wrong guidance | Deprecated tool name in executable instructions, missing file that the skill tells Claude to read, invalid script reference |
| WARN | Likely stale but not immediately breaking | /deprecated PatternFly import, @console/internal path that may be alias-resolved, orphaned skill not referenced in config |
| INFO | Worth noting but low priority | Unresolvable $codeRef in a generic example, self-referencing skill name |
## Skill Audit Report
### skill-name (SKILL.md)
- [PASS] File path references: all 5 verified
- [ERROR] Missing file: `path/to/missing.md` (line 42)
- [PASS] Script references: all 3 verified
- [ERROR] Deprecated tool: `TodoWrite` -> use `TaskCreate` (line 7)
- [WARN] PatternFly deprecated import: `@patternfly/react-core/deprecated` (line 23)
- [PASS] Tool name references: all verified
### another-skill (SKILL.md, DOSSIER-TEMPLATE.md)
- [PASS] All checks passed
### Hook Commands (.claude/settings.json)
- [ERROR] Hook `pre-submit`: path `.claude/scripts/validate.sh` not found
- [PASS] Hook `post-submit`: all paths verified
### Cross-Reference: Config → Skills
- [PASS] `gen-rtl-test` referenced in CLAUDE.md line 11 → exists
- [ERROR] `old-skill` referenced in STYLEGUIDE.md line 85 → missing from .claude/skills/
### Cross-Reference: Skills → Config
- [WARN] `microcopy-review` exists but is not referenced in any config file
---
Summary: N skills audited | N errors, N warnings, N info | N skills clean
Important Notes
- This skill is read-only — it never modifies any files
- Focus on verifiable facts (file exists, script exists, tool name matched) — do not review prose quality
- When a path is ambiguous, try both repo root and
frontend/directory - Use the severity levels consistently: ERROR for things that will mislead Claude or break skill execution, WARN for staleness that degrades quality, INFO for observations worth noting
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核