skill-audit
- Repo stars 455
- Author updated Live
- Author repo console
- Domain
- Security
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @openshift · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- macOS · Linux · Windows
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-audit
description: Audit all Claude Code skills for stale references, broken paths, and deprecated tool names Audit…
category: security
runtime: no special runtime
---
# skill-audit output preview
## PART A: Task fit
- Use case: Audit all Claude Code skills for stale references, broken paths, and deprecated tool names Audit .claude/skills/ for drift: broken file paths, missing scripts, and deprecated tool names. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Audit all Claude Code skills for stale references, broken paths, and deprecated tool names Audit .claude/skills/ for drift: broken file paths, missing scripts, and deprecated tool names. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/skill-audit`, `/deprecated`, `/skill-name`, `/plugin-api-review`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Start with a small task and check whether the result follows “Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skill-audit
description: Audit all Claude Code skills for stale references, broken paths, and deprecated tool names Audit…
category: security
source: openshift/console
---
# skill-audit
## When to use
- Audit all Claude Code skills for stale references, broken paths, and deprecated tool names Audit .claude/skills/ for d…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skill-audit" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Instructions / Step 1: Discover Skill Files / Step 2: Extract and Verify File Path References
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} /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
Decide Fit First
Design Intent
How To Use It
Boundaries And Review