mcpField
F
find-tool

find-tool

github.com/paulrbergDevelopment10271 installsUpdated today
Repository

About find-tool

A skill for recommending tools that fit a user's constraints. It checks existing capabilities first, then compares viable options using current authoritative sources and explains the decisive tradeoffs.

Key features

  1. 01Assess ecosystem, stack, and requirements
  2. 02Check standard library and installed tools first
  3. 03Search current authoritative sources
  4. 04Compare viable options against relevant criteria
  5. 05Explain the recommendation and tradeoffs

Use cases

  1. 01Choose a development tool for a project
  2. 02Assess whether a new dependency is needed
  3. 03Compare tool maintenance and security

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/paulrberg/agent-skills --skill find-tool

After installing, type/find-toolin Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlreferences/find-tool.md

Details

From the project README

Find Tool

Recommend the current option that best fits the user's actual constraints, backed by fresh primary evidence.

Workflow

  1. Infer the ecosystem, existing stack, must-haves, switching cost, and decision criteria from the request and repository. Ask only when an unknown would materially change the recommendation.
  2. Check whether the standard library, platform, or an already-installed tool is sufficient before adding a dependency.
  3. Search current authoritative sources. Read references/find-tool.md only for the relevant ecosystem's source routing, fallback criteria, install conventions, and red flags.
  4. Compare the viable options against the user's criteria. Use adoption, maintenance, security, documentation, performance, operational cost, and ecosystem fit only where they affect this decision; do not force fixed weights or a fixed number of candidates.
  5. Recommend one option when the evidence supports it. State the decisive tradeoff, material red flags, and the closest alternative. Say when the evidence is too close or no external tool is justified.

Defaults

  • With no repository evidence, default to JavaScript/TypeScript and Node.js tooling.
  • Prefer standard-library or platform primitives when adequate.
  • For JavaScript installs, prefer the repository's package manager and otherwise ni; for macOS CLIs, prefer an official or well-maintained Homebrew formula.
  • Prefer registries, official docs, repositories, changelogs, and security advisories over secondary comparisons. For agent skills, search registries and GitHub because no single index is complete.

Completion

The answer is complete when the recommendation is traceable to current sources, the deciding criteria are explicit, installation guidance matches the user's environment, and uncertainties or disqualifying risks are visible. Use a table only when repeated fields make the comparison easier to scan.

Lead with ### 🏆 Pick: <tool> and the decisive reason. Follow with ### 📦 Install and the exact command, a compact criteria/evidence table only when fields repeat, ### 🥈 Closest alternative only for a credible material runner-up, and ### ⚠️ Caveats only when material. Use symbols in comparison cells only with text; never manufacture scores. Keep URL targets exact and use descriptive Markdown links for human output. Keep install commands, versions, security advisories, and installer-risk wording exact and undecorated.

Comments

Markdown supported