Prompt Atlas: a guide to choosing a method by task

Start from your task

• Describing the task: goal, context and expected output.
• Research: finding documents, using sources and preserving uncertainty.
• Writing: examples, point of view and revision.
• Code: breaking down the problem, real calculation and tests.
• Agents: calls, tools, permissions and continuation notes.
• Thinking and learning: explaining, recalling and keeping your own judgment.
• Search the cards: method names, their alternative names and all the examples.

Describe the task first

When I say “improve this”, I leave the measure of improvement to the model. A more useful start is to say what should be produced from which input: comparing two texts, shortening an announcement, or finding a specific bug in the code? What to do with missing information is also part of this description.

The task and output contract is the first stop for this. If you can show with an example how you want the result to look, you can add few-shot. Separating the task, quotations and examples with delimiters makes reading easier. You don't have to fill these fields with a long template; a short but complete request also works.

When researching: where does the information come from?

Finding a document, extracting an answer from that document and showing what the answer rests on are three separate steps. RAG describes the setup that retrieves relevant passages from an external collection. Pasting a text you already have into the conversation does not, on its own, build a retrieval layer. If the next search for a question depends on an earlier finding, you can look at the IRCoT or Self-Ask cards.

Having links at the end of an answer is not enough either. The citation contract asks which claim is supported by which passage. If sources conflict or the needed information is missing, uncertainty and abstention comes into play. For me, a good result here is sometimes not a definite answer but being able to see clearly what is not yet known.

When writing: choose where you are stuck

If the brief is unclear, CO-STAR or question refinement can be a helpful start. If you have a draft but struggle to explain why it isn't working, open the Rubber Duck card: you are the one explaining; the model makes the connection you skipped visible through questions.

If you want the model to critique its own draft against criteria and fix it, Self-Refine does a different job. Chain-of-Density exists for adding important details left in the source to a short summary. When you need more ideas, joint ideation can be used; you still need to check separately whether the options are really different from one another.

In code: separate explanation from execution

To break a problem into subtasks you can read Least-to-Most, and to lay out a path first, Plan-and-Solve. The model explaining what the code it wrote does, however, does not show that the code works. In the Self-Debug card you can see where explanation, execution result and revision separate.

Handing a calculation over to a program with PAL or Program of Thoughts requires a real executor. Self-consistency also requires separately sampled answers; writing five solutions in one message is not the same thing. When checking, look for short, auditable traces such as the operation used, the edge input and the expected result, rather than long dumps of inner reasoning.

With agents: the instruction comes with a way of working

Master prompt describes the main working document, and general meta prompting describes the work of preparing such an instruction. RUNE is a specific configuration project with layers and tools. I don't use these names interchangeably; they can exist together in the same project.

If the stages are known from the start, prompt chaining is the more relevant card; if the next step will be chosen based on a real observation, ReAct is. In both, the tool contract and the permission boundary remain important. An instruction read from a source does not grant permission for a new action. For continuing long work, context compaction and external notes meet separate needs.

When learning: ask who is doing the work

The model giving the right answer and you being able to solve it without help are not the same result. In the self-explanation and teach-back cards, the one explaining is the human. In retrieval practice you answer before seeing the answer; spaced repetition requires real time to pass and records to be kept.

Socratic tutoring aims to give the learner questions and hints. Recursive Socratic Questioning, on the other hand, is an algorithm in which the model solves a problem through sub-questions. Their names are close; the work they do is different. To avoid agreeing with the model's suggestion right away when making a decision, you can also look at the human judgment first pattern.

How to use the cards?

Each card has a short definition, where it is useful and three separate scenarios. The Simple example shows the method's basic move. In the Medium example an extra condition or stage comes in. In the Hard example, dependencies, uncertainty or control boundaries become prominent. Moving to the Hard example does not always mean getting a better result.

The example situations, documents and responses are fictional. They are not benchmarks of models that were actually run, nor personal success stories. In a multi-call example, it is written who starts the call, which real result is carried forward and where it stops. Without these parts, copying only the prompt text does not complete the method.

The sources section contains the original title, author, known date, link and the narrow claim the source supports. For some sources only the abstract or the bibliographic record could be read; the card states this limit. Human learning, model accuracy and quality of explanation are different measures. I don't carry a result seen in an older model or in a particular course over to every use.

This is not a list of every technique in the world; it is a selection whose sources and name distinctions have been reconciled for this guide. If the origin of an acronym is unclear, instead of assigning it a new authority, I describe the areas that can be supported. Nor do I present a system that entirely requires model training as if it were a single conversation instruction.

When you open a card, you can also see the method's illustration. The production details under the image can be expanded; you can also copy the image prompt separately. To share a card or its Simple/Medium/Hard section, use its own link. The same cards are also on a separate atlas page.