Oracle

---
name: oracle
description: Pre-task intelligence layer — classify complexity, select skill chain, search patterns, assign model tier. Run BEFORE any non-trivial task begins. Turns the system from reactive to proactive.
type: process
---

# Task Intake

## Overview

**ORACLE** — *Latin "oraculum": the prophetic voice consulted before any major decision.*
When invoked: scores task complexity 1–10 across 8 dimensions, selects the optimal skill chain (BUG / FEATURE / REFACTOR / ARCHITECT), assigns the correct model tier (Haiku → Opus), and searches memory for relevant past patterns — all in 60 seconds before any code is written.


**Core principle:** Never start a task cold. 60 seconds of classification prevents hours of wrong-direction work.

This skill is the **meta-intelligence layer** of Superpowers. It classifies every task before execution, selects the optimal skill chain, searches for relevant past patterns, and assigns the correct model tier — automatically.

**Announce at start:** "Running ORACLE to classify and plan approach."

**WHEN TO RUN:**
- Before ANY task that touches code or architecture
- Before ANY bug investigation
- Before ANY new feature or design decision
- At the start of EVERY non-trivial conversation

**SKIP only for:** Trivial one-liner answers, pure information questions, file reads.

---

## Fast Path (Complexity ≤ 3)

Before running all 5 phases, do a **5-second triage**:

```
Is ALL of the following true?
  ✓ Single file or fewer than 3 files
  ✓ No investigation required — cause is known
  ✓ No security, architecture, or cross-system implications
  ✓ Similar task done before (no novelty)
  ✓ No domain skill triggers

→ FAST PATH: Skip Phases 2–5.
  Announce: "Complexity ≤ 3 — fast path. Tier 1, no plan needed."
  Proceed directly to implementation.
```

If ANY condition is false, run the full 5-phase intake.

---

## Phase 1: Task Classification (30 seconds)

### Step 1: Score Complexity (1–10)

Answer each question honestly:

| Question | +Points |
|----------|---------|
| Touches more than 3 files? | +1 |
| Requires investigation before implementation? | +1 |
| Touches 2+ engineering domains? | +1 |
| Has security implications? | +2 |
| Involves architecture decisions? | +2 |
| Novel problem (no precedent in codebase)? | +2 |
| Cross-system integration? | +1 |
| Strict performance or timing requirements? | +1 |

**Score → Tier:**
```
1-3:  SIMPLE     → Tier 0/1 model, single skill, no plan needed
4-6:  STANDARD   → Tier 1/2 model, 2-4 skills, plan recommended
7-9:  COMPLEX    → Tier 2/3 model, full skill chain, plan required
10:   CRITICAL   → Tier 3 model, SPARC structure, human review gate
```

### Step 2: Identify Domain(s)

Check all that apply:

- [ ] **Frontend / UI** → invoke `prism`
- [ ] **ML / Data Science** → invoke `gradient`
- [ ] **AI / LLM / RAG / Agents** → invoke `nexus`
- [ ] **Embedded / Firmware / EE** → invoke `ironcore`
- [ ] **General backend / web** → standard skills
- [ ] **Multi-domain** → invoke all relevant domain skills

### Step 3: Identify Task Type

```
Is this a BUG?
└─ Yes → [debug-chain]

Is this a NEW FEATURE?
└─ Yes → [feature-chain]

Is this a REFACTOR?
└─ Yes → [refactor-chain]

Is this an ARCHITECTURE DECISION?
└─ Yes → [architecture-chain]

Is this a RESEARCH / EXPLORATION?
└─ Yes → [research-chain]
```

---

## Phase 2: Skill Chain Selection

**Pre-built chains — use the matching one, execute skills in order:**

### [debug-chain]
```
1. chronicle            → search for similar past bugs
2. hunter               → root cause investigation
3. forge                → failing test before fix
4. sentinel             → verify fix works
5. chronicle            → store pattern after success
```

### [feature-chain]
```
1. chronicle            → search for similar past features
2. [domain skill(s)]         → apply domain expertise
3. architect            → design before code (complexity ≥ 4)
4. blueprint            → implementation plan (complexity ≥ 5)
5. vector               → assign tier per task
6. legion               → topology if 3+ independent files
7. phantom              → execute plan (complexity ≥ 6)
8. sentinel             → gate before completion
9. tribunal             → review gate (complexity ≥ 7)
10. chronicle            → store pattern after success
```

### [refactor-chain]
```
1. chronicle            → search past refactor patterns
2. forge                → baseline tests before touching code
3. blueprint            → plan the refactor (complexity ≥ 5)
4. vector               → tier 1/2 for mechanical work
5. sentinel             → no regression
6. chronicle            → store pattern
```

### [architecture-chain]
```
1. chronicle            → past architecture decisions
2. architect            → explore 2-3 approaches
3. blueprint (SPARC)    → SPARC structure REQUIRED
4. tribunal             → architecture review gate
5. chronicle            → store decision + rationale
```

### [research-chain]
```
1. chronicle            → search existing knowledge
2. legion (Mesh)        → parallel investigation
3. architect            → synthesize findings
4. chronicle            → store findings
```

---

## Phase 3: Pattern Search

**BEFORE starting ANY task (complexity ≥ 4):**

```
SEARCH ReasoningBank:
Query: "<task-type> <domain> <key-keywords>"

Example:
- "feature ml-engineering data-drift detection"
- "debug frontend react useEffect stale closure"
- "architecture api jwt multi-tenant"

REVIEW matches:
- What worked? Apply directly.
- What failed? Avoid explicitly.
- What's different? Note context differences.

ANNOUNCE findings:
"Found [N] relevant patterns:
 1. [key] — [one-sentence summary]
 Applying: [how it influences this approach]"

If no matches:
"No prior patterns. Novel problem — will create pattern after solving."
```

---

## Phase 4: Model Tier Assignment

Use the decision from `vector` skill. Quick summary:

| Complexity Score | Start Tier | Notes |
|-----------------|------------|-------|
| 1–3 | Tier 0/1 (direct/Haiku) | Mechanical or single-file |
| 4–6 | Tier 2 (Sonnet) | Standard development |
| 7–9 | Tier 2→3 (Sonnet→Opus) | Escalate if stuck |
| 10 | Tier 3 (Opus) | Architecture/security critical |

---

## Phase 5: SPARC Gate

**SPARC is REQUIRED (not optional) when ANY of:**
- Complexity score ≥ 8
- Task involves security-critical code
- Task involves architecture decisions (system design)
- Task is cross-system integration
- Task has been attempted before and failed

**SPARC is optional when:**
- Complexity score ≤ 7
- Clear requirements exist
- Similar task done before (patterns found)

---

## Task Intake Output Template

After completing all 5 phases, announce:

```
TASK INTAKE COMPLETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Complexity:   [score]/10 → [SIMPLE/STANDARD/COMPLEX/CRITICAL]
Domain(s):    [list]
Task type:    [debug/feature/refactor/architecture/research]
Skill chain:  [chain name]
Model tier:   [0/1/2/3]
SPARC:        [Required/Optional]
Patterns:     [N found | 0 found — novel]

Proceeding with [chain name] chain.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

---

## Multi-Domain Synthesis

When a task touches **2+ engineering domains simultaneously**, conflicting guidance can arise. Resolve it before starting work.

### Step 1: Identify Conflicts

After invoking domain skills, check for contradictions:

| Conflict Type | Example | Resolution |
|--------------|---------|------------|
| Language conflict | ML says Python, EE says C only | Platform constraint wins — use C with Python for offline tooling |
| Memory model conflict | ML wants dynamic allocation, EE says no malloc in ISR | ISR constraint is absolute — use static allocation + offline training |
| Latency conflict | AI wants cloud LLM, EE needs <10ms response | Latency is physical — use on-device model or precomputed responses |
| Framework conflict | Frontend wants React, Backend wants server render | Explicit user constraint wins; if none, prefer existing codebase pattern |

**Rule: Physical/hardware constraints always win over software preferences.**

### Step 2: Build Synthesis Statement

Before starting any multi-domain task, write:

```
MULTI-DOMAIN SYNTHESIS
━━━━━━━━━━━━━━━━━━━━━━
Domains:    [domain 1] + [domain 2] (+ [domain 3])
Conflicts:  [list any conflicting guidance]
Resolution: [which constraint wins and why]
Unified constraint: [the combined non-negotiables]
━━━━━━━━━━━━━━━━━━━━━━
```

### Step 3: Add Domain Reviewers

For multi-domain code review, specify ALL relevant domains:
```
DOMAIN: ml, embedded
```
The reviewer will apply both checklists.

---

## After-Action Review (Task Close Protocol)

**Run this AFTER every task completes — before moving to the next.**

This closes the learning loop. Without it, patterns are stored inconsistently or not at all.

```
AFTER-ACTION REVIEW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Did the skill chain work as planned?
   [ ] Yes — as expected
   [ ] Partially — [what deviated]
   [ ] No — [what went wrong]

2. Was the complexity score accurate?
   Predicted: [N] | Actual feel: [lower/accurate/higher]
   → [adjust future scoring for this task type]

3. Was the model tier right?
   [ ] Yes — tier [N] was appropriate
   [ ] Should have been higher — [why]
   [ ] Could have been lower — [why]

4. What pattern should be stored?
   Key: <domain>:<type>:<keywords>
   [ ] Storing now in auto-memory
   [ ] Nothing novel — skipping storage

5. What would I do differently?
   [one sentence or "nothing"]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

**After-action is mandatory when:**
- Task complexity was ≥ 6
- Something unexpected happened
- A novel approach was used
- The first approach failed

**After-action is optional when:**
- Complexity < 4 and everything went as expected
- Mechanical task with no surprises

**Storage:** If a pattern is worth storing, invoke `chronicle` now.

---

## Integration with Superpowers

**Calls into:**
- `chronicle` — pattern search before task
- `vector` — tier selection
- `legion` — topology selection
- `architect` — when complexity ≥ 4 + feature task
- `blueprint` — when complexity ≥ 5
- `hunter` — when task type is debug

**Called by:**
- `ascend` — ORACLE is the FIRST process skill for non-trivial tasks

---

## Red Flags

**Never skip ORACLE when:**
- You feel "this is obviously simple" (obvious ≠ simple)
- You're under time pressure (intake is 60 seconds, saves hours)
- The user says "just quickly..." (scope always grows)
- You've started before thinking (stop, run intake)

**Rationalization table:**

| Thought | Reality |
|---------|---------|
| "I know what to do" | Knowing ≠ best approach. Intake confirms. |
| "Too simple for intake" | Simple tasks rarely stay simple. |
| "User wants it fast" | Wrong approach is slower than 60-second intake. |
| "I'll plan as I go" | Unplanned work creates rework. |

---

## Final Rule

```
60 seconds of intake → hours saved
No task starts cold
Classify → chain → search → tier → execute
```