ORACLE — Never Start a Task Cold

The most expensive mistake in software development is starting in the wrong direction. Not bugs. Not technical debt. Wrong direction — 4 hours of work that needs to be thrown away because the problem was misclassified at the start.

Task intake is a 60-second protocol that runs before any implementation begins. It classifies complexity, selects the right skill chain, searches for relevant past solutions, and assigns the appropriate model tier. It is the single highest-leverage intervention in the Superpowers system.

Why 60 Seconds Prevents Hours of Rework

Consider two engineers given the same task: "Add rate limiting to the API."

Engineer A starts typing immediately. They add a middleware, test it locally, open a pull request 40 minutes later. The reviewer comments: this approach uses in-memory state, so it breaks when you deploy to 3 API instances. The engineer redesigns with Redis. Another 2 hours. Total: ~3 hours.

Engineer B takes 60 seconds first. "Touches 2+ files. Requires investigation (what's already there?). Has reliability implications (in-memory vs distributed?). Not novel, but I should check if we've done this before." They search past patterns, find a Redis-based rate limiter pattern from a previous service, adapt it in 30 minutes. Total: ~35 minutes.

The 60-second intake is not overhead — it is the most efficient investment Engineer B made.

The Fast Path: Complexity ≤ 3

Before running the full protocol, do a 5-second triage.

If ALL of these are true, skip the full intake and proceed directly:

• Single file, or fewer than 3 files
• Cause is known — no investigation required
• No security, architecture, or cross-system implications
• You've done this exact type of task before
• No domain skill applies (not ML, AI, embedded, or frontend-specific)

Examples of fast-path tasks:

• Rename a function across a file
• Add a missing null check
• Fix a typo in a string constant
• Update a dependency version in package.json

Announce and proceed: "Complexity ≤ 3 — fast path. Proceeding directly."

If any condition is false — even one — run the full protocol. "This feels simple" is not a valid reason to skip intake. It is the most common rationalization before the most expensive rework.

Phase 1: Complexity Scoring

For any task that does not qualify for the fast path, answer these 8 questions and add up the points:

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

Scores map to tiers:

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

Worked Example: "Add JWT Authentication to the API"

Walk through each question:

• Touches more than 3 files? Yes — routes, middleware, models, tests. +1
• Requires investigation? Yes — need to check what auth exists, what routes need protecting. +1
• Touches 2+ domains? Possibly — if frontend calls are affected. Let's say yes. +1
• Security implications? Yes, this is authentication. +2
• Architecture decisions? Yes — token expiry, refresh strategy, where to store secrets. +2
• Novel? Probably not — JWT is a known pattern. +0
• Cross-system integration? Depends — if an external identity provider is involved. Let's say no. +0
• Performance requirements? Usually not for auth middleware. +0

Score: 7 → COMPLEX. This means: Tier 2→3 model, full skill chain, plan required. If you had started immediately, you would likely miss the architecture decisions and end up with insecure token handling.

Phase 2: Skill Chain Selection

Once you have the complexity score, select the matching skill chain.

Bug? → debug-chain:

1. learning-from-experience → search similar past bugs
2. systematic-debugging     → root cause investigation
3. test-driven-development  → failing test before fix
4. SENTINEL → verify fix works
5. learning-from-experience → store pattern

New feature? → feature-chain:

1. learning-from-experience → search similar past features
2. [domain skill(s)]        → apply domain expertise if applicable
3. brainstorming            → design before code (score ≥ 4)
4. writing-plans            → implementation plan (score ≥ 5)
5. model-routing            → assign tier per subtask
6. swarm-coordination       → parallel agents for 3+ independent files
7. SENTINEL → gate before completion
8. requesting-code-review   → review gate (score ≥ 7)
9. learning-from-experience → store pattern

Refactor? → refactor-chain:

1. test-driven-development  → baseline tests before touching code
2. writing-plans            → plan the refactor (score ≥ 5)
3. SENTINEL → no regression
4. learning-from-experience → store pattern

Architecture decision? → architecture-chain:

1. learning-from-experience → past architecture decisions
2. brainstorming            → explore 2–3 approaches with trade-offs
3. writing-plans (SPARC)    → SPARC structure required
4. requesting-code-review   → architecture review gate
5. learning-from-experience → store decision + rationale

Not every step in a chain is mandatory at every complexity level. Steps marked "score ≥ N" are skipped for simpler tasks.

Phase 3: Pattern Search

Before starting any task with complexity ≥ 4, search the ReasoningBank — your accumulated pattern library.

Query: "<task-type> <domain> <keywords>"

Examples:
  "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 is different about this context? Note it.

Announce what you found:

"Found 2 relevant patterns:

1. jwt-stateless — implemented this in the payments service; token expiry 15m refresh 7d worked well
2. jwt-refresh-rotation — avoid reuse detection pattern without Redis, caused session loss under load Applying: using stateless JWT, 15m expiry, 7d refresh, no refresh token reuse detection in this MVP"

If nothing is found, say: "No prior patterns. Novel problem — will store pattern after solving."

The pattern search is what makes the system compound. Early sessions find nothing. After 10 sessions, you are building on a library of your own solved problems. After 50, you rarely solve the same problem twice.

Phase 4: Model Tier Assignment

Assign the right Claude model to the task:

| Complexity | Tier | Model | |-----------|------|-------| | 1–3 | 0/1 | Direct (no LLM) or Haiku | | 4–6 | 2 | Sonnet | | 7–9 | 2→3 | Sonnet, escalate to Opus if stuck | | 10 | 3 | Opus |

Tier 0 (no LLM) applies to purely mechanical transforms: var→const rename, sort imports, reformat code. These are zero-cost and instant — do not waste an LLM call on them.

Tier 1 (Haiku) applies to simple lookups, single-file edits, text transforms.

Tier 2 (Sonnet) is the default for most real development work. Standard bugs, feature additions, tests.

Tier 3 (Opus) is reserved for security-critical code, architecture decisions, complex debugging across multiple systems.

The cost difference between Tier 1 and Tier 3 is roughly 20×. Systematically routing easy tasks to lower tiers cuts API costs by 50–65% compared to treating everything as a Tier 3 problem.

Phase 5: SPARC Gate

SPARC (Specification → Pseudocode → Architecture → Refinement → Coding) is required — not optional — when any of:

• Complexity score ≥ 8
• Task involves security-critical code
• Task involves architecture decisions
• Task is cross-system integration
• This task has been attempted before and failed

When SPARC is required, the implementation does not begin until the S and A phases are explicitly written and reviewed. This prevents the most common failure mode for complex tasks: starting implementation before the problem is fully understood.

The Intake Output Template

After all 5 phases, Claude announces:

TASK INTAKE COMPLETE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Complexity:   7/10 → COMPLEX
Domain(s):    Backend (security)
Task type:    Feature
Skill chain:  feature-chain
Model tier:   2 (escalate to 3 if stuck)
SPARC:        Required
Patterns:     2 found — applying jwt-stateless pattern

Proceeding with feature-chain.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

This output is visible in the conversation. It creates shared understanding: you can immediately see if Claude misclassified the task and correct it before any code is written.

The After-Action Review

Task intake has a close protocol that runs when work completes. This is the step that most engineers skip — and the one that determines whether the system gets smarter.

After every task with complexity ≥ 6, or any task where something unexpected happened, run:

AFTER-ACTION REVIEW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Did the skill chain work as planned?
   ✓ Yes — as expected
   ✗ Partially — brainstorming was skipped, should have included it

2. Was the complexity score accurate?
   Predicted: 7 | Actual feel: 8 — security implications were deeper than expected

3. Was the model tier right?
   ✓ Sonnet was adequate — no escalation needed

4. What pattern should be stored?
   Key: backend:security:jwt-refresh
   ✓ Storing now

5. What would I do differently?
   Start with checking existing auth middleware before designing new one
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The after-action takes 2 minutes. It feeds the pattern library, calibrates future complexity scoring, and surfaces process improvements. Without it, the system does not learn.

The Rationalization Table

These thoughts are reliable indicators that you are about to skip intake and regret it:

| Thought | Reality | |---------|---------| | "I know exactly what to do" | Knowing what ≠ knowing best. Intake confirms. | | "This is obviously simple" | Simple tasks rarely stay simple. Scope always grows. | | "The user wants it fast" | Wrong direction is slower than 60-second intake. | | "I've done this before" | Context differs. Old approach may not fit new constraints. |

The rule is simple: classify before you code. Every time.

Key Takeaway

Task intake is a 60-second protocol: score complexity on 8 dimensions, select the matching skill chain, search past patterns, assign model tier, and apply SPARC if required. Fast path exists for complexity ≤ 3 tasks only. The after-action review at task close feeds the pattern library and makes the system smarter with every completed task. The single most important habit in the entire Superpowers system is running intake before any non-trivial work begins.