think-scrutinize

Think-Scrutinize - Devil's Advocate for Ideas

Scrutinizes an idea or plan to identify its faults before implementation. Uses the same adversarial pattern as /think-deliberate, but pointed inward at a single idea instead of outward across competing options: skeptics critique, an advocate defends, skeptics counter-rebut, orchestrator synthesizes.

This skill produces no tangible artifacts. It is a consultant, not an implementer. No code, no tickets, no commits. The output is a structured report of findings that survived adversarial testing.

Roles

Judge (you, running this skill):

• Capture the idea in a written brief
• Choose appropriate critical lenses
• Spawn skeptics and the advocate
• Synthesize the exchange into the final report

Skeptics: Each receives a specific lens (technical, economic, operational, etc.) and critiques the idea in good faith through that lens.

Advocate: Defends the idea against the consolidated critique — concedes genuine faults, refutes weak ones.

Workflow

1. Receive the Idea

The idea may arrive as:

• Conversation context — summarize it back to the user, confirm accuracy
• A document — read the file (design doc, ticket, plan)
• Fresh user input — capture it verbatim

Produce a written brief of the idea as you understand it. Skeptics and the advocate critique and defend this brief. Ambiguity here corrupts everything downstream.

2. Fact-Finding

Probe for the context skeptics will need:

• Goal — what problem does this solve? What's the success criterion?
• Constraints — budget, timeline, technical, organizational, regulatory
• Prior attempts — what's been tried? What's been ruled out?
• Stakeholders — who's affected? Whose buy-in matters?
• Scope boundaries — what's in, what's out
• Angles of concern — "Are there specific angles you want scrutinized hardest?"

3-5 clarifying questions is typical. More suggests the idea isn't ready for scrutiny yet.

3. Choose Critical Lenses

Select lenses that fit the idea's domain. The number is a judgment call — there is no fixed count.

Common lenses:

• Technical — scalability, reliability, complexity
• Economic — cost/benefit, ROI, opportunity cost
• Operational — maintenance, support, on-call burden
• Adversarial-user — misuse, exploitation, circumvention
• Security/trust — attack surface, privacy, data handling
• Regulatory/legal — compliance, licensing, contractual risk
• Social/organizational — adoption, political risk, cultural fit
• Temporal — does this hold up in 6 months? 2 years?

Guidelines:

• Choose lenses where the idea plausibly has weaknesses
• Skip lenses that don't apply (e.g., regulatory for a personal script)
• 2-5 lenses is typical; more only for broad ideas
• Include any angles the user nominated in step 2

4. Spawn Skeptics (Parallel)

Spawn one THK - Skeptic agent per lens, in parallel. Each receives:

• The written idea brief (from step 1)
• Its assigned lens and what the lens means in this context
• Relevant fact-finding context
• The structured output format

Collect all critiques.

5. Consolidate Critiques

Merge findings into a single brief:

• Deduplicate overlapping findings (same fault seen by multiple lenses)
• Preserve lens attribution (which skeptic raised what)
• Keep severity labels honest — don't downgrade to look kind

6. Spawn Advocate

Spawn a THK - Advocate agent with:

• The idea brief
• The consolidated critique
• Mandate: defend the idea in good faith. This is not a competition against other options — there is one idea on the table. Concede genuine faults; refute weak critiques.

The advocate returns a rebuttal per finding.

7. Counter-Rebuttal (Parallel)

Each skeptic sees the advocate's rebuttals to its own findings and responds per finding:

• Concede — rebuttal is sound; the fault was weak or wrong
• Hold — rebuttal missed the point; the fault stands
• Refine — rebuttal was partly right; narrow the fault to what still applies

Skeptics run in parallel.

8. Synthesize and Report

For each finding, verdict is one of:

• Stands — skeptic held; rebuttal didn't resolve it
• Refuted — skeptic conceded, or rebuttal clearly resolved it
• Partial — skeptic refined; narrowed concern remains
• Uncertain — both sides have a point; user judgment needed

Final report format:

## Scrutinization Report

**Idea:** [one-line summary]
**Lenses applied:** [list]

### Findings That Stand
[Fatal flaws and serious concerns that survived rebuttal]

### Load-Bearing Assumptions to Validate
[Assumptions the idea depends on — user should verify]

### Partial / Uncertain
[Findings where rebuttal narrowed but didn't eliminate]

### Findings That Were Refuted
[Brief — for completeness. Shows the exchange was not one-sided.]

### Strengths
[Where the idea held up across lenses]

### Recommendation
One of:
- **Proceed** — no material faults; idea is robust
- **Proceed with adjustments** — address standing findings, then proceed
- **Rethink** — standing findings suggest substantive revision
- **Reject** — fatal flaws are unaddressable within the current framing

9. No Iteration

This skill is one-shot. If the user refines the idea based on the report, they re-invoke /think-scrutinize with the revised version. Each invocation is a clean consultation — not an open-ended dialog.

Constraints

• No artifacts. No code, tickets, commits, or documents.
• Good faith on both sides. No strawmen, no exaggeration.
• Lens focus. Each skeptic stays within its assigned angle.
• Honest "no faults found" is a valid, valuable outcome.

When to Use

Good fit:

• Reviewing a plan or design before committing to implementation
• Pressure-testing a proposal before presenting it to stakeholders
• Surfacing objections that politeness or groupthink would suppress
• Pre-mortem analysis — "what could make this fail?"

Poor fit:

• Choosing between options → use /think-deliberate
• Finding bugs in existing code → use /bug-hunt or /review-security
• Implementing changes → this skill makes nothing; follow up with /implement, /refactor, etc.
• Vague dissatisfaction with a plan that has no concrete form yet

Philosophy

The skill exists to make ideas stronger. A good skeptic finds the faults that matter, not the most faults. A good advocate defends honestly, not desperately. The user gets the truth that emerges from their collision.

Charlie Munger, borrowing from Jacobi: "Invert, always invert." Before committing to an idea, understand how it could fail. /think-scrutinize formalizes that instinct — not as unstructured doubt, but as adversarial stress-testing with honest synthesis.