Critical Thinking

Critical Thinking

Systematically question implementation plans, architecture decisions, and technical assumptions to surface risks, gaps, and unverified claims before they become problems.

Overview

This skill proactively engages when reviewing:

• Implementation plans and roadmaps
• Architecture and design decisions
• Technology choices and trade-offs
• Performance and scalability claims
• Security assumptions
• Testing strategies

Core Principle

"What evidence supports this decision? What could make it wrong?"

Every technical decision rests on assumptions. This skill surfaces those assumptions and verifies them against:

1. Web search — Current best practices, known issues, benchmarks
2. Existing documentation — CLAUDE.md, design docs, prior decisions
3. Architectural principles — From microservices-architect and any platform-specific service-planner skill
4. First principles — Does this make logical sense?

The VERIFY Framework

For every significant claim or decision, apply:

Activation Triggers

This skill activates when encountering:

Direct Triggers

• "Let's use X because it's faster"
• "This should scale to Y users"
• "The best practice is to..."
• "Everyone uses X for this"
• "This is the industry standard"
• "We don't need to worry about..."

Contextual Triggers

• Reviewing implementation plans
• Evaluating architecture decisions
• Assessing technology choices
• Analyzing performance claims
• Reviewing security approaches

The escalation gate runs on the most capable model

Everything else is right-sized. This is the one place where model choice is not a cost decision.

The trigger is precise: the moment your instinct is to ask the operator. Stop there and run that instinct through this skill, on the most capable model available to you —

What would the best decision be here, and do I actually need the human to answer this?

Deciding whether to spend the operator's attention is the high-value judgment. Attention is the one non-replenishable input in an autonomous run: tokens can be bought, and a wrong reversible call can be re-made, but an operator interrupted for a question you could have answered yourself does not get that interruption back. So the spend is justified there, and it is justified nowhere else by this rule — outside the trigger, the ordinary tiering stands: the default ladder in Skill(df-dispatch-subagents), or your lane's binding where it names one. Bounded work against a written spec is decided by a test, not by a bigger model.

Verify which model is most capable; never trust a name written in a file

Do not hardcode the answer here, and do not trust one you find hardcoded elsewhere. Model line-ups change on a far shorter timescale than a doctrine file does, so a name committed today is a decaying fact that reads like a constant. Resolve it at the time, from the running environment.

This repo has already been bitten by that exact shape: hooks/context-budget.py records how a bare lookup table of model ids silently mis-sized a session whose id was absent from it, then reported the arithmetically impossible result as a measurement. A model name written into prose is that same table with one entry.

Capability and cost are separate axes. The most capable tier is normally also the most expensive, which is precisely why this is a trigger and not a default.

The pass may resolve ambiguity. It may never dissolve a hard stop.

These are different objects, and collapsing them is the failure this guard exists to catch.

• Ambiguity is missing information you can go and get. A more capable pass over the same evidence may legitimately turn an A into a B — it found the answer instead of asking for it. That is the gate working as intended.
• A hard stop is categorical. It survives any amount of thinking. "I reasoned carefully and concluded I may proceed" is not a resolved ambiguity; it is a stop that was argued away. A more capable model argues more persuasively for a wrong conclusion, not less — so a smooth chain of reasoning toward crossing a stop is evidence against itself, not for it.

Work that is money-critical, on a core path, or being decided at the far end of a long session stays an A however the pass comes out.

When the pass does convert an A into a B, log it where the decision is auditable: what was ambiguous, what resolved it, and what you decided. An unlogged conversion is indistinguishable from never having escalated at all.

A = hard blocker → escalate · B = reversible → decide and log. Defined in Skill(vinculum-loop).

Critical Questions by Domain

Architecture & Design

Performance & Scalability

Security

Dependencies & Integration

Verification Protocol

When a claim requires verification:

1. Identify the Claim

Claim: "Redis can handle 100k ops/second easily"
Type: Performance claim
Source: Team assumption

2. Search for Evidence

WebSearch: "Redis performance benchmarks 2024"
WebSearch: "Redis 100k operations per second production"
WebSearch: "Redis performance issues at scale"

3. Cross-Reference

- Check official Redis documentation
- Look for production case studies
- Find contrary evidence (what problems do people report?)

4. Assess and Document

Finding: Redis can achieve 100k+ ops/sec but:
- Depends on operation type (GET vs complex operations)
- Requires proper configuration
- Network latency often the bottleneck
- Persistence mode affects performance significantly

Recommendation: Verify with load test using actual operation mix

Risk Assessment Matrix

Red Flags to Watch For

Certainty Without Evidence

• "This will definitely work"
• "There's no way this could fail"
• "Trust me, I've done this before"

Appeal to Authority

• "Google does it this way"
• "The documentation says..."
• "Best practice is..."

Premature Optimization

• "We need to optimize for scale from day one"
• "Let's use X because it's faster"
• "We might need this later"

Hidden Complexity

• "It's just a simple..."
• "We just need to..."
• "It should only take..."

Missing Failure Modes

• No discussion of what happens when things fail
• No rollback plan
• No monitoring strategy

Integration with Other Skills

microservices-architect

Cross-reference against:

• Prime Directives (observability, async-by-default, etc.)
• Pattern applicability
• Operational requirements

a platform-specific service-planner skill

Verify alignment with:

• that platform's Prime Directives
• its data-gateway pattern
• Append-only contracts
• Deployment requirements

Output Format

When raising concerns, use this format:

## Concern: [Brief title]

**Claim:** [What's being claimed]
**Risk Level:** High | Medium | Low
**Evidence:** [What supports or contradicts]

### Questions
1. [Specific question]
2. [Specific question]

### Verification Needed
- [ ] [What to verify]
- [ ] [What to verify]

### Recommendation
[Accept / Reject / Investigate further]

Supporting Files

• FRAMEWORKS.md — Mental models for evaluation
• QUESTIONS.md — Domain-specific question templates
• VERIFICATION.md — Fact-checking procedures
• BIASES.md — Cognitive biases to watch for

Operating Stance

┌─────────────────────────────────────────────────────────────┐
│  Be curious, not adversarial                                │
│  Seek evidence, not opinions                                │
│  Question proportionally to risk                            │
│  Verify claims that matter                                  │
│  Document findings for future reference                     │
│  Suggest alternatives, not just problems                    │
└─────────────────────────────────────────────────────────────┘

When NOT to Challenge

• Trivial decisions with low impact
• Well-documented, battle-tested approaches
• Decisions already backed by evidence
• Time-critical situations (flag for later review)
• Personal preferences that don't affect outcomes