Deep Think Maximum Cognitive Effort Protocol Mq8kvw92 Agent Skill

/deep-think — Maximum Cognitive Effort Protocol

Goal: Activate the highest level of cognitive architecture for complex, multi-step, or ambiguous tasks where quality matters more than speed.

Time: 5-15 minutes depending on complexity tier.

When to use: Architecture decisions, multi-system changes, irreversible actions, anything where being wrong is expensive.

> This is NOT /reason. /reason = "follow the reasoning engine checklist" (fast, lightweight).

> /deep-think = "maximum effort with structured thinking, research, gap analysis, multi-perspective debate, and adversarial review" (slow, thorough).

Complexity Gate (decide first)

Before starting, classify the task:

| Tier | When | Phases Used |

|------|------|-------------|

| SIMPLE | Quick but thorough — single-domain analysis, clear question | Phases 1 + 5 only |

| MEDIUM | Research + analysis — multi-source synthesis, comparison | Phases 1-5 |

| COMPLEX | Full adversarial — architecture decisions, multi-system changes, irreversible actions | All 8 phases |

Phase 1: ORIENT (Memory + Context)

Load ALL available context before forming any opinion.

• Read project memory if available (e.g., MEMORY.md, SESSION.md, or status logs)
• Read known pitfalls and gotchas for the target domain (e.g., knowledge/gotchas.md if present)
• Read the most relevant local knowledge, READMEs, or chunk files
• Query any active workspace memory system (e.g., Honcho or agentmemory) when recent session continuity is needed
• Check conversation logs or history for prior attempts or context on this topic
• Identify which projects, modules, or systems are involved

If any tool fails: Note "degraded mode" and continue with available sources. Do NOT stall.

Phase 2: QUESTION (Challenge the Request)

Before solving, challenge the problem statement itself.

• Use a sequential thinking or reasoning tool (such as sequential-thinking MCP, if available) to decompose the problem into component parts
• Ask explicitly:
• "Is this the right question? Is there a better framing?"
• "What assumptions are embedded in this request?"
• "What would go wrong if I do the obvious thing?"
• "Has this been attempted before? What happened?"
• If the framing reveals a deeper issue, address THAT instead

Phase 3: RESEARCH (Evidence Collection)

Gather evidence from multiple sources. Do NOT rely on training data alone.

• Run web searches for current best practices, official documentation, and known issues
• Use available documentation search tools (such as Context7 MCP, if available) for any referenced libraries, frameworks, or APIs
• Check repository skills and custom workspace procedures (e.g., under .agent/skills/ or similar locations)
• Load domain-specific context or chunk files using workspace routing maps (e.g., WORKSPACE-AUTOMAP.md or equivalent)
• Review workspace-specific conventions and code style files (e.g., knowledge/conventions.md or local READMEs) for established patterns

Rule: Every factual claim must trace to a retrieved source, not memory.

Phase 4: AUDIT (Gap Analysis)

For architecture and system tasks. Skip for pure analysis questions.

• What exists? List all relevant files, tools, configs currently in place
• What SHOULD exist? Based on research and requirements, what's the ideal state?
• What's the delta? Enumerate every gap between current and ideal
• What's stale? Cross-reference sources for contradictions and outdated information
• What's broken? Check tool health, file integrity, reference validity

Phase 5: SYNTHESIZE (Multi-Perspective Analysis)

Evaluate the problem from multiple expert perspectives.

• Council of Experts — consider the problem as:
• A Lead Developer: Is this technically sound? What are the edge cases?
• A Business/Product Strategist: Does this serve the core project objectives and business outcomes?
• A UX/Ops Pro: Is this maintainable? Will it create friction?
• Reconcile conflicts between perspectives and sources
• Produce a structured recommendation with:
• The recommended approach
• The key tradeoff
• The risk if wrong
• The success criteria

Phase 6: PLAN (Surgical Execution Design)

Break the recommendation into executable steps.

• Decompose into the smallest possible steps — each independently verifiable
• Run the 5-step Pre-Action Verification Protocol on EACH step:
• Are assumptions stated?
• Am I targeting the correct file/resource?
• Is scope minimal?
• Is action reversible?
• What are the success criteria?
• Define measurable success criteria for the overall task
• Sequence steps so failures are caught early (dependencies first)

Phase 7: EXECUTE + VERIFY (Work → Check → Correct)

Execute the plan one step at a time.

• One step at a time. Verify output after each step before proceeding.
• Work → Verify → Self-Correct loop. Do not assume success.
• Anti-Bulk Enforcement: Use the most surgical edit mechanism available. Never rewrite files unless creating from scratch.
• 80% Confidence Threshold: If confidence drops below 80% on a high-stakes decision, STOP and ask the user/product owner for input.
• Follow Karpathy Doctrine: surgical, minimal, explicit.

Phase 8: CHALLENGE (Adversarial Self-Review)

After producing the result, attack it.

• Re-read the original request word by word. Did you actually answer THE question?
• What did you miss? What would a senior expert critique about this output?
• Would you stake your reputation on this? If not, what needs to change?
• Edge cases: What happens under unusual conditions? Empty inputs? Scale? Concurrent use?
• Save key learnings to the appropriate memory layer:
• Debugging insights → update known gotchas (e.g., knowledge/gotchas.md)
• New patterns → update conventions/standards (e.g., knowledge/conventions.md)
• Decisions made → update decisions log (e.g., knowledge/decisions.md)
• Recent continuity worth reusing soon → write a milestone/handoff breadcrumb to the workspace memory system (e.g., Honcho or agentmemory)

What This Workflow Does NOT Do

• It does NOT replace /reason for quick analysis — use /reason for fast reasoning engine activation.
• It does NOT save session state — that's /wrap.
• It does NOT consolidate memory — that's /dream.