EnrichNode Wiki

LLM Wiki Best Practices

4 min read

LLM Wiki Best Practices

How to make this vault maximally useful for LLMs

Compiled from Karpathy’s gist, Obsidian community patterns, and LLM retrieval research.

1. Atomic Notes

Rule: One concept per file. If you find yourself writing “and also…” about an unrelated topic, split.

Why: LLMs retrieve by file. Mixed-concept files pollute context with irrelevant information.

Good: Domain Discovery.md — only domain discovery Bad: Domain Discovery and Validation.md — two concepts, split into two files

2. Dense Cross-Linking

Rule: Every note must link to ≥2 other notes. The index must link to every note.

Why: LLMs follow links to build context graphs. Sparse links = orphaned knowledge.

Pattern:

See [[Domain Discovery]] for how domains are found.
Validated by [[Name Validation]] before use.

3. Frontmatter for Metadata

Rule: Use YAML frontmatter for tags, aliases, and update dates.

Why: LLMs can parse structured metadata for filtering and relevance scoring.

---
tags: [enrichment, scraping, compliance]
aliases: ["Crawlee", "Web Scraper"]
updated: 2026-04-28
status: current  # current | stale | draft
---

4. Specific Over Generic

Rule: Prefer file paths, function names, line numbers, dates, counts over prose.

Why: LLMs hallucinate less when given concrete anchors. Specifics are verifiable.

Good: “findCompanyDomain() in src/enrichment/sources/domain.ts:45 uses a 0.40 threshold” Bad: “The domain discovery function has a reasonable threshold”

5. Callouts for Status

Rule: Use Obsidian callouts to mark claim status. Never delete outdated info — mark it stale.

Why: LLMs need to know what’s current vs. historical. Deletion loses institutional memory.

> [!stale] 2026-03-25 — Serper.dev removed
> 
> Previously used for domain discovery. Replaced by free tier.
 
> [!todo] — Add retry logic for SMTP timeouts
> 
> Current implementation fails silently on port 25 blocks.

6. MOCs (Maps of Content)

Rule: Create hub notes that link to related atomic notes. MOCs are LLM entry points.

Why: LLMs can start at a MOC and follow links to drill down. Without MOCs, every note is equally (ir)relevant.

Existing MOCs:

7. Query-Optimized Structure

Rule: Structure notes so LLMs can answer questions in 1-2 hops.

Pattern:

Question: "What's the GDPR risk?"
Hop 1: Index → [[GDPR Audit Findings]]
Hop 2: Read the 7 critical gaps table
Answer: Complete

Anti-pattern:

Question: "What's the GDPR risk?"
Hop 1: Index → [[GDPR Legitimate Interest]] → mentions Article 14
Hop 2: [[Article 14]] → mentions notifications
Hop 3: [[RoPA Log]] → mentions audit trail
Hop 4: Still haven't found the 7 critical gaps
Answer: Incomplete

8. Citation Anchors

Rule: Every claim about code must be traceable to a specific file/line.

Pattern:

The reklamspärr check happens at enrichment time
[source: `src/enrichment/pipeline.ts:56-84`]

Why: LLMs can verify claims against source code. Reduces hallucination.

9. Contradiction Resolution

Rule: When two notes conflict, reconcile immediately. Mark the older claim stale.

Why: LLMs trained on contradictory data produce confused answers.

Process:

  1. Find both claims
  2. Verify against source code
  3. Update the correct note
  4. Mark the old claim: > [!stale] YYYY-MM-DD — reason
  5. Update both notes’ updated: frontmatter

10. LLM-Readable Tables

Rule: Use markdown tables for structured data. LLMs parse tables better than prose lists.

Good:

| Issue | Severity | File | Fix Effort |
|-------|----------|------|------------|
| Mock validation | P0 | `src/mocks/validation.ts` | 2-3 days |

Bad:

The mock validation issue is P0 severity and located in src/mocks/validation.ts.
It would take 2-3 days to fix.

11. Hierarchical Summaries

Rule: Start every note with a 1-2 sentence summary. Then detail. Then links.

Why: LLMs can read the summary and decide if the full note is relevant.

Pattern:

# Note Title
 
> [!note] Summary
> 
> One-sentence description of what this note covers and why it matters.
 
## Section 1
Details...
 
## Section 2
Details...
 
## See Also
- [[Related Note 1]]
- [[Related Note 2]]

12. Version-Awareness

Rule: Track when claims were last verified. Code changes; wiki must reflect reality.

Pattern:

---
updated: 2026-04-28
verified_against: commit 81c2568b
---

13. No Orphan Pages

Rule: Every note must have ≥1 inbound link from another note or the index.

Verify: grep -r "\[\[Note Title\]\]" Wiki/ — zero hits = orphan.

Fix: Add to Index and link from a related note.

14. Lint Before Commit

Rule: Run mechanical checks before considering an edit complete.

Checks:

  1. No orphan pages
  2. No contradictions
  3. No stale code refs
  4. No missing concept pages
  5. Index matches disk
  6. Log updated

Script: bun run scripts/lint.ts

15. Query Templates

Rule: Document common question patterns so LLMs know where to look.

Example templates:

"How does X work?" → [[Symbol Map]] → find file → read wiki
"Why was X decided?" → [[Decision Register]] → find ADR
"What's broken?" → [[Known Issues]] + [[Technical Debt]]
"Is this production-ready?" → [[GDPR Audit Findings]]

Graph View

Backlinks