discover-sources
Skill15 starsChanged 5 months agoMITView on GitHub
Map what product-data sources a user can draw on, connectors, tools, files, offline systems, and the decision-confidence ceiling those sources allow. Use when the intent is discovery and setup of the evidence base itself: \"what data do I have / could connect\", \"scan/inventory my sources\", \"is X hooked up\", \"where could product insights come from\", \"how confident could any decision be given my data\", or starting a new project before any framing or prioritizing. Do NOT use when the user wants you to actually work the data they already have, pulling, summarizing, grading, or reporting on tickets, reviews, surveys, metrics, scorecards, or trends. Those are analysis and reporting tasks, not source discovery. The trigger is \"what evidence exists and how good can it get,\" not \"analyze the evidence.\" Produces a source map plus a confidence ceiling.
In this repository13 other files it gives its agents.
- calibrateSkill
- critiqueSkill
- decision-readinessSkill
- design-testSkill
- drift-checkSkill
- gather-evidenceSkill
- pressure-testSkill
- prioritize-backlogSkill
- scorecardSkill
- startSkill
- synthesizeSkill
- to-build-briefSkill
- write-briefSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Run this first in a new project, or whenever the user asks what data they have or could connect.
- Distinctive: line 18
No single discovery surface is reliable, so check all three:
- Distinctive: line 20
Live tools: Look at which MCP tools / connectors are actually callable in this session right now, including any that are present but …
- Very specific: line 21
Registry: If a connector registry is available (e.g.
- Distinctive: line 24
Do not assume a source is unavailable just because one surface is silent.
- Distinctive: line 41
Only third-party / indirect sources (reviews, community, market tools, feature requests) → ceiling is Moderate.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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.
Files
Discover Sources
Inventory where product-relevant data lives for this user, map each source to the kind of evidence it can produce and the maximum strength that evidence can reach, and record the resulting decision-confidence ceiling. This is the foundation every other skill reads.
When to run
Run this first in a new project, or whenever the user asks what data they have or could connect. If .product-eval/<scope>/sources.md already exists, read it and offer to refresh rather than starting over.
Workflow
1. Scan three surfaces
No single discovery surface is reliable, so check all three:
- Live tools: Look at which MCP tools / connectors are actually callable in this session right now, including any that are present but require authentication. This is the most authoritative signal for "what can be pulled today." List what you find.
- Registry: If a connector registry is available (e.g.
search_mcp_registry), search it for product-data categories the user does not yet have connected, so they can be suggested with a one-click connect. - Catalog-prompted: Walk the categories in
references/source-catalog.mdand ask the user about offline or non-connectable sources. For anything that cannot be connected, offer CSV / file upload as the on-ramp.
Do not assume a source is unavailable just because one surface is silent. (It is common for a registry to report nothing while live connectors are in fact present.)
Probe to confirm, don't just detect. A tool being present is not proof it returns data. For each detected connector, make one cheap probe call (pull a single recent item) and tag the source reachable / needs-auth / empty / blocked; when it works, note the access pattern that worked (tool · operation · params) so gather-evidence reuses it. See ../gather-evidence/references/fetch-strategies.md.
2. Map every found source to an evidence role
For each source the user has or uploads, record, using references/source-catalog.md:
- the evidence role it plays (e.g. first-party quantitative, support-ticket cluster, third-party qualitative),
- the maximum evidence strength it can yield (1-5),
- which metric-tree branch it illuminates (acquisition, activation, engagement, retention, expansion, advocacy),
- the join keys it exposes (email, user_id, domain, username) for identity resolution, see
references/identity-resolution.md, so the same person or account can be linked across sources later. Note whether a CDP or identity graph is present.
3. Compute the confidence ceiling
The set of connected sources caps how confident any decision can become. Determine the ceiling honestly:
- Only third-party / indirect sources (reviews, community, market tools, feature requests) → ceiling is Moderate; decisions will tend to land at Run a research sprint or Do not commit yet.
- At least one strong first-party quantitative source (product analytics, logs) plus corroboration from another source type → ceiling can reach Decide now.
State the ceiling plainly and name the single highest-leverage source the user could add to raise it.
4. Write the source map
Write .product-eval/<scope>/sources.md (create .product-eval/<scope>/ if it does not exist) with: the sources found per surface, the role/strength/branch mapping, the join keys per source (and whether a CDP or identity graph is present), each source's probe status (reachable / needs-auth / empty / blocked) and working access recipe, coverage gaps, the confidence ceiling, and the top 1-2 suggested connectors to add. Every other skill reads this file and degrades gracefully against it.
5. Recommend the next step
Tell the user what they can and cannot do given their sources, then recommend the next action: no first-party data → gather evidence outside-in, then synthesize; rich connectors → gather evidence then prioritize-backlog; an existing roadmap → pressure-test.
Output
A short, scannable summary in chat (sources found, confidence ceiling, top gap to close) plus the written .product-eval/<scope>/sources.md. Keep the chat summary free of internal file paths unless the user asks. End with Next move: and recommend the one action that moves the user toward delivery: upload/pull evidence, gather outside-in signal, rank opportunities, or pressure-test an existing plan.
Notes
- CSV / file upload is the universal on-ramp: any source that can export becomes usable evidence even with zero connectors. Strength comes from the declared source type and content, not from how the data arrived.
- The web is always available as a corroboration layer for later steps, even when the user has no internal data.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.

