Eight modules covering the frameworks behind prompts that stay reliable, five role-based tracks, and a rollout guide for teams. No signup, no paywall, no drip sequence — the whole thing is on this page.
Almost every reliable prompt is one of these patterns, or a combination. Learn the eight and you stop copying prompts and start diagnosing why one failed.
Quick, single-turn requests where output shape matters.
Assign expertise, state the task in one sentence, then specify the exact output structure. Most weak prompts fail on the third element — the model picks a format for you, and it is rarely the one you wanted.
Act as a technical recruiter. Screen this CV against the job description. Return a table: requirement, evidence found, gap.
Communication work where voice and reader matter as much as content.
Separates what you want said from how it should land. Splitting style from tone is the part people skip: style governs sentence construction, tone governs emotional register, and they move independently.
Context: we missed an SLA. Objective: retain the account. Style: plain, concrete. Tone: accountable, not grovelling. Audience: technical buyer. Response: email under 150 words.
Stopping the predictable failure modes before they happen.
State length, what to exclude, and what to do when information is missing. The instruction that saves the most rework is telling the model to ask rather than assume — otherwise it fills gaps silently and confidently.
Under 200 words. No preamble. If the spec is ambiguous, list the ambiguities instead of guessing.
Enforcing a format or judgement call that is hard to describe in words.
Two or three worked examples outperform a paragraph of instruction for anything involving taste. Include one edge case and one near-miss — examples that are all obvious teach the model nothing about the boundary.
Here are three approved subject lines and two rejected ones with the reason. Now write five more.
Long prompts mixing instructions with pasted material.
Wrap reference material in clear delimiters and keep instructions outside them. Without a boundary the model cannot reliably tell your instructions from content it should merely process — which is also how prompt injection succeeds.
<document>…</document> Using only the document above, answer the question below.
Any task where a single prompt produces shallow or inconsistent output.
Split the work into steps with a verifiable output at each boundary, then feed one into the next. This beats a longer prompt because you can inspect and correct the intermediate result instead of debugging a black box.
Step 1: extract every claim. Step 2: rate each claim's evidence. Step 3: rewrite only the claims rated weak.
High-stakes output where a second pass is cheaper than a mistake.
Have the model produce a draft, critique it against explicit criteria, then revise. The criteria must be specific — 'make it better' produces cosmetic edits, while 'find every claim without evidence' produces real ones.
Draft the analysis. Then list every conclusion the data does not support. Then rewrite removing those.
Any prompt that will run more than a handful of times.
Keep a fixed set of ten to twenty real inputs with known-good outputs. Re-run it whenever you edit the prompt or the model updates. Without this you are not engineering prompts, you are adjusting them and hoping.
Run the prompt across the test set. Flag every output where the format broke or a fact changed.
Generic AI training fails because a developer and a content lead need different things. Each track pairs the modules above with the prompts in that part of the library.
Ship faster without merging code nobody understands.
Produce more without the output sounding machine-made.
Spend the saved hours on conversations, not admin.
Automate the recurring work that eats the week.
Make adoption decisions on evidence, not vendor decks.
Adoption fails in a predictable way: a launch announcement, a burst of enthusiasm, then quiet abandonment. This sequence is built to avoid that.
Audit what people already do with AI, including the shadow usage nobody reported. Publish the acceptable-use policy and the data rules before broad rollout, not after the first incident.
Pick a team with a measurable, repetitive workflow. Establish the before metric. Train them properly, then measure output quality and time saved against that baseline.
Turn the pilot's successful prompts into a documented internal library with owners. Undocumented wins do not survive the person who discovered them changing roles.
Roll out by role using the pilot's evidence. Put review cycles on the library, monitor for quality drift after model updates, and retire prompts that stop earning their place.
We send one practical breakdown a week — a framework, a worked example, and the failure mode it prevents. No course upsells.
The modules are free to use however you like. If you would rather we ran the training against your own workflows, that is a separate engagement.