The Dr. Gregory House Prompt: A Persona Is a Diagnostic Procedure, Not a Voice

A note on turning a Dr. Gregory House-style persona and a prompt-engineer persona into reusable LLM Wiki nodes: not by copying their voice, but by preserving their diagnostic procedures.

The easiest mistake in persona prompting is to copy the surface voice first. Make the assistant sarcastic. Give it a sharp tone. Dress it in the language of a profession. That surface can sometimes help, but it does not last. After a few turns, the character collapses and only the exaggerated style remains.

I found two local source prompts in MyZettelkasten that show a better direction:

  • 닥터 그레고리 하우스.txt
  • 프롬프트 엔지니어 페르소나.txt

At first, they look unrelated. One is a diagnostic persona based on Dr. Gregory House from House M.D. The other is a “world’s best prompt engineer” persona. But structurally, they solve the same problem. They are not mainly about tone. They define how a role should reason, what evidence it should demand, how it should update its answer, and where its authority must stop.

The Important Part of a House Prompt Is Not Sarcasm

When people think of House, they usually remember the cynicism, bluntness, dark humor, and lines like “Everybody lies.” If that is all we import into an LLM persona, the result is shallow. It becomes a slightly rude chatbot.

The deeper structure of the source prompt is different.

Element House-style meaning Prompt-design meaning
Role Head of diagnostic medicine What kind of expert is solving the problem?
Core principle Diagnosis before treatment Define the problem before answering
Thinking pattern Hypothesis storming, evidence, elimination Generate several hypotheses and narrow them with counterevidence
Team workflow Find errors on the diagnostic board Compare candidates before producing a final answer
Signature premise Everybody lies The input itself may be incomplete or wrong
Safety boundary Informational only; consult a physician Specify the persona’s authority and forbidden zones

So the core of the House prompt is not “an unpleasant genius doctor.” It is a differential-diagnosis procedure: spread possible causes, rule out dangerous possibilities, and update the hypothesis whenever new evidence appears.

That structure is not limited to medicine. It can help with app debugging, argument review, student error analysis, or business-idea validation. But it should not be framed as medical authority. Real health, medication, diagnosis, and treatment issues must remain informational and should point people toward qualified professionals.

The Prompt-Engineer Persona Handles the Same Problem

The prompt-engineer persona is more direct. It describes how a highly capable prompt engineer should approach a problem.

Its main loop is:

  1. Understand the user’s need deeply.
  2. Clarify ambiguity.
  3. Generate multiple approaches.
  4. Test and refine them.
  5. Document the process.
  6. Build a reusable prompt library.
  7. Check safety and social impact.

Here again, the persona is not a speaking style. The sentence “I am the world’s best prompt engineer” does almost nothing by itself. What matters is the repeated loop assigned to that persona.

1
2
3
4
5
6
7
understand the need
-> decompose the problem
-> generate approaches
-> test
-> refine
-> document
-> turn into a reusable library

Without that loop, a persona is costume. With that loop, a persona becomes a working harness.

A Useful Persona Has Three Layers

Putting the two source prompts together, a usable persona prompt needs three layers.

1. Surface Persona

This layer covers tone, vocabulary, attitude, humor, and sentence rhythm. A House-style persona may be brief, direct, and slightly skeptical. A prompt-engineer persona may be analytical and structured.

But this is the thinnest layer. If this is the only thing designed, the persona will break quickly.

2. Thinking Persona

This layer defines how the role reasons: what it suspects first, what it checks first, and what evidence matters most. A House-style thinker does not stop at the most obvious answer. It also looks for dangerous, unlikely, and easily missed causes. A prompt-engineer thinker does not simply execute the user’s request; it first separates objective, constraints, output format, and failure modes.

This is the layer that actually improves performance.

3. Operating Persona

This layer defines where the persona must stop, what format it must use, and how its output will be checked. A House-style persona needs medical safety boundaries. A prompt-engineer persona needs boundaries around security, copyright, unsupported claims, and over-automation.

Without this layer, a persona can become risky. A confident voice can start to look like authority.

A House-Style Diagnostic Harness

For blog and work use, I would convert the source prompt into the following general-purpose diagnostic harness. This is not a medical-diagnosis prompt. It is a general problem-analysis structure.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[Role]
You are a problem analyst borrowing House-style differential-diagnosis thinking.
Do not imitate the character. Perform the hypothesis-evidence-elimination-update procedure.

[Input]
The user's problem, symptom, log, draft, app error, student mistake, or work situation.

[Process]
1. Restate the problem in one sentence.
2. Generate at least five possible causes.
3. Separate supporting evidence and counterevidence for each cause.
4. Rank by risk and likelihood separately.
5. Ask for the most important missing evidence.
6. When new evidence appears, discard or update hypotheses.

[Output]
- Problem restatement
- Hypothesis list
- Priority table
- Missing evidence
- Safe next action

[Limits]
Do not replace medical, legal, financial, or mental-health professionals.
Do not present uncertainty as certainty.
Do not instruct the user to perform risky experiments.

The benefit is portability. “The app feels broken” becomes a symptom. “This essay is boring” becomes a symptom. The harness expands possible causes, checks evidence, and rules out weak explanations.

A Persona-Prompt Generation Harness

The prompt-engineer persona can also become a metaprompt for creating personas.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[Goal]
Design an LLM persona that can perform the user's repeated task reliably.

[Decomposition]
1. What repeated problem does this persona solve?
2. What expertise does it need?
3. What tone and attitude fit the task?
4. What input should it receive?
5. What output format should it produce?
6. What failures must it avoid?
7. What verification criteria judge the result?

[Output]
- Persona name
- Role definition
- Reasoning procedure
- Language style
- Input contract
- Output contract
- Forbidden behavior
- Verification rubric
- Example dialogue

With this structure, the persona no longer stays at the level of “speak like a friendly teacher.” It includes the repeated task, failure modes, and quality checks.

Connecting These Personas as LLM Wiki Nodes

This post continues the work from Restoring Claude Archives as an LLM Wiki. The next step is to turn local prompt traces into public, reusable nodes.

This node connects like this:

LLM Wiki node Role
Dr. Gregory House Prompt A diagnostic persona that analyzes problems through hypothesis, evidence, and elimination
Prompt Engineer Persona A designer persona that turns repeated work into prompt libraries and harnesses
Persona Generation Metaprompt A higher-level template for designing domain-specific personas
PCHL Engineering A way to operate personas through prompt, context, harness, and loop

The important thing here is not the character name. It is the role hierarchy.

1
2
3
4
5
character
-> thinking style
-> work procedure
-> output contract
-> verification loop

The character is only the entrance. What should remain in the blog is not the character’s voice, but the problem-solving procedure represented by that character.

Three Practical Uses

1. App Debugging

A House-style diagnostic harness can be used for app bugs. If a button does not respond, do not immediately blame CSS. Consider event handlers, routing, overlays, z-index, async state, build cache, and deployment path. Then rule them out one by one.

2. Writing Feedback

When a piece of writing feels flat, the cause is rarely just “bad sentences.” The claim may be weak. There may be no scene. The rhythm may be repetitive. The audience may be unclear. The conclusion may be generic. Diagnostic thinking turns vague feedback into a table of causes.

3. Student Error Analysis

When a student gets a question wrong, “not enough study” is too blunt. The cause might be vocabulary, passage structure, answer-choice traps, missing background knowledge, time pressure, or grammar signals. A persona here is not a teacher’s emotional style. It is a procedure for decomposing error.

Conclusion

The core of persona prompting is not “speak like this person.” It is closer to “repeat the way this person handles problems.”

The Dr. House prompt is entertaining because of the blunt voice. But its durable value is differential diagnosis, hypothesis storming, evidence-based elimination, and risk-aware prioritization. The prompt-engineer persona works the same way. The impressive title matters less than the loop of need analysis, experimentation, documentation, and library building.

So when designing a persona, the better question is:

What judgment procedure does this persona repeat?

Once that question is present, the persona stops being decoration and becomes a harness.

Comments

댓글

GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.