Deep Problem Solving (Structured Thinking)

Purpose: Complete thinking toolkit for problem-solving: ideate (divergent) → synthesize (integration) → refine (convergent). Process complex queries through structured thinking cycles.

Behavior: When active, apply the appropriate thinking mode based on the task. Default to full cycle for comprehensive exploration.

Mindset: Apply /pb-preamble thinking (challenge assumptions) throughout. Look for non-obvious angles, hidden patterns, and actionable insights.

Resource Hint: sonnet - Structured thinking facilitation; routine problem-solving workflow.

Modes Overview

Usage:

• /pb-think - Full cycle (ideate → synthesize → refine)
• /pb-think mode=ideate - Divergent exploration only
• /pb-think mode=synthesize - Integration only
• /pb-think mode=refine - Convergent refinement only

Mode: Full Cycle (Default)

Run all three thinking phases in sequence:

┌─────────────────────────────────────────────────┐
│  IDEATE                                         │
│  Generate options without judgment              │
│  Apply lenses, push for quantity                │
└─────────────────────┬───────────────────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────────┐
│  SYNTHESIZE                                     │
│  Integrate options into coherent view           │
│  Find patterns, resolve tensions                │
└─────────────────────┬───────────────────────────┘
                      │
                      ▼
┌─────────────────────────────────────────────────┐
│  REFINE                                         │
│  Polish to publication-grade                    │
│  Critique, fix weaknesses, deliver final        │
└─────────────────────────────────────────────────┘

Directive for full cycle:

1. Diverge first (10+ options)
2. Cluster and find patterns
3. Spotlight 2-3 most interesting
4. Synthesize into coherent recommendation
5. Refine through internal critique
6. Deliver polished, actionable output

Mode: Ideate (Divergent)

Explore possibilities through structured divergent thinking. Generate options before evaluating them. Breadth enables quality.

Directive

For ideation requests:

1. Diverge first - Generate 10+ options before evaluating any
2. Explore adjacent space - What’s near the obvious answers?
3. Invert the question - What’s the opposite approach?
4. Cross-pollinate - What would another domain do here?
5. Defer judgment - No “but that won’t work” during generation
6. Surface non-obvious - Force at least 3 unexpected angles

Do not converge prematurely. Do not evaluate while generating. Push past the first ideas to find the interesting ones.

Ideation Lenses

Apply multiple lenses systematically. Each lens forces a perspective shift.

Lens 1: Scale

Stretch the problem across dimensions:

• What if 10x smaller? 10x bigger?
• What if instant? What if it took a year?
• What if one person? What if 1000 people?
• What if zero budget? Unlimited budget?
• What if for one day? What if forever?

Lens 2: Inversion

Flip assumptions:

• What’s the opposite of the obvious solution?
• How would we make this problem worse? (reveals hidden constraints)
• What if we did nothing? What happens?
• What would we do if this wasn’t a problem?
• What if the constraint is actually the feature?

Lens 3: Analogy

Borrow from elsewhere:

• How does nature solve this? (biomimicry)
• How did history handle similar challenges?
• What would [Amazon/Apple/startup/nonprofit] do?
• How is this solved in [gaming/healthcare/finance/military]?
• What’s the physical-world equivalent? Digital equivalent?

Lens 4: Stakeholders

Shift the viewer:

• What would users hate? (reveals assumptions)
• What would delight users unexpectedly?
• What would a competitor do with this opportunity?
• What would a regulator worry about?
• What would someone new to this domain try?

Lens 5: Constraints

Add or remove limits:

• What if we had to ship tomorrow?
• What if we had 5 years and no pressure?
• What if we could only use existing tools?
• What if we had to build everything from scratch?
• What if we could break one rule?

Lens 6: Decomposition

Break it apart:

• What are the sub-problems? Solve each differently.
• What’s the core vs the wrapper?
• What’s the 20% that delivers 80% of value?
• What can be deferred? What must be solved now?
• What’s the smallest version that teaches us something?

Ideate Output Format

Phase 1: Rapid Generation

List 10-15+ options. One line each. No evaluation, no caveats, no “but.”

1. [Option]
2. [Option]
...
15. [Option]

Include bad ideas. They often spark good ones.

Phase 2: Clustering

Group options into 3-5 themes or strategic approaches:

**Theme A: [Name]**
- Options 1, 4, 7

**Theme B: [Name]**
- Options 2, 5, 9

**Theme C: [Name]**
- Options 3, 6, 8, 10

Phase 3: Spotlight

Identify 2-3 non-obvious options worth deeper exploration:

**Worth exploring:**

1. [Option X] - Why: [unexpected angle, challenges assumption, or high leverage]
2. [Option Y] - Why: [combines strengths, addresses root cause, or novel approach]
3. [Option Z] - Why: [low effort high learning, or opens new possibilities]

Do not pick the safest options. Pick the most interesting ones.

Phase 4: Next Step

Recommend concrete next action:

• Which option(s) to prototype or explore further
• What question to answer before deciding
• When to shift from ideation to evaluation

Ideate Example

User: “We need to reduce API response times. What are our options?”

Phase 1: Rapid Generation

1. Add Redis caching layer
2. Database query optimization (indexes, query rewrite)
3. CDN for static responses
4. Pagination/lazy loading
5. Async processing with webhooks
6. GraphQL to reduce over-fetching
7. Edge computing (move logic closer to users)
8. Precompute expensive operations
9. Connection pooling tuning
10. Compress response payloads
11. Split into microservices (isolate slow parts)
12. Do nothing-is the latency actually hurting users?
13. Charge for faster tier (make it a feature)
14. Batch requests client-side
15. Predictive prefetching

Phase 2: Clustering

• Caching/Precompute: 1, 8, 15
• Data Layer: 2, 9
• Architecture: 6, 7, 11
• Client-Side: 4, 14
• Reframe Problem: 12, 13

Phase 3: Spotlight

1. Option 12 (do nothing) - Worth validating if latency actually impacts users. Cheapest path if problem is perceived not real.
2. Option 8 (precompute) - If responses are derivable from known inputs, shift work to write-time. High leverage for read-heavy APIs.
3. Option 7 (edge computing) - If users are geographically distributed, physics beats optimization. Different solution class.

Phase 4: Next Step Measure current latency by endpoint and correlate with user complaints. If P95 latency is fine but P99 is bad, focus on outliers (likely Option 2). If latency is uniform, consider Option 8 or 7.

Mode: Synthesize (Integration)

Combine multiple inputs, perspectives, or sources into coherent insight. Transform raw material into actionable understanding.

Directive

For synthesis requests:

1. Map the inputs - What sources, perspectives, or data points exist?
2. Find patterns - What themes recur? What correlates?
3. Surface tensions - Where do inputs contradict? What’s the real conflict?
4. Extract signal - What’s actually important vs noise?
5. Form coherent view - Integrate into unified understanding
6. Make it actionable - What does this synthesis mean for decisions?

Do not summarize-synthesize. Summaries compress; synthesis integrates. The output should reveal something the inputs alone don’t show.

Synthesis Modes

Mode 1: Multi-Source Integration

Combining research, documents, or data from multiple sources.

Process:

1. List sources and their key claims
2. Identify agreements (reinforcing signals)
3. Identify contradictions (tensions to resolve)
4. Assess source credibility and bias
5. Form integrated conclusion with confidence level

Output format:

## Sources Analyzed
[List with 1-line summary of each source's position]

## Convergence
[What multiple sources agree on - high confidence]

## Divergence
[Where sources conflict - with analysis of why]

## Synthesis
[Integrated view that accounts for both]

## Confidence & Gaps
[What we know vs what remains uncertain]

## Implications
[What this means for the decision/action at hand]

Mode 2: Perspective Integration

Combining viewpoints from different stakeholders or disciplines.

Process:

1. Map each perspective’s priorities and concerns
2. Identify shared ground (often hidden)
3. Identify genuine conflicts (not just framing differences)
4. Find integrative solutions that address multiple concerns
5. Flag irreconcilable trade-offs honestly

Output format:

## Perspectives Mapped
[Each stakeholder/discipline and their core concerns]

## Hidden Common Ground
[Shared interests that framing obscured]

## Genuine Conflicts
[Real trade-offs, not misunderstandings]

## Integrative Options
[Solutions that address multiple perspectives]

## Remaining Trade-offs
[What can't be resolved - requires decision]

Mode 3: Learning Integration

Combining insights from experiments, iterations, or experience.

Process:

1. List what was tried and what happened
2. Identify what worked (and why)
3. Identify what failed (and why)
4. Extract transferable principles
5. Define what to do differently

Output format:

## Experiments/Iterations Reviewed
[What was tried]

## What Worked
[Successes with causal analysis]

## What Failed
[Failures with causal analysis]

## Principles Extracted
[Transferable insights, not just observations]

## Recommended Changes
[Specific adjustments for next iteration]

Mode 4: Research Synthesis

Combining findings from investigation or discovery phase.

Process:

1. Catalog findings by category
2. Separate facts from interpretations
3. Identify the “so what” - why findings matter
4. Connect to original questions
5. Surface new questions raised

Output format:

## Findings by Category
[Organized raw findings]

## Facts vs Interpretations
[What's verified vs inferred]

## Key Insights
[The "so what" - why this matters]

## Questions Answered
[Original questions and their answers]

## New Questions Raised
[What we now need to investigate]

Synthesis Techniques

Technique 1: Triangulation

When multiple sources point to the same conclusion through different paths, confidence increases.

Source A (user interviews): Users complain about speed
Source B (analytics): 40% drop-off at loading screen
Source C (support tickets): "slow" mentioned 3x more than last quarter

Triangulated conclusion: Performance is a real problem, not perception
Confidence: High (three independent signals converge)

Technique 2: Tension Mapping

When sources conflict, map the tension explicitly rather than ignoring it.

Tension: Engineering says "ship fast" vs QA says "more testing needed"

Surface conflict: Speed vs quality
Deeper analysis: Both want successful launch; disagree on risk tolerance
Root issue: No shared definition of "launch-ready"

Resolution path: Define launch criteria together, then both optimize for it

Technique 3: Signal vs Noise Filtering

Not all information deserves equal weight.

Signal indicators:

• Multiple independent sources confirm
• Comes from direct observation, not hearsay
• Specific and falsifiable
• Aligns with incentives and behavior

Noise indicators:

• Single source, unverified
• Vague or unfalsifiable
• Contradicts observed behavior
• Source has obvious bias or incentive to mislead

Technique 4: Gap Analysis

What’s missing from the inputs is often as important as what’s present.

## What We Have
- User feedback (qualitative)
- Usage analytics (quantitative)
- Competitor analysis

## What's Missing
- Cost data (can't assess ROI)
- Technical feasibility assessment
- Timeline constraints

## Impact of Gaps
Can prioritize by user value, but can't sequence by effort or cost

Synthesis Quality Standards

Good Synthesis:

• Reveals insight not visible in individual inputs
• Explicitly addresses contradictions
• Distinguishes high-confidence from uncertain conclusions
• Actionable-clear implications for decisions
• Acknowledges gaps and limitations

Bad Synthesis:

• Just summarizes each input sequentially
• Ignores contradictions or hand-waves them away
• Treats all sources as equally credible
• Abstract conclusions with no decision implications
• Overstates confidence, ignores uncertainty

Synthesize Example

User: “I’ve done user interviews, looked at analytics, and reviewed competitor products. Help me synthesize what we should build.”

Sources Analyzed:

• User interviews (8 users): Want faster workflows, confused by navigation
• Analytics (30-day): 60% drop-off at step 3 of onboarding, power users skip tutorials
• Competitors: All have simpler onboarding, 2 of 3 have keyboard shortcuts

Convergence (High Confidence):

• Onboarding is a problem - both users and data confirm
• Speed matters to engaged users - interviews and competitor patterns align

Divergence:

• Users say they want “more features” but analytics show feature discovery is low
• Contradiction suggests: users want capability, not complexity

Synthesis: The core issue isn’t missing features-it’s that existing features are hard to access. Users who succeed become power users; most don’t get there because onboarding fails. Competitors solved this with simpler initial experience and progressive disclosure.

Confidence & Gaps:

• High confidence: Onboarding needs simplification
• Medium confidence: Keyboard shortcuts would help power users (based on competitor inference, not direct validation)
• Gap: No data on which specific onboarding steps cause confusion

Implications:

1. Prioritize onboarding simplification over new features
2. Add analytics to identify exact friction points in steps 1-3
3. Consider keyboard shortcuts for power user path (validate with 2-3 users first)

Next Action: Instrument onboarding steps with detailed analytics before redesigning. Need data on where exactly users get stuck.

Mode: Refine (Convergent)

Process through internal draft-critique-refine cycles before responding. Deliver expert-quality answers without user re-prompting.

Directive

For each query requiring refinement:

1. Draft internally - Generate initial response
2. Critique internally - Red-team your own draft ruthlessly
3. Refine internally - Rewrite to expert standard
4. Deliver final only - User sees polished output, not iterations

Do not ask for permission to iterate. Do not show intermediate passes. Think deeply, refine thoroughly, respond once.

Internal Pass 1: Draft

Generate a working response:

• Answer the question directly
• Include relevant context
• Don’t overthink - this is raw material

Internal Pass 2: Critique

Red-team your draft. Check each dimension:

Alignment

• What did they actually ask?
• What did I deliver?
• Any mismatch?

Weaknesses

Identify the 5 weakest points. Be specific:

WEAK: "consider various factors" - vague, no specifics
WEAK: "this can help" - passive, no mechanism explained

Gaps

• Missing facts or data?
• Missing steps they’ll need?
• Missing examples?
• Ignored edge cases or constraints?

Assumptions

Label each:

• Confirmed - stated or verifiable
• Reasonable - fair inference
• Unverified - assumed without basis (flag these)

Risks

Where could this be:

• Wrong (factually incorrect)
• Misleading (true but misses the point)
• Impractical (won’t work in reality)

AI Patterns

Detect and plan to fix:

Rewrite Plan

• What to cut
• What to add
• What to restructure

Internal Pass 3: Refine

Rewrite to publication-grade:

1. Direct answer first - 1-2 sentences, no preamble

2. Actionable content - Steps executable today, not theoretical

3. Concrete examples - At least 2, tailored to their context

4. Specifics over vague claims

   • NOT: “improves performance”
   • YES: “reduces query time from 2s to 200ms”

5. Honest uncertainty - “I cannot confirm X” beats false confidence

6. Natural voice

   • No filler
   • Varied sentence length
   • No generic tips

7. Pitfalls section - 3-6 bullets an expert would nod at

8. Clear close - Key point + immediate next action

Quality Bar

If a domain expert reviewed this, they’d find it accurate, grounded, and immediately implementable.

Refine Example

User query: “How should I structure error handling in a Go service?”

Internal Pass 1: Draft covering error wrapping, sentinel errors, panic/recover…

Internal Pass 2: Critique finds:

• Weakness: “consider using errors.Is” is vague - needs code example
• Gap: Didn’t cover structured logging of errors
• AI tell: “Let’s explore…” opener - delete
• Rewrite plan: Lead with the pattern, add code, include pitfalls

Internal Pass 3: Refine to tight, example-driven response

Delivered response: (final only - polished, specific, actionable)

When to Use Each Mode

Scope

Apply Thinking Partner To

• Complex questions requiring reasoning
• Research or analysis tasks
• Problems with multiple valid approaches
• Decisions with trade-offs
• Anything where quality > speed

Skip Thinking Partner For

• Simple factual lookups
• Direct commands (“run this”, “delete that”)
• When user explicitly wants quick/rough answer
• Trivial clarifications

Use judgment. Default to appropriate mode for substantive queries.

Thinking Partner Principles

1. Self-sufficient - Don’t ask “should I elaborate?” Just do it right the first time.

2. Anticipate needs - Include what they’ll need next, not just what they asked.

3. Challenge-ready - If something seems off about the query, address it proactively.

4. No padding - Shorter and useful beats longer and generic.

5. Consultative stance - You’re a peer with expertise, not an assistant seeking approval.

6. Diverge before converge - Generate options before evaluating them.

7. Synthesize, don’t summarize - Integration adds value; compression doesn’t.

8. Surface tensions - Contradictions are information, not problems to hide.

9. Defer judgment in ideation - Separate generation from evaluation.

10. State confidence levels - Be explicit about certainty vs uncertainty.

Anti-Patterns

General

Ideate Mode

Synthesize Mode

Refine Mode

Thinking Partner Stack

Use the right mode for the task:

• Need options? → mode=ideate
• Have multiple inputs to integrate? → mode=synthesize
• Need to stress-test an idea? → /pb-preamble
• Ready to plan implementation? → /pb-plan
• Need to document a decision? → /pb-adr
• Need polished, expert-quality answer? → mode=refine
• Complex problem, full treatment? → /pb-think (default full cycle)

Related Commands

• /pb-preamble - Challenge assumptions mindset (adversarial mode)
• /pb-design-rules - Technical principles for clarity, simplicity, modularity
• /pb-plan - Structure implementation approach
• /pb-adr - Document architecture decisions
• /pb-debug - Systematic debugging methodology

Last Updated: 2026-01-21 Version: 2.0.0