HCoT: A Three-Step Prompt with a Solution Catalog for Hard Problems

STEP 0 (prep, once): build a catalog of 6–16 typical solution 
         patterns for your field → a list with examples

STEP 1 — Abstract: Describe the problem in general, abstract terms 
         → a generalized statement of the problem

STEP 2 — Match: Map the generalized problem onto the pattern catalog 
         → one or more matching patterns

STEP 3 — Refine: Tailor the chosen pattern to the specific situation 
         → a ready solution

Steps 1–3 can be done in a single prompt. Step 0 is a one-time job; after that the catalog gets reused.

Task: You're the founder of an EdTech startup and you've launched a B2B product for corporate training. At an accelerator demo day, investors listened for 12 minutes and said: "We're interested, but let's talk again in six months." You need to figure out what went wrong and rework the pitch.

Prompt:

I have a catalog of typical reasons a startup fails 
an investor pitch:

PATTERN 1: Market problem — the investor doesn't believe in the size or urgency of the problem.
Example: "That's a niche, not a market. There aren't many companies like that."

PATTERN 2: Weak USP — the product doesn't stand out from competitors.
Example: "How are you different from Coursera or Udemy?"

PATTERN 3: No traction — no hard numbers proving demand.
Example: "Show us at least 3 paying customers."

PATTERN 4: Team in doubt — no obvious expertise in the space.
Example: "Why are you the ones who can pull this off?"

PATTERN 5: Unclear business model — the investor can't see how you make money.
Example: "How do you calculate LTV? Who pays — HR or the C-suite?"

PATTERN 6: Too early — no appetite to invest right now.
Example: "Come back when you hit $10k MRR."

My situation: [describe the pitch: product, target customer, what the investor said]

Do three steps:
1. Abstract — describe my problem in general terms, without product details.
2. Match — find 1–2 patterns from the catalog that best explain 
   the investor's reaction. Explain why.
3. Refine — give specific recommendations: what exactly to change in the pitch, 
   which slides to rework, what data to add.

Result: The model will walk through three visible steps. In Abstract it will generalize the situation to "the investor doesn't see urgency + differentiation is unclear." In Match it will pick patterns 1 and 2 and explain which of the investor's phrases point to them. In Refine it will get concrete: what to add to the market slide, how to rephrase the USP, which case study to cite. The answer will be structured and tied to the real situation rather than generic pitch advice.

The problem: in free-form analysis an LLM works like search without an index — it sifts through a huge space of possible explanations. And generation follows a "long-tail distribution": a few obvious versions get high probability, while the precise ones get lost in the tail. The harder and more open-ended the problem, the worse this brute-forcing works.

The LLM's strength: the model is excellent at matching — finding correspondences between a description and a template, as long as the templates are given explicitly. That's far easier than inventing a solution from scratch.

HCoT mechanics: the method slices the problem into three simple operations. Abstraction strips away noise and specifics — a general statement is easier for the model to work with. Matching replaces open search with a choice from a finite list — instead of "come up with a solution," the task becomes "pick from 10 options." Refinement brings the specifics back — but now knowing the direction instead of wandering blind.

Prompt control levers: - Catalog size (6 vs 16 patterns) → more patterns mean higher accuracy but pricier tokens. For a recurring task, start with 6–8. - Pattern detail → add examples to each pattern and the model matches more precisely. - Number of Match picks → you can ask it to pick 1 pattern (more precise) or 2–3 (broader, if the problem is ambiguous). - Explicit step output → write "show each step separately" to see the logic; write "final answer only" for something shorter.

I have a catalog of typical solutions for problems in {field}:

PATTERN 1: {name} — {short description}. 
Example: "{concrete example}"

PATTERN 2: {name} — {short description}. 
Example: "{concrete example}"

[... repeat for 6–16 patterns ...]

My specific problem: {situation description}

Do three steps:
1. Abstract — describe the problem in general terms, without details. 
   What's going on here at the level of problem type?
2. Match — find the 1–2 patterns from the catalog that fit best. 
   Explain why these ones.
3. Refine — give a concrete solution for my situation 
   based on the chosen patterns.

Placeholders: - {field} — the problem area: "failed pitches", "customer complaints", "team conflicts", "underperforming ad copy" - {pattern name} — a short name: "Weak USP", "No urgency", "Trust problem" - {short description} — 1–2 sentences on what the pattern is - {concrete example} — a real phrase or situation typical of the pattern - {situation description} — your specific case

🚀 Quick start — paste into the chat:

Copy

Here's the HCoT template. Adapt it to my task: {your task}.
Help me build a catalog of 6–10 patterns for this field,
then apply the method to my situation.

[paste the template above]

The LLM will first ask about or suggest patterns for your field — because without a catalog the method doesn't work. That's the key element of HCoT: the solution space has to be defined explicitly before the analysis begins. Then the model will take the Abstract→Match→Refine structure and apply it to your problem.

⚠️ The catalog is everything: if the right pattern isn't on the list, the model will pick the closest wrong one. The method doesn't invent new types of solutions; it only chooses among the given ones.

⚠️ Requires prep: for each new field you first have to build a pattern catalog. It's a one-time job, but it's real work. For a one-off problem it's simpler to ask the LLM to "find the cause" without structure.

⚠️ Weaker on unique problems: if the problem is truly unusual and fits no pattern, the method will give a standard answer where an out-of-the-box one is needed.

⚠️ Pattern quality = answer quality: poorly worded patterns without examples produce fuzzy matching. Examples inside the catalog boost accuracy considerably.

The researchers tested HCoT on three types of tasks: two inductive reasoning tests (guess the rule from examples — tasks with an open solution space) and the Game of 24 (make 24 from four numbers using arithmetic — a task with a clearly defined space).

For the Game of 24 they took all 1362 games from 4nums.com and compared HCoT with four baseline methods: a plain IO prompt, CoT, ToT-Prompt and ToT-BFS (a search tree with breadth 5). All methods were run on GPT-4o.

The result was unexpected. ToT-BFS had the best accuracy — 55.65% — but at the cost of 27 million context tokens for 1362 games. HCoT with 16 patterns delivered 32–45% accuracy on 3–4 million tokens — 6–8 times cheaper. Meanwhile, the "best-of-4" variant (four refinement attempts) reached 55.88%, effectively matching ToT-BFS on quality while staying many times more token-efficient.

Even more interesting: IoT-Prompt, CoT and ToT-Prompt managed 3–9% accuracy — a flop. This shows that without a structured solution space, an LLM literally wanders even on a task with clear rules. The predefined pattern catalog turned out to be the deciding factor — not the model's power or the prompt's complexity.

🔧 Technique: the LLM builds the catalog for you → less prep work

Instead of inventing patterns yourself, ask the model: "Name the 8 most common types of reasons why [problem type]. For each, give a short description and an example of a real phrase or situation." You'll get a draft catalog in 30 seconds, then polish it for your context.

🔧 Technique: iterative HCoT for complex decisions → multiple passes

Apply the method twice. First pass: diagnose the problem (Abstract→Match→Refine). Second pass: build a catalog of fixes for the problem type you found and run the three steps again. The first HCoT finds "what's wrong," the second finds "how exactly to fix it."

Heuristic Classification of Thoughts Prompting (HCoT): Integrating Expert System Heuristics for Structured Reasoning into Large Language Models

Authors: Lei Lin, Jizhao Zhu, Yong Liu, Donghong Sun, Hongbo He, Yihua Du

Institutions: Computer Network Information Center (Chinese Academy of Sciences), Shenyang Aerospace University, ZGC Lab (Beijing), Tsinghua University

Key references in the paper: Clancey (1985) — the original heuristic classification; Yao et al. (2023) — Tree-of-Thoughts; Wei et al. (2022) — Chain-of-Thoughts; Newell (1981) — problem space theory