Workflow Recipe Cards for Study, Code, Career, Research and Work

Learning a skill and having a habit are different things. Knowing that you should "ground the model in your sources and verify the output" is easy to agree with and easy to forget on a busy Tuesday. A recipe card puts the habit on a single page, in a form you can copy, run and improve.

This article gives you fourteen. They are starting points, not scripture: adapt them to your tasks, test them where you know the answers, and keep the ones you use.

• A standard card format.
• Fourteen cards across six areas.
• How to adapt, test and retire a card.

CARD: [name]            Risk: [low / medium / high]     Data: [public / personal / work]GOAL:    what it achievesUSE WHEN: the situationINPUTS:  what you must supplySTEPS:   numbered, with who does each (you, AI, code)PROMPT:  the templateCHECK:   what you verify every timeSEE:     where the reasoning is explained

The cards below are written in compact form. Square brackets mark blanks to fill.

Risk: low. Data: personal. Goal: actually understand a difficult idea. Steps: (1) AI asks you four diagnostic questions, you answer. (2) AI explains in three layers: analogy and where it breaks, worked example, precise terms. (3) You attempt a problem with no help. (4) AI gives feedback as hints, using a ladder. (5) You teach the idea back, and AI looks for gaps. (6) Cold test in two days.

I am learning [TOPIC] for [PURPOSE]. I understand [WHAT I KNOW] and I get stuck on[WHERE]. Ask me four short diagnostic questions first and wait for my answers.Then explain in three layers (analogy and where it breaks, a worked example, preciseterms), each under 120 words. Then give me one problem without a solution. Use a hintladder: nudge, key idea, outline, partial solution. Never give the full solution unlessI type "solution".

Check: run any code; check definitions in a textbook or official source; do the cold test. See: articles 10 and 12.

Risk: low. Data: personal. Goal: turn your notes into questions and revision. Steps: (1) You paste your own notes. (2) AI makes cards in a table with a source line from the notes. (3) You review every card. (4) AI quizzes you one question at a time. (5) You log misses. (6) Weekly: AI makes targeted practice from the error log.

From the notes below, make up to 15 flashcards as a table: front, back, source linefrom the notes. One idea per card. Use only facts in the notes. Put unclear points in aseparate list called "unclear in notes". Then quiz me one question at a time, wait for myanswer, mark it, quote the supporting line of my notes, and revisit what I missed.<notes> [PASTE] </notes>

Check: cards with no source line are suspect; check a sample against your textbook. See: article 11.

Risk: low. Data: work (follow policy). Goal: build a correct mental model. Steps: (1) Give the code, the structure and an example input. (2) AI explains in layers and lists what it cannot see. (3) You test its claims by running and tracing. (4) You write your own summary. (5) AI points out what you got wrong.

Explain this code in three layers: what it does (one sentence), how it works step by stepfor the input [EXAMPLE], and the assumptions it makes and how it could fail (empty, large,wrong type). List anything you are unsure of because it depends on code I have not shown.Do not guess about the rest of the project. [CODE] [FILE TREE OR RELEVANT CONTEXT]

Check: run the code on the example and an edge case; confirm any named function or library exists in your version. See: article 18.

Risk: medium. Data: work (redact secrets). Goal: find the real cause. Steps: (1) You reproduce and shrink the bug. (2) You redact secrets and paste the minimal code and error. (3) AI lists ranked causes with a test for each. (4) You run the tests. (5) AI proposes the smallest fix for the confirmed cause. (6) You review the diff and add a regression test. (7) You explain the cause in a sentence.

Bug: expected [X], actual [Y]. Language and version: [..]. Minimal code: [..]. Error: [..].What I have tried: [..]. Do not give a fix yet. List the three most likely causes in order,and one quick test for each.

Check: the fix must change the cause, not hide the symptom (no blanket exception handling, no disabled checks); regression test fails before and passes after. See: article 19.

Risk: medium. Data: work. Goal: add one small feature that you understand. Steps: (1) You write acceptance criteria. (2) AI lists edge cases and questions, without seeing the implementation. (3) You write or approve tests. (4) AI drafts the code in a small diff. (5) You read every line, run tests, run linters and security checks. (6) Commit.

Context: [STACK, FILES]. Task: [ONE SMALL FEATURE]. Constraints: no new dependencies, change only[FILES], follow the existing style. Acceptance criteria: [..]. First list edge cases andquestions. Then give the change as a diff. Afterwards list the security assumptions you made.

Check: break the code on purpose to confirm tests can fail; verify any suggested package exists. See: articles 17, 20 and 21.

Risk: low. Data: work. Goal: catch issues before a human reviewer does. Steps: (1) Paste your diff (redacted if needed). (2) AI reviews against a checklist. (3) You verify each point. (4) You also review it yourself.

Review this diff as a careful senior engineer. Focus on edge cases, error handling, security,removed checks, new dependencies, and anything changed that the description does not mention.For each concern: quote the line, explain the risk, say how confident you are. If a category hasno issues say "none found" and do not invent concerns. [DIFF] [DESCRIPTION]

Check: treat output as leads, not a verdict. A clean report is not a clearance. See: article 20.

Risk: medium (honesty). Data: personal. Goal: a clear, true bullet. Steps: (1) Write a fact sheet, including what you do not know. (2) AI rewrites using only those facts, in three lengths, and asks questions. (3) You verify each claim and number. (4) You pass the interview test.

Rewrite my resume bullet in one line: action verb, what I did, how, result. Use only the factsbelow. Do not add numbers, tools, users or outcomes that are not there; if no number is given,describe the scope in words. Give three versions and list questions that would strengthen it.FACTS: [..]  CURRENT BULLET: [..]

Check: every detail traces to your facts; you could talk about it for two minutes. See: article 23.

Risk: low. Data: public (postings) and personal (your facts). Goal: a ranked list of what to learn or show. Steps: (1) Collect 5 to 10 postings yourself. (2) AI extracts requirements with quotes. (3) You spot-check and count. (4) AI classifies each against your facts as can show, partial or missing. (5) You correct and prioritise.

For each posting (labelled 1 to N), extract requirements as a table: posting, requirement,category, required or preferred, exact quote. Use only the text. Then group similarrequirements and count the postings that mention each. Then, using my fact sheet, classify my status as"can show", "partial" or "missing", citing my fact-sheet line; if not mentioned, "missing".

Check: verify the top five counts by search; correct any generous classification. See: article 24.

Risk: low. Data: personal. Goal: realistic practice with honest feedback. Steps: (1) Set the role and rules. (2) Answer aloud. (3) AI follows up, no hints until you ask. (4) Score against a rubric. (5) Log the top three improvements. (6) Redo the weakest answer.

Run a mock interview for [ROLE] at [COMPANY TYPE]. Ask one question at a time, wait, ask onefollow-up, give no hints until I type "feedback". Be strict. At the end score 1 to 5 on clarity,specificity, correctness, structure and follow-ups, quote one line for each score and give threeimprovements. My real background: [FACTS].

Check: run any code yourself; verify technical corrections in a reliable source; do one human mock. See: article 25.

Risk: medium. Data: public. Goal: a defensible answer to a research question. Steps: (1) You frame the question and scope. (2) AI maps terms and debates, with no citations. (3) You find sources yourself. (4) You read the key parts. (5) You build a matrix: type, date, claim, quote, reliability. (6) You write your conclusion with limits.

I am researching: [QUESTION, SCOPE]. Give a 150-word overview, the main terms and synonyms, the mainpositions and the kinds of source that exist. Mark anything you are not confident about. Do not givecitations. Then suggest 8 search phrases for a library database and an official site search.

Check: every cited source exists, is read, and supports the claim; trace echoes to the original. See: article 27.

Risk: medium to high depending on the claim. Data: public. Goal: decide how far to trust a statement. Steps: (1) AI lists the claims in a text. (2) You choose what to verify by stakes. (3) Find the primary source. (4) Compare an independent source. (5) Check date, context and numbers. (6) Record and label.

List every factual claim in the text below as a numbered list, one per line, using the originalwording. Mark each as fact, number, named source, prediction, opinion or definition. Do not judgewhether they are true. [TEXT]

Check: label each claim confirmed, probable, unverified or contradicted, with the source and date. See: article 26.

Risk: low to medium. Data: work (approved tool). Goal: a clear message that keeps your voice and does not invent anything. Steps: (1) Write facts as bullets. (2) State audience, ask, tone, length. (3) AI drafts. (4) You check facts and commitments. (5) You personalise.

Write a [email/message] to [PERSON, ROLE]. After reading they should [ASK]. My facts, and only these:[BULLETS]. Tone: [..]. Length: about [N] words. Do not add facts, dates, amounts or promises. If youneed something I did not give, ask me first. Match the tone of these samples: [2 SAMPLES].

Check: names, dates, numbers and promises against your notes; do not send sensitive messages drafted this way without care. See: article 13.

Risk: medium. Data: work (consent and policy first). Goal: reliable decisions and action items. Steps: (1) Confirm permission and tool. (2) AI extracts decisions, actions, open questions and "not decided" with quotes. (3) You verify against the transcript. (4) Send to attendees to confirm.

From the transcript, list: decisions (only if agreed, with the quote), action items (task, owner,due date; write "not stated" if missing, with the quote), open questions, and things discussedbut explicitly not decided. Use only the transcript. Do not infer owners or dates.

Check: negations, owners, dates, names; attendee confirmation. See: article 14.

Risk: low. Data: personal. Goal: a realistic plan with the likely failures named. Steps: (1) You state goal, deadline, constraints and known tasks. (2) AI breaks it into tasks of at most two hours, in order, fitted to your hours. (3) AI runs a pre-mortem. (4) You cut to what fits. (5) Weekly: adjust.

Goal: [..]. Deadline: [..]. Constraints: [HOURS PER WEEK, SKILLS, BUDGET]. Known tasks: [..].Break it into tasks of at most 2 hours with dependencies, schedule them week by week within myhours, then imagine it failed and list the 8 most likely reasons with one preventive action each.

Check: compare time estimates with your own history; cut scope before extending the deadline. See: article 16.

Risk: medium to high. Data: depends. Goal: decide whether and how to automate a repeated task. Steps: answer these questions before building anything.

TASK: [..]  FREQUENCY: [..]  CURRENT TIME PER RUN: [..]Is there a precise rule or formula? (yes: use ordinary automation)Which steps need language understanding? [list only those]Input format: [..]  Output format and validation rules: [..]Worst realistic error and its cost: [..]Who approves before anything external happens? [..]What happens on failure or uncertainty? [escalate to ..]How will I test it? [20 real examples with expected results]Stop button and owner: [..]

Check: if you cannot answer these, do not automate yet; start with the manual chatbot version. See: articles 30 to 32.

• Adapt: replace the blanks with your own context, and add the constraints you always need. Keep the "do not add facts" and "not stated" lines. They carry the safety.
• Test: run a card on a task whose answer you already know. If it fails, fix the card, not just the output.
• Date it: note the tool and the date. Re-run after major changes.
• Improve: after each use, write one line: what worked, what you had to correct.
• Retire: if you have not used a card in two months, archive it.

• Copying a card without adapting it to your situation.
• Deleting the checks because they take time.
• Using high-risk cards with unapproved tools.
• Storing real data inside the cards.
• Treating a card as a guarantee. It is a method, and the output still needs your judgment.
• Collecting cards you never run.

• Next: Your 30-Day Plan and Long-Term AI Skill Roadmap turns your system into a four-week routine and a longer path.
• To go deeper into any card, follow its "See" reference to the relevant article.
• To go back to the loop that underlies them all, see Start Here: What You Can Do with AI and the Work Loop.