wiki
promptly
_
Promptly
Browse
Guides
Extension
+ Share a prompt
wiki
/
guide-advanced-prompting
/ edit
Suggest an edit.
Improvements are reviewed before going live, like any wiki.
Title
One-line summary
The prompt
- [Decomposition](#decomposition) - [Chain-of-thought: when it helps](#chain-of-thought-when-it-helps) - [Self-critique passes](#self-critique-passes) - [Prompt chaining across steps](#prompt-chaining-across-steps) - [Evaluation](#evaluation) - [A worked pipeline](#a-worked-pipeline) The techniques in this guide share one idea: for hard tasks, stop asking for the finished product in one shot and start designing the process that produces it. ## Decomposition Large tasks fail in one prompt because attention gets spread across too many simultaneous goals: structure, content, style, and correctness all compete. Decomposition splits the work so each prompt has one job. You can decompose yourself, or have the model propose the split: ``` I need to migrate a small Flask app from SQLite to Postgres. Do not write any code yet. Break this into ordered steps where each step is independently verifiable, and for each step state what "done" looks like. Flag the steps where mistakes would be hard to undo. ``` A good decomposition has three properties: steps are small enough that you can check each one, they are ordered so later steps consume earlier outputs, and risky steps are identified before you start. Reviewing the plan before execution is the cheapest quality control you will ever get — errors caught at the plan stage cost one sentence to fix. ## Chain-of-thought: when it helps Asking the model to work through reasoning before answering helps on problems with dependent steps: math with multiple operations, logic puzzles, tracing code, weighing conflicting evidence, applying rules to a fact pattern. ``` A customer signed up on March 5 with a 14-day trial, converted to the annual plan on March 12, and cancelled on April 20. Our policy: full refund within 30 days of first payment, prorated after. Work through the relevant dates step by step first, then state the refund type and show the dates that determine it. ``` It does not help everywhere. For recall ("what year did X happen"), style tasks, or simple extraction, requesting visible reasoning adds latency and words without improving the answer, and a plausible-looking derivation can lend false confidence to a wrong claim. Also note that many recent models reason internally by default, and their written-out rationale is a report of the answer as much as the path to it. The reliable uses are: problems you can verify by checking the steps, and situations where you need to audit *why* — because a stated derivation gives you something concrete to check and dispute. ## Self-critique passes Generating and critiquing are different tasks, and models perform each better when they are separated. After a draft, run an explicit critique pass with a rubric — a bare "any problems?" invites either false reassurance or nitpicks. ``` Review the draft above against exactly these criteria: 1. Does every claim have support in the source document I provided? List any that don't. 2. Does the argument in section 2 actually follow from section 1? 3. Is anything important in the source omitted? Be specific: quote the sentence at issue for each finding. If a criterion passes, say "pass" and move on. ``` Then apply fixes as a separate instruction, so you can veto bad suggestions first. Two practical refinements: for high-stakes checks, run the critique in a fresh conversation with only the draft and the sources, so the critic is not anchored by the drafting discussion; and expect diminishing returns — one or two critique rounds capture most of the benefit, and further rounds tend to churn style rather than fix substance. ## Prompt chaining across steps A chain is decomposition made operational: each prompt consumes the previous prompt's output, usually in fresh conversations with explicit hand-offs. This keeps each step's context clean and lets you inspect intermediate products. A three-step research-summary chain: ``` Step 1 (extraction): "From the article below, extract every factual claim relevant to remote work and productivity as a numbered list. Quote the supporting sentence for each. Do not interpret or summarize." Step 2 (synthesis), new conversation: "Here is a numbered list of claims extracted from an article. Group them into themes, note where claims conflict, and write a 200-word synthesis citing claims by number." Step 3 (verification), new conversation: "Here is a synthesis and the claim list it was built from. Check that every statement in the synthesis is traceable to a numbered claim. List any that aren't." ``` Design the interfaces the way you would between functions: specify each step's output format precisely, because it is the next step's input. Chains trade convenience for control — worth it when the task exceeds what one context handles well, or when you need auditable intermediate stages. ## Evaluation Once a prompt runs repeatedly — in a product, a script, or your own routine — impressions are not enough. Build a small test set: real inputs, expected outputs or a checklist of required properties, and the hard cases that broke earlier versions. Run any revised prompt against the set before adopting it. For outputs without a single right answer, model-assisted grading against explicit criteria works, with care: ``` You are grading a summary against a source document. Score each criterion 1-5 and justify with a quote: - Faithfulness: no claims absent from the source - Coverage: the source's main points appear - Concision: no filler or repetition Output JSON: {"faithfulness": n, "coverage": n, "concision": n, "worst_problem": string} ``` Spot-check the grader against your own judgment on a sample before trusting it, and keep criteria few and concrete. The discipline to remember: change one thing at a time between runs, keep the versions that scored well, and let the test set — not the most recent impressive output — decide. ## A worked pipeline Putting it together for, say, producing a competitor analysis: decompose (plan the sections and what evidence each needs), chain (one extraction prompt per source, then one synthesis prompt over the extractions), critique (rubric pass checking every claim against the extractions), evaluate (a checklist you apply to the final document). Each stage is unglamorous alone. Combined, they turn a task that fails in one prompt into one that succeeds in six.
Write it so someone can paste it straight into Claude, ChatGPT or Gemini and fill the [BRACKETS].
Category
Video
Images
Slides
Narration
Books
Writing
Coding
Marketing
Productivity
Difficulty
basic
intermediate
advanced
Tags (comma-separated, up to 5)
Your name (optional)
What did you change and why?
Submit edit for review
Crafted with precision by
MnexWeb