knowledge-lookup

knowledge-lookup

You are consulting the user's Obsidian Knowledge Base before solving a problem. The goal is to replace "guessing from memory" with "research from the KB." If the KB has an entry, use it. If it doesn't, research the real code / docs / error — don't fall back to half-remembered fixes.

Rigid process — run these steps in order every time

Step 1: Load the MOC index

Read the single index file:

~/Documents/workspace/obsidian-vault/claude-code/Resources/MOC-Knowledge-Base.md

This is cheap — one line per entry. If the path doesn't exist, announce KB unavailable — vault not mounted at expected path and stop (do not halt the user's task; just proceed without the KB).

Step 2: Identify scope

Determine three things:

1. Current project slug, resolved in this order:

   • project_slug frontmatter in the repo's CLAUDE.md (if present)
   • basename of the git repo root (e.g. /Users/harshagarwal/Documents/workspace/c360 → c360)
   • otherwise, scope is cross only

2. Tech area — inferred from the task description, files being edited, and any error text. Examples: drizzle, nginx, auth, deploy, migration, cookie, cors, docker, react-router, asana, jira.

3. Keywords — specific strings to match on. Pull them from:

   • Error messages (literal text)
   • File paths being edited (e.g. backend/drizzle/)
   • Task titles
   • Library/stack names

Step 3: Scan the index for matches

From the index lines, pick the ones where:

• <scope> is cross OR matches the current project slug, AND
• <keywords> or <hook> text contains any of the identified tech-area words or error keywords

Collect the wikilinks from matching lines. Read each matching full doc.

Step 4: If an error is present, ALSO grep full docs for the error text

For reactive lookups (an error / test failure / unexpected behavior has surfaced), additionally grep:

grep -rn "<distinctive error snippet>" \
  ~/Documents/workspace/obsidian-vault/claude-code/Resources/gotchas/ \
  ~/Documents/workspace/obsidian-vault/claude-code/Resources/patterns/ \
  ~/Documents/workspace/obsidian-vault/claude-code/Projects/ 2>/dev/null

Pick a distinctive phrase from the error message, not a generic word. Read any matches.

Step 5: Announce findings — MANDATORY

Report to the user in 1-3 bullets.

If matches found:

KB hit:
- [[Drizzle migration `when` timestamp]] — applies because we're adding a new migration file. Action: before picking a `when` value, check the journal for max existing `when`.

If no matches:

KB checked (index loaded, scope: c360 + cross, keywords: migration drizzle postgres). No matches.

The "no matches" announcement is never optional. It is the forcing function that proves the skill actually ran. If you skip this announcement, you are violating the skill contract.

Step 6: Research-before-guess rule

When KB has no relevant entry, you MUST research the actual code / docs / error before proposing a fix. This means:

• Read the actual file that's producing the error
• Read the library's source or upstream docs
• Check recent git history for related changes
• Run the failing command with more verbose flags to get real signal

You may NOT fall back to "I think it's probably X" from conversation memory. That is exactly the failure mode this skill exists to prevent.

When the MOC index is missing or empty

If the MOC file doesn't exist or has no entries, still announce:

KB checked — MOC exists but has no entries in scope <scope>. Researching from source.

Then proceed with the research-before-guess rule from Step 6.

Interaction with other skills

• Runs before any implementation work, fix attempt, or debugging session.
• Does NOT replace the systematic-debugging skill — if you're debugging, use both: lookup first, then systematic-debugging for the research phase.
• Pairs with knowledge-save — lookup consumes the KB, save writes to it. They never run concurrently in the same step; lookup at task start, save at task end.

Token budget

The MOC index is the only file always read. Full docs are only read on match. Target: total tokens from this skill ≤ 5k on a typical task. If you find yourself reading more than 3 full docs, stop and ask yourself whether they're all actually relevant.