tooling-discovery
Use when looking for available tools, MCP servers, or CLI utilities for a task. Triggers: 'what tools do I have', 'is there an MCP for this', 'what's available', 'find a tool for', 'discover tooling', 'what CLI tools exist'. NOT for: documenting existing tools (use documenting-tools).
Best use case
tooling-discovery is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use when looking for available tools, MCP servers, or CLI utilities for a task. Triggers: 'what tools do I have', 'is there an MCP for this', 'what's available', 'find a tool for', 'discover tooling', 'what CLI tools exist'. NOT for: documenting existing tools (use documenting-tools).
Teams using tooling-discovery should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/tooling-discovery/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How tooling-discovery Compares
| Feature / Agent | tooling-discovery | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use when looking for available tools, MCP servers, or CLI utilities for a task. Triggers: 'what tools do I have', 'is there an MCP for this', 'what's available', 'find a tool for', 'discover tooling', 'what CLI tools exist'. NOT for: documenting existing tools (use documenting-tools).
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Tooling Discovery
<ROLE>
Tool Scout. Your job is to surface every relevant tool for the user's domain, with clear trust classification so they can make informed decisions.
</ROLE>
## Invariant Principles
1. **Registry is source of truth.** Only recommend tools that exist in the curated YAML registry. Never fabricate tool entries.
2. **Trust tiers are non-negotiable.** Always present trust classification. Tier 4+ tools require explicit risk warnings before recommendation.
3. **Detection before recommendation.** Always run the tooling_discover MCP tool to check availability. Do not skip detection and guess.
## Workflow
### Step 1: Determine Domain Keywords
<analysis>
Before calling the discovery tool, analyze the user's request to extract domain keywords:
- What technology area is being discussed?
- What keywords would match the registry domains?
- Is there project context (language, framework) that adds implicit keywords?
</analysis>
Extract domain keywords from one of:
1. User's explicit request (e.g., "what tools exist for Jira integration?")
2. Current project context (language, framework, key dependencies)
3. Active feature being developed (technologies mentioned)
Combine into a comma-separated keyword string.
### Step 2: Call tooling_discover
```
tooling_discover(
domain_keywords="<comma-separated keywords>",
project_path="<project root or empty for auto-detect>"
)
```
### Step 3: Present Results
<reflection>
After receiving results, reflect:
- Are the matched domains relevant to the user's actual need?
- Are there available tools that the user might not know about?
- Are there any tier 4+ tools that need trust warnings?
- Did the detection summary reveal unexpected findings?
</reflection>
Group results by availability and trust:
**Available Tools** (detected on this system):
- List tools where `available: true`, grouped by detection method
- For each: name, type, trust tier label, description, how detected
**Registry Tools** (known but not detected):
- List tools where `available: false`
- For each: name, type, trust tier label, description, source URL
**Trust Warnings** (tier 4+):
- For any tool with trust_tier >= 4, prominently display risks and next_steps
### Step 4: Suggest Integration
For available but potentially unused tools:
- Suggest how to leverage them in the current workflow
- For MCP servers: note they are already connected
- For CLIs: note they can be called via Bash tool
- For libraries: note they are already in project dependencies
<FORBIDDEN>
- Recommending tier 5-6 tools without displaying trust warnings
- Skipping the availability check (always call the MCP tool)
- Making up tools not in the registry
</FORBIDDEN>Related Skills
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment. Triggers: 'write a skill', 'new skill', 'create a skill', 'skill doesn't work', 'skill isn't firing', 'edit skill', 'skill quality'. NOT for: general prompt improvement (use instruction-engineering) or command creation (use writing-commands).
writing-plans
Use when you have a spec, design doc, or requirements and need a detailed implementation plan before coding. Triggers: 'write a plan', 'create implementation plan', 'plan this out', 'break this down into steps', 'convert design to tasks', 'implementation order'. Also invoked by develop during planning. NOT for: reviewing existing plans (use reviewing-impl-plans).
writing-commands
Use when creating new commands, editing existing commands, or reviewing command quality. Triggers: 'write command', 'new command', 'create a command', 'review command', 'fix command', 'command doesn't work', 'add a slash command'. NOT for: skill creation (use writing-skills).
verifying-hunches
Use when about to claim discovery during debugging. Triggers: "I found", "this is the issue", "I think I see", "looks like the problem", "that's why", "the bug is", "root cause", "culprit", "smoking gun", "aha", "got it", "here's what's happening", "the reason is", "causing the", "explains why", "mystery solved", "figured it out", "the fix is", "should fix", "this will fix". Also invoked by debugging, scientific-debugging, systematic-debugging before any root cause claim.
using-skills
System skill loaded at session start to initialize skill routing. Not invoked directly by users. Also useful when: 'which skill should I use', 'what skill handles this', 'wrong skill fired', 'skill didn't trigger'.
using-lsp-tools
Use when mcp-language-server tools are available and you need semantic code intelligence. Triggers: 'find definition', 'find references', 'who calls this', 'rename symbol', 'type hierarchy', 'go to definition', 'where is this used', 'where is this defined', 'what type is this'. Provides navigation, refactoring, and type analysis via LSP.
using-git-worktrees
Use when starting feature work that needs isolation from current workspace, or setting up parallel development tracks. Triggers: 'worktree', 'separate branch', 'isolate this work', 'don't mess up current work', 'work on two things at once', 'parallel workstreams', 'new branch for this', 'keep my current work safe'.
testing-strategy
Test selection strategy and scope guidance. Triggers: 'which tests should I run', 'test tiers', 'test marks', 'slow tests', 'integration vs unit', 'cross-module regression', 'test scope', 'what should I run', 'select tests', 'test batching'. NOT for: writing tests (use test-driven-development) or fixing broken tests (use fixing-tests).
test-driven-development
Use when user explicitly requests test-driven development. Triggers: 'TDD', 'write tests first', 'red green refactor', 'test-first', 'start with the test'. Also invoked by develop and executing-plans for implementation tasks. NOT for: full feature work (use develop, which includes TDD internally).
tarot-mode
Use when session returns mode.type='tarot', user says '/tarot', or requests roundtable dialogue with archetypes. Triggers: '/tarot', 'use tarot mode', 'roundtable with archetypes', 'tarot personas'. Session-level mode, not task-level.
smart-reading
Behavioral protocol for reading files or command output of unknown size. Loaded automatically for all file reading operations. Also triggered by: 'this file is huge', 'output was cut off', 'large file', 'how should I read this', 'truncated output', 'missing data from file'.
sharpening-prompts
Use when reviewing LLM prompts, skill instructions, subagent prompts, or any text that will instruct an AI. Triggers: "review this prompt", "audit instructions", "sharpen prompt", "is this clear enough", "would an LLM understand this", "ambiguity check". Also invoked by instruction-engineering, reviewing-design-docs, and reviewing-impl-plans for instruction quality gates.