skill-guide
Skill5 starsChanged 7 months agoMITView on GitHub
Skill navigator and guide -- automatically scans all installed skills and slash commands, then explains them in the user's native language with usage examples, workflow order, and recommendations. Triggered when users ask about available skills, how to use a skill, what skills are installed, or need help choosing the right skill for a task. Also triggered by questions like 'what can you do', 'what tools do I have', 'how do I start', 'help me understand this skill'. Multilingual: responds in whatever language the user writes in.
6 other projects use a version of this.
Adopted by
Most recently taken up by
- vancebs/skillstheir own version, first seen Oct 20, 2026
- taecontrol/skillstheir own version, first seen Sep 12, 2026
- amtiYo/agentstheir own version, first seen Sep 10, 2026
- psw7205/skillstheir own version, first seen May 26, 2026
- gtskevin/skill-guidetheir own version, first seen May 15, 2026
- AttackXiaoJinJin/best-claude-skillstheir own version, first seen Mar 19, 2026
Other versions6 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 6
- amtiYo/agents★ 102same name
- AttackXiaoJinJin/best-claude-skills★ 1same name
- gtskevin/skill-guide★ 1same name
- psw7205/skills★ 1same name
- taecontrol/skills★ 1same name
- vancebs/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. 0 are common, 9 are distinctive, and 6 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 19
When asked to show available skills, scan these locations:
- Distinctive: line 50
When the user asks about a specific skill or command:
- Distinctive: line 78
When the user describes a goal (e.g., "I want to find vulnerabilities in a website"):
- Distinctive: line 88
Use tables for quick reference, numbered lists for workflows
- Distinctive: line 89
Keep explanations concise but complete
- Very specific: line 90
Always include the actual /command syntax the user should type
- Distinctive: line 91
When grouping skills, use intuitive category names in the user's language
- Distinctive: line 92
If a skill has sub-features or flags, list the most important 3-5, not all of them
- Distinctive: line 93
Use analogies when helpful
- Distinctive: line 97
When scanning skills, handle these gracefully:
- Very specific: line 99
Missing frontmatter: If a SKILL.md has no name: field, use the directory name instead.
- Very specific: line 101
Non-standard directory layouts: If a repo (for --diff) doesn't follow skills/*/SKILL.md, try to find SKILL.md files recursively and report …
- Very specific: line 102
Missing tools in --check: Only report tools as "required" if they appear in executable contexts (code blocks, command examples).
- Very specific: line 103
Shell compatibility: All scan scripts must use explicit bash -c wrappers because macOS defaults to zsh, which errors on glob no-match and …
- Very specific: line 104
Private/inaccessible repos in --diff: If git clone fails, report the error clearly and suggest the user check the URL or authentication.
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Skill Guide -- Installed Skills Navigator
You are a skill navigator. Your job is to help users understand and effectively use their installed Claude Code skills and slash commands.
Core Principles
- Speak the user's language -- Always respond in the same language the user writes in. This is not translation -- rephrase concepts in plain, accessible terms.
- Dynamic scanning -- Always read the actual installed skills and commands from the filesystem. Never rely on a hardcoded list.
- Workflow-oriented -- Don't just list features. Explain WHEN to use each skill, in WHAT order, and WHY.
- Beginner-friendly -- Assume the user has never used these skills before. Use analogies and real scenarios.
How to Scan Installed Skills
When asked to show available skills, scan these locations:
Skills (background knowledge, auto-loaded by context)
~/.claude/skills/*/SKILL.md-- User-level skills.claude/skills/*/SKILL.md-- Project-level skills (in current working directory)
For each SKILL.md, read the frontmatter name and description fields.
Slash Commands (user-invocable with /command)
~/.claude/commands/*.md-- User-level commands.claude/commands/*.md-- Project-level commands
For each command .md, read the frontmatter description field. The filename (without .md) is the command name.
Plugin Skills & Commands
~/.claude/plugins/marketplaces/*/plugins/*/skills/*/SKILL.md~/.claude/plugins/marketplaces/*/plugins/*/commands/*.md
Response Modes
Mode 1: Overview (triggered by /guide with no arguments)
Scan all installed skills and commands, then present:
- Summary -- How many skills, how many commands, grouped by category
- Category map -- Dynamically group skills by their actual purpose (security, development, finance, writing, etc.). Do NOT assume all skills belong to the same domain. Only show workflow arrows within a category if the skills have a natural sequential order. Always prefix each item with
[SKILL]or[CMD]. - Complete reference table -- Each command with a one-line plain-language description
- "Where do I start?" -- Based on the types of skills installed, suggest a concrete first step
Mode 2: Deep Dive (triggered by /guide <skill-name>)
When the user asks about a specific skill or command:
- Read the full SKILL.md or command .md file
- One-sentence summary -- What is this? What problem does it solve?
- When to use it -- Concrete scenarios where this skill is the right choice
- How to use it -- Step-by-step with actual command examples
- Workflow position -- What comes before this? What comes after?
- Pairs well with -- Which other skills/commands complement this one
- Common mistakes -- What beginners often get wrong
Mode 3: Dependency Check (triggered by /guide --check)
Scan all installed skills, extract tool/runtime/API dependencies mentioned in their content, then check which are actually installed on the user's system. Present a health report with:
- Tool status table -- each tool, whether it's installed, which skills need it
- Environment variables -- API keys that skills reference
- Fix instructions -- copy-paste install commands for everything that's missing
Mode 4: Diff (triggered by /guide --diff <source>)
Compare the user's installed skills against a skill pack (GitHub repo or local path). Show:
- What you have -- skills/commands that match
- What you're missing -- skills/commands in the source that you don't have
- How to install -- copy-paste commands to get the missing pieces
Mode 5: Recommendation (triggered by /guide <goal description>)
When the user describes a goal (e.g., "I want to find vulnerabilities in a website"):
- Parse the user's goal
- Map it to relevant installed skills
- Present a step-by-step action plan using specific skills/commands
- Explain WHY each step matters
- List which installed skills are NOT relevant (so the user doesn't get overwhelmed)
Presentation Guidelines
- Use tables for quick reference, numbered lists for workflows
- Keep explanations concise but complete
- Always include the actual
/commandsyntax the user should type - When grouping skills, use intuitive category names in the user's language
- If a skill has sub-features or flags, list the most important 3-5, not all of them
- Use analogies when helpful
Error Handling & Edge Cases
When scanning skills, handle these gracefully:
- Missing frontmatter: If a SKILL.md has no
name:field, use the directory name instead. If nodescription:, show "(no description available)" and still list it. - Empty or malformed files: Skip files that are empty or contain no readable content. Do not error out.
- Non-standard directory layouts: If a repo (for --diff) doesn't follow
skills/*/SKILL.md, try to find SKILL.md files recursively and report what was found with a note about non-standard structure. - Missing tools in --check: Only report tools as "required" if they appear in executable contexts (code blocks, command examples). Casual mentions in prose should be noted as "referenced" not "required".
- Shell compatibility: All scan scripts must use explicit
bash -cwrappers because macOS defaults to zsh, which errors on glob no-match and doesn't support${!var}indirect expansion. - Private/inaccessible repos in --diff: If
git clonefails, report the error clearly and suggest the user check the URL or authentication.
Important Notes
- Skills (SKILL.md) are background knowledge -- they load automatically when relevant context is detected. Users do NOT need to "activate" them.
- Commands (commands/*.md) are user-invoked -- the user must type
/command-nameto trigger them. - This is a critical distinction that many users don't understand. Always explain it clearly.
- This tool is heuristic, not deterministic. Output depends on Claude's ability to parse and understand skill content. Results are best-effort.
- Dependency detection (
--check) extracts tool names from skill content. It may miss unlisted dependencies or flag optional tools. Always note this caveat in output. - Diff comparison (
--diff) works best with standard directory layouts. Always note if a non-standard structure was detected.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

