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.