Compile institutional PI practice knowledge from FirmVault activity logs into a structured Obsidian wiki using Karpathy's LLM Knowledge Base architecture. Use when adding new cases, recompiling, querying, or linting the law firm wiki.
Instrucciones de origen · Vista previa de solo lectura
name
law-firm-wiki-compiler
title
Law Firm Wiki Compiler
description
Compile institutional PI practice knowledge from FirmVault activity logs into a structured Obsidian wiki using Karpathy's LLM Knowledge Base architecture. Use when adding new cases, recompiling, querying, or linting the law firm wiki.
Use the subcategory: settlement_activity_export tag to identify imported-from-Excel cases later
Multiple files in one session
Aaron often sends multiple Excel files in sequence. Process each one fully
(convert → batch → compile → rebuild index) before asking for the next.
The converter handles deduplication automatically — if a case dir already
exists, new logs append; if a log file for that date exists, it appends
an "Imported Entries" section.
>50 cases: 3 parallel subagents (split evenly by log count)
10-50 cases: 1-2 subagents depending on log volume
<10 cases: Single subagent with targeted article updates only.
Do NOT have it read all existing articles — point it at the 5-6 most
likely articles to update. Set max_iterations=30 to avoid running out
of turns on reading.
Reusable converter script
Save to /tmp/convert_excel.py, swap the path for each new file. The script:
Uses openpyxl (pip install if missing)
Slugifies per FirmVault rules
Groups by case → date → writes markdown with frontmatter
Reports new vs updated case dirs
Architecture
Karpathy's 3-layer pattern: raw sources → LLM compiler → structured wiki
Layer 1: Raw (immutable)
cases/*/Activity Log/*.md — 21K+ activity logs
cases/*/*.md — case files
Layer 2: Wiki (LLM-maintained)
wiki/
Home.md — Obsidian dashboard
index.md — master catalog
log.md — compilation history
concepts/*.md — atomic knowledge articles (63 as of 2026-04-12)
connections/*.md — cross-cutting insights (26 as of 2026-04-12)
AGENTS.md — compiler schema (the spec)
SPEC.md — architecture doc
Layer 3: Consumers
Hermes semantic skills, OpenClaw agents, Aaron via Hermes
Compilation Process
Batch Processing (for bulk cases)
Group cases into batches of ~80K tokens
Delegate 3 batches in parallel
Each subagent reads AGENTS.md, existing articles, case files + sampled logs
Subagents UPDATE existing articles (evidence_count++) or CREATE new ones
Do NOT let subagents rewrite index.md (race condition) — rebuild after
Rebuild index.md from all articles on disk after all batches complete
Key Instructions for Compiler Subagents
Read AGENTS.md for full schema
Read ALL existing concept + connection articles before writing
ANONYMIZE all PII (use "Case A", "Case B", etc.)
UPDATE existing > CREATE new (upgrading confidence is the goal)
Confidence: low (<5 cases), medium (5-9), high (10+)
Use [[wikilinks]] between articles
Append to log.md, do NOT rewrite index.md
Sampling Strategy
Large cases (400+ logs): first 40 + last 40 chronologically
Medium cases (100-400): first 25 + last 25
Small cases (<100): first 10 + last 10, or all
Subagent Prompt Template
Law Firm Wiki compiler. Read /opt/data/FirmVault/wiki/AGENTS.md.
Read existing articles in wiki/concepts/ and wiki/connections/.
Compile cases: [LIST]. For each: read cases/<slug>/<slug>.md and
sample first N + last N activity logs. UPDATE existing articles
(increment evidence_count, upgrade confidence: 5=medium, 10=high).
CREATE new only for genuinely new patterns. ANONYMIZE PII.
Write to wiki/. Do NOT rewrite index.md. Append to wiki/log.md.
Adapt prompts to data category
Different Excel exports contain different types of data. Add a focus hint:
Settlement files: "Focus on: settlement patterns, negotiation tactics,
treatment timelines, SOL management, adjuster behavior, lien resolution"
Closing files: "These are CLOSING cases -- look especially for: case
closure workflows, decline reasons, final disbursement, file archival,
post-closing obligations, client termination patterns"
Intake files: Focus on onboarding, insurance verification, initial
treatment referrals
This dramatically improves pattern extraction quality.
Index rebuild
Always rebuild index.md as a separate delegate_task after all compilation
batches complete. Even for small batches. The subagent just needs to parse
YAML frontmatter from all .md files in concepts/ + connections/ and generate
the index per the schema in AGENTS.md. Takes ~60 seconds, max_iterations=15.
Obsidian Vault
The wiki/ directory IS an Obsidian vault:
.obsidian/ config with graph colors (blue=concepts, orange=connections)
Home.md as landing page
[[wikilinks]] use slug names (NOT path-prefixed)
Graph view shows article interconnections
Wikilink Rules
Use [[slug-name]] not [[concepts/slug-name]]
Obsidian resolves by filename, paths break links
Filtering Cases for Compilation
Two approaches — use the Excel file directly (preferred) or scan the vault:
Preferred: Extract slugs from the Excel file itself
# Parse Excel → get unique Project Names → slugify → batch
wb = openpyxl.load_workbook(path, read_only=True)
cases = Counter(str(r[0]).strip() for r inlist(wb.active.iter_rows(values_only=True))[1:] if r[0])
slugs = [{"slug": slugify(name), "logs": count} for name, count in cases.items()]
This is precise — only compiles what was just imported.
Fallback: Scan vault by subcategory tag
for slug in os.listdir(cases_dir):
for logfile in os.listdir(log_dir):
if"settlement_activity_export"inopen(logfile).read(200):
new_slugs.append(slug)
break
Do NOT use mtime-based filtering — it picks up every case in the vault
(including old ones whose dirs were touched during conversion).
Pitfalls
Parallel subagents cause race conditions on evidence_count — accept ±3 variance
Don't let subagents rewrite index.md — rebuild it yourself after all batches
Large cases (1000+ logs) must be truncated — sample strategically
Wikilinks with path prefixes break in Obsidian — strip concepts/ etc.
The compile.py script generates prompts but doesn't call the LLM directly — use delegate_task
Some articles reference aspirational links (articles not yet created) — that's OK, they'll be created as more cases are compiled
mtime-based vault scanning doesn't work for identifying "just imported" cases — conversion touches existing dirs too. Always extract the case list from the Excel file itself.
Closing cases are mostly declines, not post-settlement closures. The decline/close workflow gets the biggest evidence boost from closing data, not the settlement disbursement workflow.
Small batches (<10 cases) exhaust subagent iterations if you have them read all 89 articles. Point them at specific articles instead.
Multiple-File Workflow
When user sends multiple Excel files, convert all first then compile:
Reuse /tmp/convert_excel.py — just patch the filename for each file
After all converted, batch the NEW cases only (use slugify + check existence)
Compile in 3 parallel batches, then rebuild index once at the end
Duplicate Detection
User may send the same file twice (same name, different doc ID). Compare row counts + first/last row to detect dupes before converting.
300 cases: 3 parallel subagents with aggressive sampling (first 10 + last 10)
Always rebuild index.md AFTER all batches complete (never let subagents touch it)
Pitfall: mtime-based filtering unreliable
Don't use file mtime to find "new" cases — convert_excel.py touches existing files too. Instead, extract case names from the Excel directly and slugify to get the target list.
Files
FirmVault: /opt/data/FirmVault
Wiki: /opt/data/FirmVault/wiki/
Schema: wiki/AGENTS.md
Converter: /tmp/convert_excel.py (patch filename between runs)
Article counts: 65 concepts + 28 connections = 93 total (as of 2026-04-12)
Decisions: /opt/data/FirmVault/decisions/ (ADR-000 through ADR-006)
