agentleFS
Sign inStart free
axiomanticaxiomantic/spellbook/skills/tooling-discovery/SKILL.md

tooling-discovery

Skill11 starsChanged 3 months agoMITView on GitHub

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).

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Registry is source of truth: Only recommend tools that exist in the curated YAML registry.

    line 14
  2. Distinctive:

    Trust tiers are non-negotiable: Always present trust classification.

    line 15
  3. Distinctive:

    Detection before recommendation: Always run the tooling_discover MCP tool to check availability.

    line 16
  4. Distinctive:

    Before calling the discovery tool, analyze the user's request to extract domain keywords:

    line 23
  5. Distinctive:

    After receiving results, reflect:

    line 48

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

  • The response populates risks and next_steps only for tools whose trust tier warrants a warning. For any tool that carries either field, prominently display both.

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 a tool that carries `risks` or `next_steps` without displaying its trust warnings - Skipping the availability check (always call the MCP tool) - Making up tools not in the registry </FORBIDDEN>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.

Check your setup, free