Oracles

An oracle is an AI loaded with a curated pile of documents about one specific domain of someone's own accumulated knowledge — not a search index, something you can ask a nuanced question and get a synthesized answer from. NotebookLM (Google's tool for this) is what one example roster was built on; any similar tool works the same way.

If you haven't set any of this up (most people won't have, at first — this is optional, advanced setup): skip straight to the fallback below. Everything past that is one example roster, shown as a worked example of how to organize domains — not something you have automatically.

If oracles aren't set up: the local fallback

Instead of querying a notebook, ground the same kind of question in what's already on the machine:

• grep across the project's docs, CLAUDE.md, and any notes folder
• git log --oneline --all -S "<term>" for when and why something was built a certain way
• The person's own past Claude Code sessions: grep -l "<term>" ~/.claude/projects/*/*.jsonl

Say plainly that no oracle was consulted, and that this is a local-search substitute, not the deeper synthesis an oracle would give. Never present a local grep result as if it came from a curated oracle.

Setting up your own

See /alignment-harness:harness-setup for the guided version. In outline: install nlm (NotebookLM's CLI) or your preferred notebook tool, sign in, then build one or more notebooks from your own material — your project's docs, your own past corrections and decisions (mined from ~/.claude/projects/*/*.jsonl), and whatever domain-specific material you want deep coverage of. A good starting pair, buildable from history alone: a rules-and-corrections notebook and a what-was-tried notebook. Everything else in this file is a template for further domains, once you have those two.

---

The Output Format (MANDATORY — every oracle query)

Give each oracle in your own roster a unique extraction-marker pair, e.g.:

## ORACLE_{YOUR_DOMAIN_NAME}
...
## END_ORACLE_{YOUR_DOMAIN_NAME}

Print the marker before your output, the closing marker after. Print this exact shape per query:

## ORACLE_{ORACLE_NAME}
📚 ── Oracle: {Oracle Name} ──────────────────────────
🔧 Command run: nlm notebook query {uuid} "{exact question text}" --profile {your profile}
❓ Why I asked this: {what you were trying to find out and why right now}
💭 Intent: {what you hoped the oracle would unlock}
📋 Response from {Oracle Name} (verbatim — never summarize):
{everything it returned, word for word}
────────────────────────────────────────────────────────
## END_ORACLE_{ORACLE_NAME}

Never summarize the response — the verbatim record is what lets you (or a later process) learn from how well the oracle actually answered.

---

An example roster (worked example — build your own domains, don't copy these)

Each entry below is a category of institutional knowledge, illustrated with a roster actually built this way. The pattern — split by domain, say when to use it and when not to, cross-reference near-duplicates — is the reusable part. The specific notebooks, IDs, and business content are from that example; replace them with your own.

Rules & antipatterns ("Agent Steering")

Every documented rule about how an agent should behave, and every correction that changed how the system works. Check here before doing anything non-trivial, to see if an explicit rule already covers it. Use when: about to do something that might be an antipattern, or want to know what process to follow before implementing a feature. Don't use for: what features to build, what happened in past sessions.

What the product should do ("Product Intent")

Testable conditions for every feature, the intended UX at each decision point, the reasoning behind why things were built a certain way. Example: during validation an oracle like this caught a real implementation bug by knowing what a placeholder string was supposed to say and noticing the code had it wrong — that's the precision level to aim for: testable conditions, not marketing copy. Use when: validating what you built against what was intended, or asking "what should happen when X?" Don't use for: agent behavior rules (that's the rules oracle), specific past sessions (that's history).

What's been tried before ("Session History")

Highest-leverage past sessions plus a store of typed knowledge atoms — decisions, corrections, patterns, open questions. Ask this before proposing something: there's a good chance someone already tried it and documented exactly what happened. Use when: checking whether something's been tried, or looking for a specific past decision. Don't use for: protocol rules, domain-specific technique.

Domain expertise the product runs on ("Coaching Principles," in this example)

If your product embeds domain expertise (clinical, legal, technical, whatever), an oracle like this holds the underlying principles with their evidence and failure modes — not vibes, actual sourced technique with warnings for when it backfires. Example: one version holds several hundred therapeutic principles across many lineages, each with evidence citations and clinical warnings. Use when: touching anything that affects what your product says or does for an end user. Don't use for: the technical pipeline that delivers it (that's code); individual user sessions.

Why the business exists ("Investor Context")

Mission, competitive thesis, unit economics reasoning, hard-won lessons on sales and leadership. Useful whenever you need to explain the business to someone who isn't living in the codebase. Use when: preparing a strategic conversation, or needing the thesis behind a pricing/product decision. Don't use for: operational or technical detail.

Communication playbook ("Email Design")

Voice rules, journey-stage logic, anti-spam constraints, template governance for anything user-facing you send. Example: one version specifies voice down to "if they say stuck, you say stuck." Use when: writing or reviewing anything user-facing. Don't use for: individual user data, or the domain content that goes inside the message (that's the domain-expertise oracle).

Cross-domain synthesis

A wide notebook spanning everything else, for when a question crosses boundaries and you need synthesis rather than depth. Trade-off: not the deepest in any one area — use the domain-specific oracle for depth, this one for connections between systems.

Voice texture

If you've built a voice oracle from raw transcripts of the person you're working with (see founder-voice-email-writing or how-to-talk-like-the-founder for how to collect that material), this is where you go to understand how they think about something — reasoning and posture, not just documented rules. Don't use for: specific protocol rules — those live in the rules oracle with more precision.

Operational failure modes ("Agent Principles Vault")

Patterns extracted from real agent sessions — not rules someone wrote down, but what happened when a rule was ignored, and what the ground truth turned out to be. The difference from the rules oracle: rules tells you the protocol, this tells you what happened when someone violated it and why it mattered. Use when: about to touch a domain with a known history of failure, or need to know the ground truth for a metric before reporting numbers. Don't use for: current product intent, current-session events.

Workflow/pipeline design patterns ("Workflow Construction")

A playbook for building multi-agent pipelines that don't hallucinate, built from real case studies of pipelines that failed and were redesigned (for example: agents cross-verifying each other without real independence, producing a high hallucination rate until redesigned for genuine independence). Validated pipeline stages, failure-mode case studies, and the patterns that separate a real autonomous pipeline from one that only looks like one. Use when: designing a multi-stage agent workflow, or diagnosing which stage of a struggling pipeline is broken. Don't use for: single-agent tasks, or governer scoring (that's /governer).

Strategic/architectural blueprint

The "why is the system built this way" oracle, distinct from voice texture — this is the architecture of the thinking, not its texture. Don't use for: operational failure modes, specific UX intents.

Financial/operational audit

Exact performance numbers — payback curves, LTV by channel, cohort data, tactical roadmap. The place for actual data, not the thesis behind it. Don't use for: the strategic thesis (that's Investor Context), domain technique, agent behavioral rules.

Investor due diligence

Source documents for a full valuation picture, if that's relevant to your business — grounded, documented context rather than pitch-deck claims. One example version is configured with a custom system prompt enforcing non-assertive framing and an AI disclaimer on every response, which is a pattern worth copying if you build one of these: ⚠️ "AI can make mistakes. Ask for human validation for anything produced here before acting on any generated outputs." Don't use for: live operational metrics (that's the audit oracle), the strategic narrative (Investor Context), agent/product system internals.

---

Query All at Once

When you don't know which oracle to use, fan out across all of them:

# Via MCP (if a notebooklm-style server is running):
mcp__notebooklm__search_recent({ question: "your question", max_notebooks: 8 })

# Via CLI:
nlm cross query "your question" --max 8 --profile <your profile>

Note: nlm cross query may not support every --profile flag on all versions. If it fails, fall back to your cross-domain synthesis oracle, or to the local fallback described above if you don't have one yet.

---

Also: /jonathan-check2 — Predict the Reaction of the Person You're Working With

Not an oracle notebook by itself — a skill that predicts what the person you're working with would say to your output, including what they'd challenge and what evidence they'd demand. It predicts YOUR person's reaction once you've set it up with your own material (or their own past sessions and stated preferences as a local fallback).

Use before declaring any work done. Invoke: /jonathan-check2

---

Quick Reference (template — replace with your own roster)

Category	What it's for
Rules & antipatterns	Protocol, what gets corrected
Product intent	Feature UX, testable conditions
Session history	Past decisions, what was tried
Domain expertise	The technique/knowledge your product embeds
Business context	Mission, moat, strategic why
Communication playbook	Voice rules, templates, journey logic
Cross-domain synthesis	Connections across all of the above
Voice texture	Reasoning posture, philosophy, if you've built one
Operational failure modes	What's already been learned the hard way
Workflow/pipeline patterns	Anti-hallucination pipeline design
Strategic/architectural blueprint	Why the system is built this way
Financial/operational audit	The actual numbers
Investor due diligence	Valuation and financing documents, if relevant

Build this table from your own roster once you have one — a generated config beats a hand-maintained list, since the two will otherwise drift.