# Choosing Tools > Decide which installed skill or tool, if any, should own a task — a fit-ranking dispatch step at task starts and direction changes, not a per-message ritual. Use when starting substantive work that more than one installed capability could plausibly own, when unsure whether a discipline skill (TDD, debugging, data-contract guardrails) applies to the work at hand, when two skills seem to claim the same job, or when the user asks "which tool/skill should handle this". Ranks candidates against their descriptions' positive and negative triggers and loads one only when its expected benefit clearly exceeds its context and anchoring cost; exits in one line when nothing fits, and sets aside a loaded skill plainly when it turns out wrong. Pairs with toolkit-awareness, which answers what is installed — this skill decides whether and when to load it. Not for inventory questions (that is toolkit-awareness) and not for authoring or tuning skill descriptions (that is skill-authoring). - Skill: `grimaldost/choosing-tools` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add grimaldost/choosing-tools` - Raw SKILL.md: https://api.skillmd.com/api/skills/grimaldost/choosing-tools/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: grimaldost (https://skillmd.com/u/grimaldost) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/grimaldost/choosing-tools --- # Choosing Tools Tool selection runs on fit, not volume. This skill states the dispatch policy once, centrally, so no individual skill has to argue for its own attention — descriptions describe, and this protocol ranks them. This is a **flexible** skill: the procedure below is the default shape of the decision, and the judgment inside each step is yours. ## When this runs At task starts and direction changes — the moments where work could take a shape: build, fix, migrate, refactor, review, plan, audit. **Inside a long autonomous task the internal phase shifts are direction changes too** — design→build→run→report each invite a quick re-check and a one-line naming of the active discipline, rather than riding the opening dispatch for hours. It does not run on conversational turns, follow-up messages inside an active task, or questions answerable directly. A dispatch check on "hang on" is ceremony, not selection. ## The dispatch procedure 1. **Name the task in one phrase.** "Schema change with downstream consumers", "unexplained test failure", "new feature, shape unclear". The phrase is what candidates get ranked against. 2. **Shortlist candidates.** Installed skills whose triggers plausibly match. When unsure what is installed, get a live inventory rather than recalling from memory — an inventory skill when one is installed (e.g. session-workflow's toolkit-awareness), else the harness's skill listing or a repo's `AGENTS.md` index already in context. 3. **Read the target tool's own record.** When the task will exercise a tool that has a registered dogfooding-feedback intake (e.g. a `feedback-targets` binding, where session-workflow's loop is installed), read the newest report's Misses/Friction from that intake — one Read — before settling the shortlist. Dispatch is where a recorded miss must resurface: the same under-dispatch recurred across six arcs, once the day after being written down, because nothing read the record back at this step. No registered intake → skip; the step costs nothing. 4. **Check positive and negative triggers.** A candidate that matches the phrase but sits in another skill's declared territory ("not for X — that is Y") loses to the owner. Negative space decides ties. 5. **Load when the bar is met.** Load the best fit when its expected benefit — risk averted, rework avoided, discipline the task genuinely needs — clearly exceeds its cost: the context it occupies and the way a loaded skill anchors the plan. When a process discipline and an implementation skill both apply, load the process discipline first; it shapes how the implementation runs. 6. **Exit in one line when nothing clears the bar.** "No installed skill owns this; proceeding directly" is a complete, correct outcome. Record it and move on. 7. **Set aside misfires plainly.** A loaded skill that turns out not to fit is abandoned explicitly — "loaded X; it assumes Y, which doesn't hold here; continuing without it." Following a misfit skill to completion because it was loaded is anchoring, not diligence. ## The loading bar The threshold is deliberately qualitative — "clearly exceeds" — because a numeric cutoff in prose would be fake precision. What calibrates the bar over time is measurement: the trigger evals and their gates, not adjectives. Two rules of thumb hold: - Cheap, scoped reference skills (a schema, a config convention) clear the bar easily; heavyweight process skills that restructure the whole turn need a task that actually has the failure modes they prevent. - Keyword overlap alone never clears the bar. "Test" appearing in the task does not load a TDD skill; implementing behavior does. - Declining to load a skill is not declining its cheapest, most durable core. The bar gates skill *ceremony*, not the cheap insurance some disciplines carry (e.g. leaving a red-green regression test after a bug fix — seconds of work, lasting protection — even when the full skill isn't worth loading). Apply the core, skip the ceremony. ## Boundaries - **The inventory is someone else's job** — what is installed and who owns which concern comes from an inventory skill (e.g. session-workflow's toolkit-awareness), the harness's skill listing, or a repo's `AGENTS.md` index. This skill consumes that answer; it does not produce it. - **skill-authoring** owns descriptions — when a skill keeps winning or losing dispatch wrongly, fix its trigger surface there, never by inflating register; selection quality depends on descriptions staying honest. ## Dispatch-router hook The plugin ships a UserPromptSubmit hook that runs a lexical router over each substantive prompt and names each matching skill by its activation test — a question to answer, not a coincidence to notice. It skips skills this install lacks, and never reads the cwd's name as trigger vocabulary. On by default; `HUMBLEPOWERS_DISPATCH_PROMPT_INJECT=0` opts out.