Copy a prompt.
Then check the result.

Start with AI

Help me make [one tiny artifact] for [audience]. My three personal ingredients are [details]. Give three concepts, then wait for my choice. After that, produce a standalone creation brief with the subject, tone, constraints and three checks. Keep it achievable with tools I already have.

Summarize this note in 60 words or fewer: [paste the practice note]

Create a scoring rubric for these three tasks: [tasks]. Score factual accuracy, instruction following and human editing effort from 0 to 2 with concrete definitions. Keep speed and cost separate. Give a blank results table and a rule for choosing a tool by task.

Before solving this, help me clarify what I want. Situation: [example]. Who is affected: [people]. Current workaround: [workaround]. Ask three important questions, challenge one assumption, and propose a simpler non-AI option. Then write an outcome, constraints, exclusions and three acceptance checks.

Help me review this failed attempt without generic encouragement. Intended result: [goal]. Observed result: [evidence]. Original instructions: [prompt]. Separate facts from hypotheses, identify one missing fundamental, and propose a small next experiment with a pass/fail check.

Recommend three books about [topic you know well]. For each give the exact title, author and year of publication.

In this empty practice folder, create a single HTML checklist with three fictional study tasks. No accounts, network requests or paid services. Explain the files, show a local preview, and help me test checking and unchecking items. Do not publish it.

Turn this note into a table with action, owner and deadline. Use only facts in the note. Write “unknown” when a deadline or owner is missing. After the table list open questions. Note: Maya drafts the invitation. Lee checks the venue details by Thursday. We have not chosen the event date.

Everyday AI

Plan three study sessions. Treat this context as the only facts about me, and use general knowledge for study ideas. Goal: [goal]. Stable preferences: [preferences]. Recent events: [events]. Reference: [source excerpt]. For each session give an action, a duration, and the supplied fact it relies on (or “general knowledge”). List missing information separately. Do not invent my history.

Translate this everyday message from [language] to [language] for [relationship and situation]: [message]. Keep names, quantities and times unchanged. Give the translation, a literal back-translation, and any ambiguity I should ask a fluent speaker about. Do not add facts.

Compare these goals with these dated notes. For every observation cite a date or exact note. Separate recorded facts from hypotheses. Missing entries are unknown, not failures. Suggest three small experiments; I will choose one. Goals: [goals]. Notes: [notes].

Turn [goal] into a seven-day experiment. Current routine: [facts]. Constraints: [time and resources]. Ask up to three clarifying questions, then propose one behavior, a baseline, a daily record and a stop/continue rule. Do not assume motivation or invent future outcomes.

Edit this paragraph for [specific issue]. Keep my meaning, factual claims and this sentence unchanged: [sentence]. Do not add accomplishments, quotes or facts. First diagnose the issue, then offer a light edit and a short explanation of changes. Draft: [text].

Act as my practice partner for [situation] at beginner level. Use only these verified phrases: [list]. Give one short turn at a time. Let me reply in text if voice is unavailable. Correct one meaningful error, explain it simply, and let me retry. Do not score pronunciation from text alone.

Use only this source to tutor me on [concept]: [excerpt]. Explain it with one example, then quiz me one question at a time. Wait for my answer. Cite the source when correcting me. Finish with a new application problem and a list of mistakes to revisit.

Review these three project summaries as a limited sample, not a personality assessment. Cite evidence for any pattern, give an alternative explanation, and name missing information. Suggest one reversible behavior experiment and what would disprove the hypothesis. Summaries: [summaries].

Using this inventory: [items and quantities]. Suggest two simple meal ideas for [people] within [time] using [equipment]. Avoid [ingredients]. Separate existing items, missing items and assumptions. Do not infer freshness or claim nutrition accuracy. Then produce a deduplicated shopping list.

Create media

Turn these notes into a visual explanation for [audience]. First extract facts and uncertainties. Recommend a timeline, table or flowchart and explain why. Use at most seven main elements. For each label and relationship cite the supporting sentence. Notes: [notes].

Plan a twenty-second fictional video for [audience] with this takeaway: [takeaway]. Give three beats, each with purpose, image, narration and transition. Use only these available assets: [assets]. Keep identities and location consistent. Include a review checklist before generating motion.

Design a three-minute AI demonstration about [concept]. Include a misconception, two comparable inputs, expected observable differences, a pause for prediction, and a practice task. Separate what the demo proves from what remains uncertain.

Create a three-shot production pack for [story]. Canon: [character/location/style]. For each shot give purpose, opening state, one action, ending state, reference file and a standalone prompt. Add a continuity checklist. Do not schedule paid generation until the reference frames are reviewed.

Create one [asset type] for [placement and aspect ratio]. Reference role: [identity/style]. Preserve [invariants]. Scene: [one focal action]. Use [palette/medium]. Keep important subjects inside the safe area. Avoid unwanted lettering and watermarks. The image must remain readable at [display size].

Build apps

In this practice folder, build a simple reading list with add, complete and remove actions and local persistence. First inspect the folder and explain the smallest file structure. Use fictional data, no accounts or paid APIs. Run it, test empty input and reload behavior, and show me the preview and remaining limits.

Investigate this bug. Reproduction: [steps]. Expected: [expected]. Actual: [actual]. Evidence: [logs/files]. Rank likely causes and identify the smallest check for each. Implement the smallest supported fix, rerun the reproduction and test nearby behavior. Explain what remains unverified.

Help design a four-message communication-board prototype. User preferences: [consented observations]. Include touch/keyboard access, one optional alternative input, visible focus, adjustable timing, clear/repeat/pause controls and a test plan. Use fictional messages and avoid assumptions about cognition.

DEFINITION OF DONE (save this in the project instructions file)
1. The main workflow works end to end, and you ran it.
2. Data survives a reload.
3. Errors show a message a person can understand.
4. Secrets stay out of browser code and out of the repository.
5. Each user sees only their own data (if the app has accounts).
6. A new user can open it without help.
7. Data can be exported.
8. The diff touches only files this task needs; ask before adding a dependency.
9. Report the commands you actually ran with their output, and list anything unverified.

TASK
Read the definition of done in [instructions file] first. Implement [specific behavior] in this repository, following existing conventions. Keep the change focused. Explain the diff, add or run a test that demonstrates the behavior, then check the project against every item and report pass, fail or not verified for each.

Help me scope one accessible improvement to this communication prototype. Observed friction: [evidence]. Desired behavior: [outcome]. Include the smallest change, keyboard/touch fallback, visible status and a test with camera denied. Use fictional data and state what individual usability testing is still required.

Build one small playable level with movement, one hazard, an exit, win/loss states and restart. Use placeholder shapes first and keep rules separate from rendering. Show debug collisions and clear controls. Test complete win and loss paths before adding polish. Exclude extra levels and multiplayer.

Design one learning encounter for [topic]. Verified learning items: [items]. Include prompt, answer, explanation, retry hint and progression rule. Support text/tap input if voice is unavailable. Give separate tests for game state and actual understanding.

Review this static-site release plan: [plan]. Identify the source repository, build/output directory, validation checks, encrypted upload method, secret storage, live verification and rollback. Flag any step that could affect unrelated sites. Do not change DNS or publish until the concrete destination and files are clear.

Automate safely

You are planning commands for an imaginary home with two lamps: [desk lamp, bedroom lamp]. You may only propose one action: turn a listed lamp on or off. For each request I send, reply with the lamp and on/off you propose, ask one question if it is unclear, or say it is not allowed. Never say an action happened; you can only propose it.

Here are my field-test notes for [task] in [app or tool] on [device]: [what happened offline, when cut off mid-answer, and when interrupted]. For each problem, write one recovery rule: the message the person should see, the safe next step, and what must be kept so they can resume. Then suggest one realistic condition I did not test and how to test it. Do not assume a reliable network or full attention.

From this fictional note extract task, owner and deadline. Use null for missing facts and list ambiguity separately. Do not infer dates. Note: Maya drafts the invitation. Lee checks the venue details by Thursday. We have not chosen the event date. After answering, show the exact supporting phrase for each value.

Design a draft-only workflow for [task]. When it runs: [schedule]. What it reads: [input]. Decisions: [yes/no rules]. Example inputs: [examples]. Specify the output fields, missing-data rules, three tests, what to do when there is no new input, the review point and the manual fallback. Do not send messages or modify external records.

Work & business

Design a 45-minute beginner workshop for [audience] where everyone produces [artifact]. Use this fictional example: [example]. Include a worked demonstration, paired exercise, review checklist, accessibility options and a five-minute debrief. Keep the lesson to one repeatable skill.

Plan a one-page website for [audience] to [action]. Verified facts: [facts]. Available assets: [assets]. Missing facts: [unknowns]. Produce the content order, plain navigation labels and mobile layout. Explain how each section answers a visitor question. Never invent testimonials or business claims.

Audit this website for the journey [journey]. Evidence: [screenshots and notes]. Return a ranked table of issue, location, user impact, smallest fix and retest. Separate observed problems from assumptions. Prioritize completing the task over visual decoration.

Turn these event notes into a one-page operating brief. Include outcome, confirmed owners, timeline, materials, three likely exceptions and escalation contacts represented as placeholders. Do not assign unconfirmed responsibilities or invent attendance. Notes: [notes].

Using only this verified brief [brief], draft a short email, social post and landing-page introduction for [audience]. All three should lead to [action]. Preserve facts exactly, mark missing information and list every claim needing review. Do not invent testimonials, scarcity or results.

Write a project case study for [audience] using these receipts: [evidence]. Structure it as problem, my role, key decision, result, proof and remaining limits. Distinguish prototype from production. Flag unsupported claims and confidential details instead of filling gaps.

Field notes: Start with the basics

Answer using only the text below. For each answer, quote the exact phrase that supports it. If the text doesn't contain the answer, write “unknown from this text.” Don't turn a sensible guess into a fact. Text: [paste text] Questions: [your questions]

Look at your answer above. List every specific factual claim in it (names, dates, numbers, quotes, sources) as a checklist. For each one, say what kind of trustworthy source I could check it against. Don't defend the claims. Just list them so I can verify them.

Give me three different ways to continue this sentence: [sentence]. For each one, describe a situation or background that would make it the most likely continuation.

Answer my request. Treat the context pack below as the only facts about me and my situation, and the Reference (if there is one) as the source for prices, dates and rules. Use your general knowledge for ideas and how-to.

Date: [today's date]
Request: [what you want decided]
Stable preferences: [things that stay true about you]
Recent events: [what happened lately]
Reference (optional): [paste a short excerpt from a trusted source]

For each part of your answer, name the line of context it relies on, or write "general knowledge". List anything you had to assume about me separately. Do not invent facts about me.

Before you answer [your question], list the five facts about my situation that would most change your answer. Ask me for them and wait before answering.

Here is my context pack, dated [date]:

[paste your pack]

For the request [your request], point out lines that contradict each other, lines that look out of date, and lines that would not change your answer. Then suggest a shorter, updated version. Do not add new facts about me.

Before helping me improve or execute this, ask one or two sharp “why” questions that could expose a weak assumption, hidden constraint, or missed opportunity. Then ask what outcome I want, what success looks like, what “done” means, and what evidence would change my mind. Do not solve the request until I answer. Here is my request: [what you were about to ask for]. Here is what goes wrong today: [friction notes: what, for whom, how often, current workaround].

Here is something that keeps going wrong: [plain description with one real example]. It affects [who], about [how often]. Today we handle it by [current workaround]. Don't suggest tools yet. Restate the real problem in one sentence, challenge one assumption I'm making, and tell me the simplest option that involves building, buying or doing nothing new.

Help me narrow this to one outcome: [your problem statement]. Write the outcome in one sentence, list what's out of scope for now, and write a finish line I can check with a yes or no. If my outcome is still vague, ask me one question instead of guessing.

Field notes: Think like a skilled AI user

I am practicing [narrow skill, e.g. writing product descriptions that answer a buyer's questions]. Design a ten-attempt experiment that changes only one variable at a time. Define the fixed starting point, the variable, the values to try, a checklist of three or four yes/no checks, how to record each attempt, and the conclusion I should be able to draw.

Here is my reference example: [paste or describe it]. Here are my attempts: [paste them]. Compare each attempt with the reference. Do not rank them by vague preference. Explain the specific differences in [qualities that matter, e.g. composition, lighting, clarity, fit with my goal]. Then name one fundamental concept I should study before my next attempt, explained in plain language.

My attempts keep failing this check: [the check]. Teach me the one basic principle behind it in five sentences, with one bad example and one good example. Then give me a single change to try in my next attempt.

Help me build a small test set for comparing AI tools on my own work. I regularly do these tasks: [list 3 to 5 tasks]. For each one, write one realistic example input using invented details (no real names or private data) and a checklist of 4 to 6 yes/no items describing what a good answer must include or avoid. Keep the checklist short enough to score in a minute.

I'm considering using AI for this workflow at work: [workflow]. Identify who uses the result, what decisions depend on it, what a mistake would cost, what information it can use, and where a human must approve. Then propose five short test cases with known answers, two realistic run-throughs that include missing information or a failed step, and a way to run it beside the people doing the job without it taking any action. Connect every measure to a real risk or outcome.

Field notes: Get better results

You are a prompt architect. I want to create [what you're making, e.g. an email inviting neighbors to a block party] for [who it's for]. Before writing it, ask me up to five questions about anything you need to know. Here is my checklist for a good result: [your five checks]. Make sure the prompt covers every item. Then write a standalone prompt I can paste into a fresh chat to produce it. Include audience, goal, tone, length, format, must-include facts and things to avoid. Keep every fact I gave you exactly, and label anything you assumed.

Review the [draft type] below against this checklist: [item 1], [item 2], [item 3], [item 4], [item 5]. For each item, say pass or fail and quote the exact part of the draft that shows it. Then give one overall decision: PASS, REVISE, or REJECT. If REVISE, name the single biggest mismatch. Quote the line of my prompt that caused it, or say which instruction is missing. Give the exact replacement or added line, and say what must stay the same. Don't flatter me; I want the problems. Do not PASS if [a deal-breaker, e.g. the date is missing or wrong].

Prompt I used:
[paste the prompt]

Draft:
[paste draft]

Before we start, here are the limits for this task: one draft and no more than [2] revisions, and a maximum spend of [amount, if the tool charges per use]. Make cheap test versions first ([e.g. an outline before the full lesson plan, or a still image before any video]). Before each attempt, tell me the attempt number and any cost. If we hit a limit, or you're unsure what something will cost, stop and ask me to choose. Never send, publish or pay for a higher-cost version without my yes.

Review the sample of my own records below. I chose what to share, and it is a small slice of my life, not all of it.

Find at most three patterns in what I actually did or decided, especially any gap between what I say matters and what the records show. For each pattern, quote at least two specific entries from the sample as evidence, state the observation first, and label any interpretation as a hypothesis. If the sample can't support a pattern with two examples, say so instead of guessing. Describe behaviors, not personality, and do not diagnose me. End by asking me to mark each pattern fits, doesn't fit, or not sure.

What I say matters most right now: [your goal or priority]

My sample: [paste your sample]

Take this observation: [paste the finding]. Give me three other explanations that could produce the same evidence. Then list anything in the material that points the other way. Finish by rating how confident I should be in the original observation (low, medium or high) and explain why.

Convert the patterns I marked "fits" into a table with: pattern, benefit, hidden cost, trigger, replacement behavior, and one measurable 30-day experiment. Prefer behaviors I can observe over abstract advice. Then suggest a review date and the evidence I should check on that date.

Review my email from the last two weeks. Find repetitive tasks I keep doing that you could automate for me. Just recommend — don’t send or change anything.

Help me create a skill called [skill name] from this process. [Your yes/no decisions]. [What it does when everything checks out, including who must be on CC]. If anything is missing, don’t send — save a draft and flag it for me.

Test my [skill name] skill without sending anything. Here are sample requests: [one that should be approved], [one missing a business reason], [one for a tool not on my list], [one that should trip the guardrail, like no manager on file]. For each, show the draft or action you would take and the rule that decided it.

Every [day] at [time], use my [skill name] skill on [what it should read]. Prepare each reply for my approval instead of sending it, then email me a summary.

Here are five examples of a request I answer the same way every time, with names and private details removed: [paste the requests and my replies]. Write the rules I seem to follow as yes/no decisions, what I do when each answer is no, and one guardrail that must be true before a reply is sent. Then list anything you had to guess and the questions I should answer.

Field notes: Build with AI

Before writing any code, interview me about who this is for, the one thing a user must be able to do, what data must be saved, privacy concerns, what could go wrong, and what proof would show it works. Explain in plain English which secrets must never reach the browser. Then propose no more than three small slices.

Build only this slice: [name]. Requirements: [list]. Acceptance checks: [what I’ll be able to see or do when it works]. Tests: [steps, including refresh, phone, empty state, double-click]. Proof: [screenshots, live URL, saved data]. Don’t break what already works. Stop when the checks are proven, show the proof, and list risks before suggesting the next slice.

Test the live URL like a first-time user on desktop and phone: refresh, sign out and in, no data, submitting twice, and trying to see data that isn’t mine. Don’t mark anything complete without evidence.

Help me figure out why [spreadsheet / prompt / routine / program] isn’t working. Expected: [result]. Actual: [result]. Steps that cause it every time: [steps]. Recent changes: [list]. Evidence: [error text, screenshot description or log lines]. Give me at most three possible causes, ranked by the evidence. For each, name one observation that would confirm it and one that would prove it wrong. Do not fix anything yet.

Suggest the smallest temporary way to see what’s happening inside [the formula / the routine / the scene]: a helper column, a log, a label or a marker. It must not change how the thing works, must be easy to remove, and must help me tell your top two hypotheses apart.

Make the smallest fix for the cause we confirmed. Tell me how to re-run the original steps plus these nearby checks: [list]. List what you changed, what’s still uncertain and how to remove any temporary debug tools.

Field notes: Take on bigger projects

Here is an export of my [LinkedIn posts / newsletter / notes]. Before writing anything, build an evidence map: number every item, group them into teaching themes, list the item numbers under each theme, flag duplicates and gaps, and propose one practical lesson per theme with an outcome a beginner could complete in under 30 minutes. Only use what the items support. Mark anything uncertain instead of guessing.

Using this evidence map, build a static teaching website for [audience]. Store each lesson as a content file with: outcome, time, steps, a copyable prompt, how to check the result and troubleshooting. Write one build script that compiles the content into plain HTML with consistent navigation (Start here, Guides, Field notes, Projects, About), and a validation script that fails on broken links, missing anchors or missing images. Keep it deployable to any basic web host.

Review [your site URL] for [who the reader is]. The purpose of this site is: [your one-sentence purpose]. Judge every page only against that purpose. List the ten problems that most stop that reader from getting what they need quickly, ranked by impact. For each, name the page, what you saw and the smallest fix. Flag duplicate ideas across pages. Skip purely visual suggestions unless they block the purpose.

Review the articles, check for duplicate ideas, and consolidate them so each article teaches a new concept thoroughly and clearly. This is a teaching site to get people to try and adopt AI, so every article must be distinct and useful. Redirect any retired page to the article that now owns its idea.

Set up hosting and automatic deployment for this static site on [host] so I do not have to change settings myself. Rules: create a deploy-only account restricted to one folder; use encrypted transfer with certificate checks; I will type any password into a secure prompt and it must never appear in chat, code or logs; store it only as a CI secret; each push must validate the site, upload only changed files and verify them; never delete files on the server; keep the old site in place for rollback. Finish with a README listing every setting you changed and how to undo it.

Use a local HyperFrames pipeline to make a [length] instructional video that teaches how I built [project] with AI: [the steps and tools]. Use my [characters or artwork] and AI voices for two narrators, disclose that the voices are AI-generated, check every scene with snapshots and show me the preview before rendering.

I need to train [audience] to perform [one observable task] in [tool]. Here is a production workflow I already trust: [stages]. Map those stages into a short training-video pipeline. Preserve what is reusable, replace entertainment requirements with learning requirements, identify the safe demo data I need, and define a human approval point before any final render or publication.

Review this training-video plan as a skeptical first-time learner, product specialist, accessibility reviewer and production editor. Score accuracy, clarity, safety, pacing, visual targeting, captions, audio and learner control from 1 to 10. For anything below 9, give one specific change and the evidence needed to rescore it. Do not approve the build until every category reaches 9.

Watch or inspect this review copy against the locked script and interface reference. At each teaching beat, check that the narration, cursor, highlight, visible label and resulting state all agree. List mismatches with timestamps, severity and the smallest safe correction. Do not treat polish as proof.

I'm practicing designing a simple tool for one invented person: [two sentences about them, no real health details]. Interview me one question at a time about what they most need to do, which movement is reliable for them, what tires or confuses them, and who helps them. Stop after five questions. Then: 1) rank their needs in their order; 2) design one screen with exactly six large buttons, one or two words each, including Stop; 3) recommend the lowest-effort input (touch, one switch, head movement or gesture) and what could go wrong; 4) describe a paper fallback and how to stop the tool; 5) give four checks: accuracy, accidental presses, tiredness and how fast a helper can recover it.

Help me organize questions for a qualified AAC or rehabilitation professional. Do not recommend a device or diagnose ability. Ask about communication priorities, languages, vision, fatigue, reliable movements, positioning, cognition, environment, caregiver support, privacy, fallbacks, and how success will be measured.

Create a short supervised evaluation for this prototype: [describe prototype]. Include target size, contrast, dwell time, false activation, calibration drift, fatigue, message completion time, caregiver recovery, offline fallback, and stop conditions. Protect sensitive data and do not make clinical claims.

Turn these verified setup notes into a one-page caregiver checklist with start, calibrate, communicate, recover, charge, clean, privacy, and support steps. Use plain language and pictures where possible. Notes: [paste notes]

Project lab starter prompts

Longer prompts for the first session of each project lab. Open a lab to read and copy its prompt.

Help me build a tiny offline browser roguelike in [JavaScript or TypeScript] in a new practice folder. First version only: one grid room, one player, one enemy, move, wait and an exit, with placeholder art. No procedural generation, inventory or touch buttons yet. List the setup commands before changing any files. Then work in five checkpoints and, after each, tell me how to check it in the browser and which test covers it:
1. One room, one player, one monster and an exit.
2. The world as a grid before any graphics.
3. Deterministic movement, waiting and enemy turns.
4. Save the game state, reload and get the same state back.
5. A manifest and service worker, added last, so the built game reopens offline at the same address.
My room theme: [one sentence].

Help me build a local-first daily quest planner in [plain TypeScript or the framework you know] in a new practice folder. First version only: create and complete quests, one Today view and a short evening review, with invented quests. Store quests locally only: no accounts, cloud sync or AI API, and no archive or morning question yet. List the setup commands before changing any files. Then work in four checkpoints and, after each, tell me how to check it:
1. TypeScript domain types for a Quest with title, status, effort and due date.
2. A small repository interface backed by IndexedDB, with create and complete, so a completed quest stays completed after a reload.
3. One Today view instead of ten dashboards.
4. An evening review that compares planned with completed quests, using only stored records.
My invented quests: [three short tasks].

Help me build one playable language encounter for [target language] in a new browser practice folder. First version only: one location and a single question, with lesson data kept separate from the scene and a tap or text answer. No recorded audio, speech recognition or 3D yet. List the setup commands before changing any files. Then work in three checkpoints and, after each, tell me how to check it:
1. One scenario: a learner enters a hotel and says hello.
2. The target phrase, translation, hint and accepted variants stored as data I can review without reading rendering code.
3. A tap-to-continue version where a wrong answer shows the hint and allows a retry, and a missing answer is handled.
Use these phrases, checked by a fluent speaker or a trusted source: [three phrases with translations].

Help me build a static 3D character test page with Three.js in a new practice folder. First version only: load one GLB model, with animation selection, a camera reset, a grid and visible error text. Keep game systems out of the viewer, and leave lighting controls and automatic deploys for later. List the setup commands before changing any files. Then work in five checkpoints and, after each, tell me how to check it:
1. A page that loads one character model.
2. A dropdown for every animation clip.
3. Camera orbit, reset and a grid for judging scale.
4. Model name, animation name, scale and loading errors shown on the page, including for a missing model URL.
5. A static build published once, for example to GitHub Pages, so someone else can open the same link.
My model: [GLB file you have permission to use]. The bug I want to reproduce: [one sentence].

Help me build a mobile-friendly page for [fictional event] in a new practice folder. First version only: answer what happens, who the format is for, where to go and how to book, with sample content labeled as fictional. Leave out testimonials, attendance claims, a first-ten-minutes walkthrough and decorative animation. List any setup commands before changing files. If you can’t create files, give me one self-contained index.html instead, and tell me how to save it, open it in my browser and preview it at phone width. Then work in five checkpoints and, after each, tell me how to check it on a phone:
1. The questions a first-timer arriving alone would ask, and the three that matter most before arriving.
2. Those questions turned into visible sections.
3. One sample event format, labeled as fictional, with location, audience and timeline.
4. One useful interactive tool, not a decorative animation.
5. Every strong action pointing at one booking destination: [booking URL or a labeled placeholder].
Use this brief: [paste the practice material or your own fictional event brief].

Help me build an offline-first tracker in [TypeScript or JavaScript] in a new practice folder. First version only: one record type, [journal entries], with stable IDs and local storage, and export before any sync. No module registry, accounts, cloud tables or sync conflict rules yet, and no API secrets in client code. List the setup commands before changing any files. Then work in three checkpoints and, after each, tell me how to check it:
1. A data contract with a stable ID, created and updated timestamps and a deletion marker, shown as a TypeScript type.
2. Saving and querying records with IndexedDB, using the indexes you choose.
3. A JSON export and an import that keep the same IDs, plus a test that exports three entries, clears the store, imports them and compares every field.

Help me build one mobile combat encounter in Phaser 3 in a new practice folder. First version only: one player, one enemy, health, an attack with a cooldown and restart, using placeholder shapes, with keyboard and touch routed to the same actions. No title scene or publishing yet. Follow the current Phaser setup instructions and list the setup commands before changing any files. Then work in five checkpoints and, after each, tell me how to check it:
1. One combat scene with movement, before any enemy.
2. Temporary hitboxes so attacks are visible.
3. One enemy that chases, attacks on a cooldown and can be knocked back.
4. Health, game over and a restart that clears player and enemy state.
5. Touch controls that call the same actions as the keyboard.
Starting tuning values: [speed, range, cooldown, damage]. My placeholder theme: [one sentence].

Help me build a no-build Markdown blog in plain JavaScript in a new practice folder. First version only: two posts with title, slug, summary and category frontmatter, a posts/index.json list, safe rendering and a not-found view. No category filter or extra frontmatter fields yet. List the setup commands before changing any files. Then work in six checkpoints and, after each, tell me how to check it:
1. index.html, styles.css and a posts folder.
2. Two Markdown posts with that frontmatter.
3. Both paths listed in posts/index.json.
4. Rendering with [a maintained Markdown parser you name and explain], raw HTML off and javascript: links rejected.
5. A not-found message for unknown slugs, linking back to the list.
6. A GitHub Actions Pages workflow that publishes the folder.
Add a test post with a <script> tag and a javascript: link to confirm neither runs. My blog topic: [one sentence].

Help me build a one-page website for [fictional service business] in a new practice folder. First version only: what is included, what is excluded, the service area and one next step, using only my brief or clearly labeled samples. No testimonials, invented credentials or quote form yet. List any setup commands before changing files. If you can’t create files, give me one self-contained index.html instead, and tell me how to save it, open it in my browser and preview it at phone width. Then work in five checkpoints and, after each, tell me how to check it on a phone:
1. Every service, with what is included and what is not.
2. Starting prices with honest qualifiers.
3. The process in three plain steps, with any placeholder photo labeled.
4. Phone, email, hours and service area, labeled as sample; no licenses unless the brief verifies them.
5. Every claim traced to the brief, and anything unverified removed.
Write it from these notes: [paste the practice material or your own fictional technician notes].

Help me build a small research assistant in Python in a new practice folder, using five saved fictional rental listings. First version only: a common schema with a stable source ID and explicit unknown fields, scoring and filters, and SQLite with deduplication. No scraping, site adapters, desktop table or outreach drafts. List the setup commands before changing any files. Then work in four checkpoints and, after each, tell me how to check it:
1. A listing schema with source ID, canonical URL, price, size, location and conflict flags.
2. Loading the saved listings, with missing values kept as unknown.
3. An explainable score and filters for rentals in [your city], where every score comes with a human-readable reason.
4. SQLite persistence that flags duplicates without losing source links and keeps conflicting prices visible.
My budget and must-haves: [budget, size, transit].

Help me plan [my original game concept] as small playable milestones. First version only: separate the long-term vision from milestone one, a single playable interaction with a visible action and outcome. This is a planning exercise: no code, and later RPG systems stay out of milestone one. If a step needs a tool or file, list the setup first. Then work in four checkpoints and, after each, tell me how to check it:
1. Three game pillars and a one-sentence core loop.
2. Milestone one as one satisfying action, not the complete game, with acceptance criteria and a five-minute demo checklist.
3. Which rules are testable and which depend on scene feel, with the tunable values in one table.
4. A decision record for each boundary a future contributor might undo.
Leave coding the tunable values and a system index for later milestones. My engine, if any: [Godot or another engine].

Help me set up a file-based shot register for [my short video idea] as [a spreadsheet or a JSON file]. First version only: three fictional shots with shot ID, purpose, prompt version, reference files, output file and review status, generated by hand. No provider integrations or automatic retries. If this needs any setup, list it before creating files. Then work in six checkpoints and, after each, tell me how to check it:
1. A short written canon and three shot intents.
2. One register row per shot.
3. A file name for every output that includes its shot and version.
4. Four fixed statuses: draft, in review, approved, rejected.
5. Only approved references carried into the next shot.
6. A view grouped by status so a collaborator can find the next action.

Help me build a small searchable prompt library for [one job outcome my team repeats]. First version only: three reviewed prompts stored as records, each with a category, tags, a worked example and a review checklist, plus search and one-click copy. Leave weak-versus-improved examples and every other feature for later. A spreadsheet is fine; if this needs any setup, list it before creating files. Then work in five checkpoints and, after each, tell me how to check it:
1. The job outcome in one sentence.
2. Three prompts written as records: title, job outcome, prompt text with fill-ins, example input and reviewed output.
3. A review checklist on every record. Include a caution for any rules that apply in [your industry], for example Fair Housing rules in property marketing.
4. Records stored as structured data with categories and tags.
5. Search and one-click copy.

Help me build Pong in LÖVE and Lua in a new practice folder, without giving me the whole solution at once. First version only: paddles, a ball, movement, collision, scoring and a serve state, until one match works. No AI opponent, menus, sound, power-ups or particles yet. List the setup commands before changing any files. Then work in five checkpoints; at each, explain the math, give a small code target and a manual test before continuing:
1. Two paddles and a ball.
2. Positions updated using delta time.
3. Wall and paddle collisions.
4. Scoring and a serve state, with each point counted exactly once.
5. A restart that resets score and ball state.
Paddle keys: [keys for each player]. Winning score: [a number].

Help me build one secure full-stack interaction with [React and Express, or your stack] and TypeScript in a new practice folder. First version only: create-habit and list-my-habits, a local API, two fictional test accounts and a server-side ownership check on every request. No deployment or infrastructure automation yet. List the setup commands before changing any files. Then work in five checkpoints and, after each, tell me how to check it:
1. One vertical slice: create and list habits.
2. Request and response schemas, defined before wiring the interface.
3. Sign-in for the two test accounts, with tokens verified on the server.
4. A user ID stored with every record and checked on every request.
5. Tests proving user B cannot list, fetch or change user A’s habits by direct API calls, and that unauthenticated calls fail.
Follow current guidance for [your identity provider].

Help me model private information in a two-player card game, in a new practice folder or on paper. Stay offline for the first version: one pass-and-play round for two fictional players, plus a table of who may see each fact. No rooms, join codes, seat tokens, server-side hands or realtime updates yet. If code is involved, list the setup commands before changing files. Then work in three checkpoints and, after each, tell me how to check it:
1. An offline pass-and-play round.
2. Public and private state defined as separate schemas.
3. A table of every fact and who may see it: player A, player B, everyone or server only.
Then show the exact data each player would receive and confirm neither contains the other hand. My game in one sentence: [rules]. My tool: [a language you know, or paper].

Help me prove a physical phone can reach my API, in a new practice folder, with FastAPI, Docker and Expo. Keep the first version to one health endpoint and one phone screen with a Test connection button that shows the response or a readable error. No authentication, data storage or AI yet, and no secrets in the client. List the setup commands before changing any files. Then work in five checkpoints and, after each, tell me how to check it:
1. A FastAPI health endpoint.
2. The API running in Docker.
3. An Expo screen with a Test connection button.
4. A test on the physical phone over [the same network or a temporary tunnel], never localhost.
5. Typed API responses and a visible error when the API is stopped.
My computer’s development address: [IP address or tunnel URL].