Prompt Techniques Are a Pattern Language, Not Tricks

The prompt catalog contains 49 items under Prompt Engineering Technique. Compared with the 1,164 creative writing prompts, that number looks small. But this group matters because it asks a different question: not merely what to ask for, but how to shape a request so the answer becomes stable.

The interesting part is how plain many of these techniques are. Answer only in JSON. Show an example first. Write a short tagline. Use a specific format. These are small sentences, but they are also signals that define the shape of work.

Tricks and Patterns Are Different

If prompt techniques are treated as tricks, every new situation sends us looking for a new incantation. If they are treated as patterns, they become reusable.

Seen as a trick	Seen as a pattern
A phrase is assumed to work magically	The function of the phrase is identified
Model-specific wording is memorized	Input, output, and verification are separated
Good results are not explained	Success conditions are saved for the next template
Failure leads to more wording	Failure leads to structural diagnosis

The point of prompt technique is not to find stranger wording. It is to turn a request into a clearer work interface.

The Basic Blocks

Through the PCH lens, prompt techniques tend to break into five blocks.

Block	What it does
Role anchor	Defines the perspective of the answer
Output contract	Fixes the answer shape, such as a table, list, JSON, or code block
Example	Shows what a good answer looks like
Constraint	Sets length, tone, audience, and exclusions
Repair rule	Tells the model what to do when format or information is insufficient

These blocks are not isolated tips. They form a small language. An output contract can make an answer tidy, but without evidence criteria the content can still drift. An example can stabilize tone, but without a repair rule the answer may still violate the required format.

Good Techniques Describe the Work

Prompt engineering is often framed as a way to persuade the model. The techniques that stay useful over time do something less mysterious. They describe the work.

“Give me a good answer” is weaker than “Create three alternatives and compare each one by benefit, risk, and required input.” The second prompt is not better because it is more polite. It is better because the units of work are visible.

A useful technique answers these questions.

1. What role is the model taking?
2. What must the user provide?
3. What format must the model return?
4. What must be included in the answer?
5. What should happen when information is missing?

If a technique cannot answer those questions, it may work once, but it is hard to reuse.

Short Prompts Can Be Upgraded Too

The catalog also contains many short creative requests: taglines, haiku, sonnets, brief descriptions, and similar forms. They look simple, but they are useful upgrade exercises because missing assumptions are easy to see.

For example, a request for a short tagline can be expanded like this.

Layer	Upgrade question
Prompt	What is the tagline for?
Context	Who is the audience, what is the brand tone, and what should be avoided?
Harness	How many options should be generated, and by what criteria should they be selected?

This is not about making every prompt long. It is about surfacing the hidden decisions inside a short request.

What I Want to Save in the Catalog

When I save prompts from now on, I want a few columns next to the original wording.

Column	Why it matters
Pattern name	So a similar task can reuse it later
Output contract	So the result can be checked or transformed
Failure condition	So the model knows when to stop
Example needed	So I know whether few-shot prompting matters
Reuse scope	So personal notes and team workflows stay distinct

With those columns, a prompt stops being a sentence to memorize. It becomes part of a pattern language that can be assembled when needed.

That is why classification matters more than count. Knowing many tips is less useful than knowing what problem each tip solves.