plea.dev

Diagnose before you build.

Claude Code plugin. Medical-grade requirements gathering through binary yes/no questions. One question, re-assess, repeat. Output: a concrete PLAN.md.

claude plugins add-marketplace sliday/claude-plugins &&
claude plugins install plea@sliday click to copy
Star

One sentence in. Three rewrites later.

You describe what you want in a sentence. Claude fills the gaps with assumptions. You correct. It over-corrects. Two more rounds and you've spent more time steering than building.

Without plea

"Build me a CLI that syncs files"
Assumes bidirectional sync, config file, watch mode
400 lines you didn't ask for
You correct. It over-corrects.
Another round of corrections...

With plea

"Build me a CLI that syncs files"
12 yes/no questions
PLAN.md unidirectional push, 3 files, ~80 lines
Exactly what you meant

What a session looks like

plea starts broad, then narrows. The question count adapts — it stops when the picture is clear, not when a counter runs out.

What you get

Output: PLAN.md — files to create, changes to make, implementation order. Ready to hand to Claude Code or execute yourself.

How it works

Six phases. The interview loop is the engine.

Why it works

The problem with AI coding assistants isn't intelligence — it's alignment. You say "build me an API." The agent hears a hundred possible APIs and picks one. Three correction cycles later you're still not talking about the same thing.

We looked at fields that have solved this problem already. Doctors don't ask patients to describe their illness in one sentence and then guess the diagnosis. They run a differential diagnosis: a structured sequence of binary questions where each answer eliminates half the remaining possibilities. "Does it hurt here? Yes or no." Not "tell me about your pain."

The key insight: binary questions are cheap for the user but expensive in information. A yes/no answer takes one second to give but can eliminate entire branches of the solution space. And critically — the next question depends on the previous answer. It's a tree, not a list.

We tested this on ourselves first. Azamat pitched the idea: "what if we just bombard the user with yes/no questions before any code is written?" We ran a live session — 20 questions about building this very plugin. Three things became clear:

Binary answers are fast

Developers answered in seconds. No friction. No "let me think about that." Yes or no, move on.

"Or" questions break the flow

"REST or GraphQL?" forces a pause. "Does it need a REST API?" doesn't. If the question feels hard to answer, the question is wrong — decompose it.

Free text leaks through (and that's good)

3 out of 20 times, the developer typed a sentence instead of yes/no. Every time, it was more valuable than a binary answer. The system accepts it and skips questions that the text already answered.

The methodology draws from four proven frameworks. Differential diagnosis provides the core loop: ask, eliminate, re-assess. TRIZ (Altshuller's theory of inventive problem solving, derived from 40,000 patent analyses) contributes contradiction detection — if you say "no database" then "persistent user accounts," those answers conflict and the system flags it before it becomes a bug. Kepner-Tregoe situation appraisal provides the structured decomposition of complex situations into binary assessments. Adaptive clinical interview ensures the protocol is a tree, not a checklist — each answer reshapes the remaining questions.

The result: developers reach a concrete, executable plan in under 3 minutes. The plan is specific enough that Claude Code can execute it without further clarification in most cases. And zero questions are asked that could have been derived from the codebase.

It's a decision tree, not a questionnaire.

Every answer visibly reshapes the interview. Questions are added, removed, or reprioritized in real time.

Binary only

Every question is yes or no. "A or B?" becomes two questions: "Is it A?" then "Is it B?" No ambiguity.

Re-assess after every answer

After each response, update the full picture. Eliminate branches. Unlock new ones. Recalculate what to ask next. Not a script.

Contradiction detection

If you say "no database" then "persistent user accounts" — the plugin catches it and asks you to resolve the conflict.

Differential Diagnosis TRIZ Kepner-Tregoe Adaptive Clinical Interview

Depth modes

Auto-detected from your request. The total is a living number — it changes as branches open and close.

~5
Compact
Small, well-defined changes
~15
Standard
New feature or module
30+
Thorough
Architecture decisions