All workflows

24 workflows that chain several AI prompts in order to finish one real task.

24AI Workflows

Writing a weekly report with AI that doesn't come back for revisionA weekly report usually gets sent back because your manager cannot see the result, the risk, or the decision you need from them — not because the prose is weak. This flow pulls the facts out of the week's chats, organizes them for your manager, separates out the ask, then strips template phrasing and checks every number.
Turning a meeting into an action list people actually doThe usual outcome of a meeting is that it felt productive and then evaporated. This flow turns the talk into written decisions people can quote, cuts it to decisions, owners, and dates, converts that into a checklist, then handles the items nobody claimed and the parts other teams owe you.
Turning a pile of research into an article that holds togetherPlenty of material does not make a good article; most long pieces fail on structure, not sentences. This flow compresses the fragments into a defensible outline, has a reader's eye find where the piece gets abandoned, fixes the structure, then unifies the language and adds headings before checking facts.
Editing the AI out of your own writingThe AI voice is not typos; it is sentence shape, rhythm, and the way claims get made. This flow deletes the template phrasing first, smooths what is left, then compares each claim with its evidence, checks the facts, and finally tests the piece on a reader who is ready to leave.
How to get into an unfamiliar field in two hoursThe biggest trap in a new field is diving straight into the details. This flow maps the field first — how many blocks there are and what depends on what — then translates the jargon, cuts a minimum path, uses a plain-language explanation to expose the gaps, and finally hunts for what you have understood wrong.
How to read a paper and judge whether to trust itPapers are hard to read because most people start with the method and reach the conclusion last. This flow asks what the paper actually proved, maps the argument, checks the data behind each claim, inspects how the metrics were defined, and separates correlation from causation.
Preparing for a technical interview so the follow-ups don't break youMemorized answers survive one question. This flow generates the questions from the job description, prepares a system design answer by tearing down a real system, drills five levels into each technical decision, has you explain it while an opponent marks errors, then simulates the actual follow-up rhythm.
Turning your job change into a story that persuadesAn interview story is not a résumé: it is why you chose what you chose, what it cost, and what came of it. This flow lines up the scattered facts, separates fact from inference, attaches evidence to each claim, rewrites for the audience, and stress-tests it with a reader who is already doubting you.
How do I take a feature from idea to launch?Turn a vague requirement into something shippable: model the data, split the work, close test gaps, map the blast radius, then audit config before launch.
Production is down: how do I debug it step by step?Don't debug from the first ERROR. Build a timeline, split evidence from guesses, write a failing test, map the fix's impact, then write a real postmortem.
Taking over an unmaintained legacy project: where do I start?Legacy risk is changing what you don't understand. Read boundaries first, find dangerous parts, close test gaps, then check dependency upgrades.
Designing an API from scratch: what should I decide first?Once an API has callers, changes become coordination. Model the data, stress-test the design, define failure paths, lock the contract, split the build.
How do I make code review useful instead of a style debate?Code review turns into a style debate without a process. Authors self-review, tests supply evidence, reviewers check failure paths and concurrency.
How do I run a database migration without breaking production?Migrations fail on locks, rollbacks, and stale queries. Map impact, try to veto the plan, write migration and rollback together, verify with real queries.
How do I choose a technical approach without guessing?Technical choices lock in early. Compare options on the same dimensions, find what can't be undone, test the cost with a pre-mortem, set exit conditions.
How do I write technical docs people actually finish?Docs fail when they don't answer the reader's question. Build structure, let headings show the point, check claims against evidence, rewrite for the reader.
Prepare a Design Review: From a One-Page Brief to a DecisionTurn a one-page brief and a draft into a review that ends with a decision. State the goal and the boundaries, critique the work yourself first, walk in with the questions most likely to trip you up, and hand the approved outcome to engineering.
Turn One Sentence Into an Image Prompt That WorksStart from a vague idea and fix one variable at a time: subject, composition, light, material. Borrow vocabulary from a reference image, decide the palette once, and write the reusable rules down so a set of images looks like a set.
Write UI Copy: Buttons, Empty States, and Error MessagesList every place the interface speaks, then write by state: buttons name the action, empty states name the next step, errors say whose problem it is and whether retrying helps. Unify the tone, then rewrite once for new and returning users.
Make a Decision Between Two Options You Can Review LaterPut both options in one comparison table, surface the assumptions behind each, compare them structurally, then attack the option you prefer. Finish by writing the exit conditions and what you will check in three months.
Stress-Test a Plan by Assuming It Already FailedWrite down everything vague in the plan, work backward from failure, check each cost estimate, find the cheapest way to disprove the plan, and finish with a risk table that has triggers and exit conditions.
Decide Whether AI Output Is Good Enough to UseSeparate fact from inference and preference first, then check facts against each other and against sources, test whether the evidence carries the claim, red-team the piece, and strip the words that carry no information.
Build Your Own Prompt Template LibraryCollect material from the last two weeks of real work, group it into the few task types that keep repeating, write each as a template with slots, test the slots by changing audience and tone, then strip the filler and keep a version history.
Explain a Technical Problem to Someone Non-TechnicalExplain it once until you get stuck; the stuck point is what you have not thought through. Replace jargon with actions and consequences, anchor it with an analogy that states where it breaks, write a three-sentence version, and report conclusion first.