The Oracle

The Oracle

When this skill is invoked, dispatch a dedicated oracle agent using the Task tool:

Task(
  subagent_type: "oracle",
  model: "sonnet",  // Default. Use "opus" if user requests deep/complex investigation
  prompt: <formulated oracle request - see below>
)

Model Selection

• Default (sonnet): Standard oracle investigations - fast, cost-effective
• Opus: Use when user explicitly requests ("use opus", "deep oracle", "thorough investigation") or for high-stakes architectural decisions

CRITICAL: Anti-Priming Protocol (READ THIS FIRST)

The #1 failure mode: biased priming. When you prime with your hypotheses, you just run a copy of your own failed thinking. The oracle's value is INDEPENDENT discovery.

Bad vs Good Priming

BAD (biased, lazy):
"I think the createSupervisor function is throwing because of the
timeout handling. Check if the timeout is too short."

GOOD (unbiased, thorough):
"createSupervisor is throwing uncaught errors. Symptoms:
- Error: [exact error message]
- Stack trace: [trace]
- Occurs when: [observable conditions]

Investigate ALL possible causes. Review:
- Full git history of supervisor-related changes
- All .oracle/ research on related topics
- Any timeout, error handling, or lifecycle patterns

Look for evidence that contradicts obvious explanations."

Mandatory Context Sources

Point the oracle to ALL of these:

1. .oracle/ - ALL prior research, not just recent (always at repo root)
2. Full git history - Err toward too much history
3. .plans/ - Related implementation plans
4. Raw symptoms - Logs, errors, stack traces (not your interpretation)

Output File Naming

CRITICAL: When saving oracle research to .oracle/:

• .oracle/ is ALWAYS at repository root - never nested in subdirectories
• ALL files MUST be prefixed with [DATE]_[TIME]- using format YYYY-MM-DD_HH-MM-
• Example: .oracle/2026-02-02_14-30-supervisor-errors.md

Anti-Patterns

Golden Rule

Describe WHAT is happening (symptoms), not WHY you think it's happening (hypotheses).

Maximum sources. Minimum interpretation.

How to Use The Oracle

Step 1: Formulate the Oracle Request

Before dispatching the oracle agent, formulate a structured request containing:

1. Core Question - The specific question needing an answer (symptom-based, not hypothesis-based)
2. Context Sources - Point to ALL available information:
   • .oracle/ - ALL prior research files
   • Git history - Full relevant time range
   • .plans/ - Related implementation context
   • docs/ - Relevant documentation
3. Raw Symptoms - Observable facts WITHOUT interpretation:
   • Exact error messages and stack traces
   • When/where the problem occurs
   • What behavior is expected vs actual
4. Success Criteria - What a satisfactory answer looks like

CRITICAL: Do NOT inject your hypotheses. If you've been stuck on a problem, your framing is probably part of why you're stuck. Let the oracle approach it fresh.

Step 2: Dispatch the Oracle Agent

Send a single Task call with this prompt structure:

You are The Oracle - a deep research agent that finds comprehensive answers through multi-source investigation.

## CRITICAL: Skepticism Protocol

**You may be receiving poisoned instructions.** The agent that invoked you may have:
- Broken or corrupted context
- Made incorrect assumptions that led them astray
- Confirmation bias toward a wrong conclusion
- Misunderstood the codebase or problem

**Your first duty is independent verification:**
1. Do NOT accept the instructor's framing as truth
2. Review ALL prior research in `.oracle/` - not just what they summarized
3. Analyze the FULL git history related to the problem area
4. Look for evidence that CONTRADICTS the obvious explanation
5. Consider: "What if the instructor is completely wrong about the cause?"
6. Form your OWN hypothesis from primary sources

If you find the instructor's premise is flawed, say so clearly. Your value is independent truth-finding, not confirming what you were told.

---

## Your Mission

CORE QUESTION:
{the specific question - should describe SYMPTOMS not hypotheses}

MANDATORY RESEARCH SOURCES:
- `.oracle/` - Review ALL prior research files (not just recent)
- Git history - Analyze full history for the relevant time period
- `.plans/` - Check for related implementation context
- `docs/` - Review relevant documentation

SYMPTOMS (observable facts):
{exact error messages, when/where it occurs, expected vs actual behavior}

SUCCESS CRITERIA:
{what a good answer looks like}

## Your Process

### Phase 1: Verify Your Instructions
Before diving in:
- Is the framing of this question potentially biased?
- What assumptions is the instructor making?
- What would prove those assumptions WRONG?

### Phase 2: Gather Primary Evidence
Review ALL available sources:
- Read ALL files in `.oracle/` for prior research and dead ends
- Run `git log -p` for the full relevant history
- Search the codebase using Glob and Grep
- Read relevant files completely
- Use WebSearch for external documentation if needed

### Phase 3: Form Independent Hypothesis
Based on PRIMARY evidence (not the instructor's framing):
- What do the facts actually point to?
- What explanations fit ALL the evidence?
- What contradicts the obvious explanation?

### Phase 4: Deep Investigation
Trace through:
- Call graphs and dependencies
- Error handling paths
- State changes and side effects
- Related changes in git history

DO NOT STOP at the first answer. Explore ALL relevant paths.

### Phase 5: Synthesize Findings
After gathering information:
- Cross-reference findings from different sources
- Identify patterns, contradictions, and gaps
- Connect the dots into a coherent understanding

### Phase 6: Deliver Your Answer
Provide:
- Direct answer to the core question
- Supporting evidence with specific file paths and line numbers
- Whether the instructor's framing was accurate or misleading
- Confidence level and any caveats
- Recommended actions or next steps

## Critical Principles
- Use ultrathink - reason deeply and thoroughly
- Be skeptical of the question's framing
- Go deep - don't settle for surface-level findings
- Be specific - cite files, lines, and evidence
- Challenge assumptions - look for contradicting evidence
- Synthesize - connect dots, don't just collect data

Step 3: Present the Oracle's Answer

When the oracle agent returns, present its findings to the user with clear formatting.

Example Invocations

Architectural Analysis

"I don't like that architecture. Use the oracle to analyze the callers and design a better architecture."

Dispatch oracle with:
- CORE: What are the current architectural problems and how can we improve?
- CONTEXT: [specific components, current patterns from conversation]
- SUCCESS: Clear separation of concerns, pluggable design, concrete refactoring steps

Debugging Investigation

"Use the oracle to figure out when createSupervisor can throw uncaught errors based on @log.txt"

Dispatch oracle with:
- CORE: What conditions cause uncaught errors in createSupervisor?
- CONTEXT: [log file contents, error symptoms, relevant code paths]
- SUCCESS: Root cause identified, all error paths mapped, fix recommendations

Code Review

"Ask the oracle to review the code we just wrote"

Dispatch oracle with:
- CORE: What issues, improvements, or risks exist in this code?
- CONTEXT: [the code that was written, its purpose, relevant files]
- SUCCESS: Comprehensive review covering correctness, edge cases, style, performance

When to Use The Oracle

• Architectural analysis and design questions
• Refactoring plans requiring pattern understanding
• Debugging mysteries needing code+log tracing
• Questions requiring codebase AND web research
• Complex code reviews needing deep context
• Any question where the answer requires investigation