::synthesis · Tim-Ferriss method

Prompt engineering core (the 80/20)

::minimum effective dose

Strip every 'prompt engineering' course down and what's left is six moves that produce 80% of the gain. (1) Specify the role only when it actually changes behavior — 'you are an expert' is mostly noise on modern models; 'you are a senior staff engineer reviewing for security vulnerabilities' changes output because it specifies WHAT TO LOOK FOR. (2) Give the task structure — input, constraints, output format, examples. Models follow structure more reliably than vibes. (3) Show, don't just tell — one well-chosen example outperforms five paragraphs of instruction. (4) Ask for the work to be done before the answer — 'think step by step,' 'first list the candidates, then rank them, then choose' reliably improves correctness on multi-step tasks. (5) Specify the output format precisely — JSON schema, markdown structure, length cap. Vague format requests get vague format outputs. (6) Iterate against failure cases — your first prompt is a hypothesis; refine it against the cases where it broke, not where it worked. Everything else (chain-of-thought magic phrases, 'take a deep breath,' multi-shot exotic patterns) is incremental at best, superstition at worst on modern models. The fundamentals compound; the tricks don't.

::DiSSS · deconstruction questions

01What is the SHORTEST prompt that produces the output I need? (Start there, add only what's necessary.)
02What does failure look like for this task — and have I built three failure examples I can test new prompts against?
03Am I using the model's strongest capability (reasoning, structured output, tool use) or fighting it with a wrong shape?
04Could I replace 80% of my prompt with one good example?
05Have I separated the system prompt (stable, cached) from the user prompt (varies per call)?

::fear-setting

Cost of not learning this: you'll be three to ten times slower than operators who have the fundamentals down, and you'll never know why. You'll blame the model for outputs that a clearer prompt would have fixed in one revision. You'll think the answer is 'a more advanced model' when it's actually 'a less ambiguous request.' Cost of getting it wrong: silent failure. Bad prompts don't crash — they produce plausible wrong answers that look fine until a customer or auditor finds the error. Operators who skip the fundamentals build entire workflows on prompts that work 70% of the time, then spend six months debugging the 30% in production. The fix at month six is the same fix that would have taken twenty minutes on day one: better structure, better examples, better failure cases.

::80 / 20 cut

SKIP: 'jailbreak' prompts, magic phrases ('take a deep breath,' 'I'll tip $200'), persona stacking, exotic chain-of-thought variants. Most are folklore that worked on one model version and don't transfer. OBSESS OVER: (1) one great example per task, (2) explicit output format spec, (3) a small failure-case test set you run every time you change a prompt. Twenty minutes building a 10-case eval beats a week of prompt-tweaking by feel.

::tribe of mentors · paraphrased stances

Anthropic prompt engineering documentation team

Wrote the most operator-useful, model-grounded prompt engineering guide in the industry

Anthropic's stance: be direct, give context, use examples, structure with XML tags, let the model think. The fundamentals are boring and they work; the tricks are exciting and they regress.

Eugene Yan

Applied ML lead, writes detailed pattern catalogs for production LLM systems

Eugene's stance: prompts are software. They need version control, evals, regression tests, and a changelog. Operators who treat prompts as one-shot text strings ship fragile systems; operators who treat them as code ship robust ones.

Riley Goodside

Staff prompt engineer at Scale AI, one of the first 'prompt engineer' job titles, deep practitioner

Riley's stance: the model is doing a probability calculation on your tokens. Anything that disambiguates the desired completion helps; anything that confuses it hurts. Most 'tricks' are just ways of disambiguating that could be done more clearly with structure.

Sander Schulhoff

Lead author of the Prompt Report (2024), the most comprehensive academic survey of prompting techniques

Sander's stance: of the 200+ documented prompting techniques, fewer than a dozen reliably help. The rest are either marginal or model-version-dependent. Stick to the basics; measure everything.

::real-world test · this week

This week: take a prompt that 'mostly works' for you. Build a 10-case eval — 5 inputs you've seen succeed, 5 inputs you've seen fail. Score each output PASS or FAIL with a clear rubric. Now refactor the prompt using only the six moves above: role-as-task-spec, structure, one example, request-then-answer pattern, format spec, iterate-against-failures. Re-run. If your pass rate didn't go from ~70% to ~90%, your eval rubric is too lenient or you missed one of the moves. The eval is the practice.

::action items · ranked

01Build a 10-case eval for the prompt you use most — written PASS/FAIL criteria, not vibes
02Add ONE high-quality example to that prompt and re-evaluate; remove all other 'magic phrases'
03Specify the exact output format (JSON schema, markdown structure, or word cap) and reject outputs that don't match
04Version-control your prompts as code with a changelog of what changed and which eval cases moved
05Strip your current prompts by 50% — most have accumulated noise; find what's actually load-bearing