Oracle

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:

Copy code
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:

Score → Tier:

Copy code
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

Copy code
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]

Copy code
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]

Copy code
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]

Copy code
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]

Copy code
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]

Copy code
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):

Copy code
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:

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:

Copy code
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:

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

Step 2: Build Synthesis Statement

Before starting any multi-domain task, write:

Copy code
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:

Copy code
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.

Copy code
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:

Final Rule

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