The /finder Skill

What it does

finder answers a research question with current, external, cited evidence — not whatever the model happens to remember.

It fans out across a small set of angles (official docs, community discussion, general web, and — when relevant — this repository), then synthesizes one report. Code appears only when the question is about implementation, and only as a short illustrative snippet. Finder never edits repository files.

When to reach for it

• “Research best practices for X”
• “Investigate this issue / error and what’s known about it”
• “What does the community say about this approach?”
• “What do the official docs recommend?”
• Any question where an answer from memory alone risks being stale, unverified, or generic

Do not use for:

• Trivial lookups with no ambiguity or need for citation
• Direct implementation (“add a button that does X”) — just build it
• Cases where you’ve already supplied the context and only want code

Prerequisites

Works best with web search/fetch and parallel sub-agents. If the harness can’t spawn sub-agents, Finder works the same angles sequentially. Without any search/fetch tool, it isn’t useful.

How it works

1. Decompose — Pick only the angles that matter. Cap at three concurrent angles; note what was deprioritized.
2. Fan out or fall back — Parallel sub-agents when available; sequential otherwise (not an error).
3. Bound each angle — Roughly 5–8 searches/fetches (or file reads for the repo angle). Stop and report confidence rather than researching forever.
4. Synthesize — Reconcile consensus vs this repo, conflicting sources, and outdated advice.
5. Decide on code — Snippet only for implementation questions; never for pure concepts.
6. Cite everything — Non-trivial claims get sources; end with a Sources list.
7. Output in the conversation — Print the report; don’t write a file.

What you get

A cited report shaped like: Summary, Key Findings, Repo-Specific Notes (when in scope), Recommendation, optional Code Snippet, and Sources.

The full report template lives in the source skill.

Common questions

Will it change my repo?
No. Snippets are for you to apply. Finder is read-only research.

What if sources disagree?
The report calls out the disagreement and recommends with reasoning instead of silently picking a winner.

When does it look at my codebase?
Only when the topic plausibly relates to this repo. Purely conceptual questions skip the repo angle entirely.

It’s working if

• Claims point at URLs (or clearly marked well-known facts)
• Conflicting guidance is surfaced, not papered over
• Repo notes reflect actual usage when that angle was in scope
• Code samples stay short and optional
• No files in the repository were modified

Where it fits

Use before plan-with-me when a planning decision is blocked on external knowledge, or before instrumenting-for-observability when you need to learn an unfamiliar telemetry API. Finder closes unknowns; it doesn’t choose your product tradeoffs for you.