Tribal knowledge hunt

Every company runs on knowledge that was never written down. Why the Denver account gets invoiced differently. Which vendor contract auto-renews in a way that burned everyone last year. Why the deploy script has a sleep 30 in it. Who actually approves a refund over $5k. None of this is in the handbook. It lives in people's heads, and its only physical trace is scattered across a few thousand messages, threads, comments, and docs that nobody will ever read again.

This skill turns that scatter into an answer. The method has one non-negotiable property: every claim carries a link to where it came from. Anything that can't produce a link doesn't ship as a finding — it ships as a gap.

That rule is the whole thing, so it's worth being clear about why. A knowledge document's entire value is that the next person can trust it without re-verifying. An unsourced claim destroys that: it looks exactly as authoritative as a sourced one, gets copied into the next doc, and becomes fake institutional knowledge that outlives everyone who could have corrected it. A gap does the opposite — it tells the reader "nobody knows this, go find out," which is true and actionable. A confident wrong answer is worse than an admitted hole.

Phase 1 — Inventory the record

Before asking anything, find out what's actually reachable. Check which connectors and tools are live in this session — chat platforms, email, wikis and doc stores, ticket trackers, CRMs, code hosts, calendars, support tools, file systems, uploaded files. Don't ask the user which tools they have; look, then tell them what you found.

Report it in a line or two: what's connected, and what's conspicuously missing for a company of this shape. If nothing is connected, say so plainly and ask them to connect something or paste/upload an export — this skill has nothing to work with otherwise, and pretending otherwise wastes their time.

Hold the gap analysis until after the interview. You can't tell someone which connectors they need until you know what they're hunting.

Phase 2 — Interview

Keep this short — three questions is plenty, and skip any question the request already answers. Someone who says "why do we bill Acme quarterly instead of monthly" has already told you the outcome and the scope; don't make them sit through an intake form. The interview exists for vague asks, not specific ones.

What you actually need:

The outcome. Not the topic — the artifact and what it's for. "Everything about our refund policy" is a topic. "A one-pager so the new support hire stops escalating refunds to me" is an outcome, and it determines length, format, and what counts as done. Common outcomes: a sourced answer to one question, an onboarding brief, a decision log, a process reconstruction, a risk register of what breaks when someone leaves, a precedent search before making a call, story or content mining.

The scope. Time range, teams, projects, or accounts. Tribal knowledge has a half-life — a policy from three years ago may have been quietly reversed. If they don't know, default to the last 12–18 months and widen only if the trail demands it.

The sensitivity. Who reads the output, and is there anything that shouldn't travel — comp, performance, legal exposure, an unannounced departure. Ask once, early. It's much cheaper than un-writing something later.

Then do the gap check: given that outcome, name any source you'd want that isn't connected, and say whether it's worth stopping to connect it or whether you can get most of the way without it. Let them decide. references/sources.md covers what typically lives where.

Phase 3 — Hunt for traces, not answers

This is the part people get wrong, and it's why generic search disappoints.

Tribal knowledge is by definition not written down as an answer. Searching for the answer directly — "revenue recognition policy," "deploy process" — mostly surfaces the official doc that's either missing, stale, or the very thing being contradicted in practice. The knowledge you want doesn't exist as a statement. It exists as residue: the friction it caused, the questions it prompted, the exceptions people made around it.

So hunt the residue. Seven patterns cover most of it:

1. The repeated question — the same thing asked by different people, months apart, in different places. Proof that no canonical answer exists. Usually the single highest-value find.
2. The exception — "normally we do X, but for Y we do Z." Exceptions carry the real rule, which is almost never the written one.
3. The reversal — a decision made and then quietly undone. The reasoning behind the undo is the knowledge, and it's almost never recorded anywhere official.
4. The name — "ask Priya," "Marcus would know," "check with whoever owns that." Every one of these marks knowledge concentrated in a single human, which is what a bus factor actually looks like in the wild.
5. The workaround — "just do it manually," "there's a script for that," "I have a spreadsheet." Undocumented process, doing real load-bearing work.
6. The warning — "careful, last time we tried that," "don't touch that until you talk to me." Scar tissue. Points straight at an incident whose lesson never made it into a doc.
7. The stale artifact — a doc everyone links to that hasn't been updated in a year while the chat record quietly contradicts it. The gap between the two is the finding.

references/traces.md has query templates for each of these, adapted per source type. Read it before your first search — the phrasings matter more than they look, because you're searching for conversational residue, not keywords.

Then shape the hunt to the person asking. An accountant hunting a close process, an engineer hunting why a system is the way it is, a recruiter hunting what actually gets candidates hired — same method, very different queries and very different tells. references/hunts.md has starting hunts by function and by outcome. Treat them as starting points, not a taxonomy; if the role isn't listed, the pattern still transfers.

Work in widening passes. Start narrow with the obvious terms, then follow what you find — names, project codenames, ticket IDs, product nicknames, the internal shorthand nobody would think to tell you. Internal vocabulary is the highest-leverage thing you learn in the first pass, because it unlocks searches you couldn't have written at the start. Note it as you go and re-search with it.

You cannot read the record. Assume it is orders of magnitude larger than anything you could
open — tens of thousands of messages, most of them irrelevant. Every search returns a sample,
and the job is to follow leads out of that sample, not to sweep the corpus. Two specific
temptations to refuse: enumerating a source item by item because the IDs happen to be
guessable, and firing dozens of single common words to see what falls out. Both feel thorough
and produce noise. A hunt is twenty good queries deep, not two hundred shallow ones.

Stop widening when two consecutive passes turn up no new vocabulary, no new names, and no new
dates. That is the signal that the reachable record is exhausted — everything after it is
padding, and what's left is a gap to report rather than a query to keep rephrasing.

Phase 4 — Verify

Search results are leads, not findings. Three things to do before anything earns a place in the output:

Read the thread to its end. A decision in the third message is often reversed in the twentieth. Snippets and search previews truncate; open the actual thread. This is the most common way a confident wrong answer gets made.

Check the date against the scope. A true statement from 2023 can be a false statement today. Date every finding — the reader needs it to judge staleness themselves.

Look for the contradiction rather than around it. If two sources disagree, that's not a problem to resolve by picking the more recent one — it's frequently the most valuable thing you'll surface, because it means the org itself doesn't agree and somebody should probably know that. Present both with their sources and say plainly that they conflict. Smoothing a contradiction into a clean answer manufactures a consensus that doesn't exist.

A discredited source stays discredited. Once you've established that a doc is stale or
wrong, you cannot keep borrowing its other claims as defaults. The temptation is specific and
easy to miss: you catch that the policy page is out of date on the two things the chat record
contradicts, then quietly use its unchallenged third claim to fill a hole. That claim has
exactly the same provenance as the two you just disproved. Mark anything you take from a
discredited source as an inference, name the source and its date, and say what would confirm it.

Recompute every derived number. Totals, counts, date spans and averages are claims, and
they are the ones most likely to be wrong, because they carry a receipt for each component and
none for themselves. A table of four correctly-cited credits under a total that is off by $100
is a sourced document with a false headline, and the total is what gets quoted. Add it up
again against the rows you actually cited, and show the components next to the total so the
reader can check you.

Kill anything that survives all of this but still has no link. No exceptions, including for things you're confident are true.

Phase 5 — Deliver

Match the format to the outcome from Phase 2 — a one-pager, a brief, a table, a doc in their wiki. Whatever the shape, three sections earn their place:

What the record says. Findings, each with its source link and date. Where confidence is uneven, say so — "three people say X, one says Y, most recent is X" is more useful than a flattened verdict.

What the record doesn't say. The gaps you hit. Be specific: not "unclear," but "no message anywhere states who approves this; the four instances found were all approved by different people." A well-specified gap is a finding.

Who to ask. When knowledge is genuinely only in someone's head, the honest output isn't a guess — it's a name and the exact question to put to them. Pull the names from the trail: whoever answered last time, whoever made the call, whoever gets tagged. This turns a dead end into a five-minute conversation, which is a real deliverable.

Then close the loop. The output of a knowledge hunt is usually the input to something else — the doc that should now exist, the process that should be written down, the person who should be asked, the decision that can now be made. Name that next step and offer to do it, rather than handing over findings and stopping.

Sensitive material

A search across a company's whole record will surface things the person asking didn't intend to go looking for: compensation, performance problems, health, someone's exit before it's announced, legal exposure. Note that it exists if it's relevant to the hunt, don't quote it into a document that will travel, and tell the user what you found and left out. If the entire hunt is heading somewhere it shouldn't — someone using it to build a case against a colleague, say — raise it rather than quietly complying.

Handle the record with the same care as the person whose messages you're reading would want.

Reference files

• references/traces.md — query templates for each of the seven trace patterns, per source type. Read before your first search.
• references/hunts.md — starting hunts by function (finance, engineering, marketing, sales, people, ops, legal, product, support, exec) and by outcome type. Read once you know who's asking and what for.
• references/sources.md — what tribal knowledge lives in each kind of source, how to search each one well, and what to do when a needed source isn't connected.