Build one useful journey before adding more features.
Get the steps & prompt
Name the user, their problem, and the outcome.
Choose one workflow and three acceptance checks.
Build it with sample data, then test it yourself.
Try this · replace the [brackets]
Help me scope an app for [user] who needs [outcome]. My experience is [level]. Ask up to three essential questions. Propose one small end-to-end workflow, three acceptance checks, and what to leave out of version one. Then outline the first implementation step.
Watch out: Requesting login, payments, chat, and a dashboard in the first prompt.
You’re done when: A new user can complete the core task without your explanation.
Describe, build, run, inspect. Repeat in small slices.
Get the steps & prompt
Save a working checkpoint in version control.
Ask for one visible behavior and run it.
Review the changed files before the next feature.
Try this · replace the [brackets]
Implement only [behavior]. First identify the files you expect to change. Keep existing conventions. Afterward explain the diff in plain language, run relevant checks, and give me a manual test. Flag anything you could not verify.
Watch out: Stacking new features on top of a broken version.
You’re done when: You can explain what changed and restore the previous working version.
Choose around your constraints and ability to maintain it.
Get the steps & prompt
List platform, hosting budget, data needs, and skills.
Compare two suitable options.
Test the riskiest integration in a small prototype.
Try this · replace the [brackets]
For [app], compare two stacks against my skills [skills], budget [budget], hosting [constraints], and data needs [needs]. Explain maintenance costs and tradeoffs. Recommend one and a small prototype to test its biggest uncertainty.
Watch out: Choosing a stack because AI describes it as modern.
You’re done when: You can run, deploy, and debug the prototype.
Write the goal, key conventions, and check commands.
Include boundaries and links to relevant docs.
Update the brief when decisions change.
Try this · replace the [brackets]
Inspect this project and draft a concise contributor brief: purpose, structure, setup, test commands, coding conventions, and areas requiring care. Distinguish verified commands from guesses. Use the instruction-file format supported by my coding tool.
Watch out: A huge instruction file full of obsolete or contradictory rules.
You’re done when: A fresh session can locate the feature and run the right checks.
Investigate [task] in this repository. Read its project instructions. Locate the entry points, relevant dependencies, and tests. Summarize the flow with file references and propose the smallest change. Do not edit yet.
Watch out: Loading the whole repository without a concrete question.
You’re done when: The plan names the relevant files and explains why each matters.
Trade guesses for a reproduction and one hypothesis.
Get the steps & prompt
Record expected behavior, actual behavior, and the exact error.
Find a minimal way to reproduce it.
Test one cause, then add a regression check where useful.
Try this · replace the [brackets]
Investigate this failure: [error and reproduction]. Expected: [expected]. Previous attempts: [attempts]. Before editing, explain the leading hypothesis and what evidence would disprove it. Make the smallest supported fix and rerun the reproduction.
Watch out: Changing several unrelated things between attempts.
You’re done when: The original reproduction passes and nearby behavior still works.
Make the pull request easy for another person to assess.
Get the steps & prompt
Review the diff against the intended base branch.
Keep one purpose; remove unrelated edits.
Describe the behavior change, checks, and remaining risks.
Try this · replace the [brackets]
Prepare a draft pull request for this change against [base branch]. Inspect the full diff. Suggest a clear title and a description covering problem, resulting behavior, validation actually performed, and limitations. Identify unrelated changes or secrets before publishing. Do not merge.
Watch out: Listing tests as passed when they were only suggested.
You’re done when: A reviewer can understand the change without reading your chat.
Trace affected callers, permissions, and failure paths.
Prioritize actionable findings with reproduction steps.
Try this · replace the [brackets]
Review this PR against [base] for correctness, regressions, authorization, and missing failure handling. Read surrounding code. For each finding include severity, file and line, a concrete failure scenario, and evidence. Separate confirmed issues from questions. Do not invent findings or edit files.
Watch out: Treating an AI approval as proof that a change is safe.
You’re done when: Each finding points to an observable risk; a human reviews merge readiness.
Resolve the concern, then show how you checked it.
Get the steps & prompt
Turn comments into a short checklist.
Check each suggestion against the actual behavior.
Fix supported issues and draft a concise response.
Try this · replace the [brackets]
Assess these review comments: [comments]. For each, explain the underlying concern and whether the code supports it. Implement justified fixes, run relevant checks, and draft replies with evidence. Flag disagreements for discussion. Do not post replies yet.
Watch out: Applying every suggestion without checking its effects.
You’re done when: Each comment has a fix with evidence or a clear reason for discussion.
Test the real user journey in the target environment.
Get the steps & prompt
Check environment variables, access controls, and migrations.
Deploy to a preview and test success and failure paths.
Prepare rollback and verify the live journey after release.
Try this · replace the [brackets]
Prepare a release checklist for [change] on [platform]. Inspect required configuration, data changes, access controls, and rollback options. Run available checks and mark each item passed, failed, or unverified. Distinguish local results from preview and production results.
Watch out: Calling a successful build a successful launch.
You’re done when: The deployed journey works, and you know how to recover if it fails.
List current files, results, failed attempts, and next step.
Verify the handoff, then use it in the new session.
Try this · replace the [brackets]
Write a concise handoff for a fresh session: goal, constraints, decisions, relevant file paths, completed work, checks and results, failed approaches, unresolved issues, and the next action. Preserve exact errors and commands where necessary. Do not include secrets.
Watch out: A vague summary that loses the details needed to continue.
You’re done when: The next session can continue without repeating the investigation.
Identify which limit you hit before changing your workflow.
Get the steps & prompt
Read whether the message refers to context, output, rate, or account usage.
Use the provider’s stated reset or retry guidance.
Batch related questions and reduce unnecessary retries.
Try this · replace the [brackets]
Help me interpret this exact limit message: [message, with private details removed]. Distinguish conversation context, output length, request rate, and account allowance. Use current provider documentation where available; do not guess reset times. Suggest the smallest next step.
Watch out: Starting a new chat expecting an account allowance to reset.
You’re done when: Your next action addresses the actual limit shown by the service.
Send relevant evidence and ask for a bounded result.
Get the steps & prompt
Remove duplicate logs and unrelated documents.
Request targeted retrieval or specific file sections.
Try a less costly option on a representative task and compare quality.
Try this · replace the [brackets]
Solve [task] using these relevant inputs: [inputs]. Return [specific output] within [length]. If information is missing, identify exactly what you need instead of guessing. Avoid repeating the source material.
Watch out: Cutting the evidence needed for accuracy just to shorten the prompt.
You’re done when: The result meets the same quality bar with less repeated material.
Ask for page or section references with each finding.
Check key passages in the original documents.
Try this · replace the [brackets]
Using only these documents, answer [question]. For each important claim cite the document and page or section. Separate direct evidence from inference. Flag disagreements and missing information. If the files are inaccessible or unreadable, say so.
Watch out: Assuming uploading a file means every page was read correctly.
You’re done when: The cited passages exist and support the answer.
Start with a specific buyer and a problem they already have.
Get the steps & prompt
Collect real customer questions or interview notes.
Group recurring needs and objections.
Choose one audience hypothesis to validate with people.
Try this · replace the [brackets]
Use these anonymized customer notes: [notes]. Identify recurring problems, buying triggers, and objections with supporting excerpts. Propose one audience hypothesis and five non-leading interview questions. Clearly label assumptions; do not invent customer evidence.
Watch out: Treating an AI-generated persona as customer research.
You’re done when: Real conversations confirm or challenge the proposed problem.
Give one audience one clear reason to take one next step.
Get the steps & prompt
State the audience, outcome, and evidence.
Choose one primary call to action.
Explain the offer and answer the main objection.
Try this · replace the [brackets]
Draft landing-page copy for [audience] seeking [outcome]. Offer: [offer]. Verified proof: [proof]. Main objection: [objection]. CTA: [action]. Write a headline, short explanation, three concrete benefits, and an objection answer. Do not invent metrics, testimonials, or guarantees.
Watch out: Publishing persuasive claims you cannot substantiate.
You’re done when: A reader can tell who it is for, what it does, and what to do next.
Show your voice through examples and specific details.
Get the steps & prompt
Supply two examples you like and one you dislike.
Name the audience and intended action.
Read aloud and remove empty claims.
Try this · replace the [brackets]
Rewrite [draft] for [audience] to encourage [action]. Match the voice of [examples]: [three traits]. Keep the verified facts intact, use concrete language, and remove clichés. Give two alternatives and explain the difference briefly.
Watch out: Asking for “more engaging” without showing what that means.
You’re done when: The copy sounds natural and makes the next action clear.
Collect questions from sales, support, or interviews.
Choose a few questions tied to your offer.
Pair each piece with a useful answer and a relevant next step.
Try this · replace the [brackets]
Create a two-week content plan from these customer questions: [questions]. Audience: [audience]. Offer: [offer]. For each piece give the question, useful takeaway, format, evidence needed, and appropriate next step. Fit my production budget of [hours]. Avoid invented search-volume claims.
Measure the business outcome and where people drop off.
Get the steps & prompt
Define the goal: qualified inquiry, activation, or purchase.
Check that tracking records that event correctly.
Test one meaningful change with a predefined evaluation window.
Try this · replace the [brackets]
Help evaluate [campaign]. Goal: [business outcome]. Data: [visits, spend, conversions, time window]. Check data gaps and calculate only supported metrics. Propose one test with a hypothesis, primary metric, guardrail, and decision rule. Flag when the sample is too small for a reliable conclusion.
Watch out: Calling clicks purchases or declaring a winner from a tiny sample.
You’re done when: You can connect results to the intended outcome and explain uncertainty.
Use a relevant reason, a modest ask, and verified facts.
Get the steps & prompt
Confirm the audience is eligible for your chosen channel.
Reference a real, relevant need without fake familiarity.
Draft and review before sending; honor opt-outs.
Try this · replace the [brackets]
Draft a brief outreach message for [eligible audience] about [verified relevant problem]. Offer: [offer]. Ask for [small next step]. Use only supplied facts, no fake familiarity, urgency, or invented results. Include appropriate sender and opt-out details for our process. Draft only; do not send.
Watch out: Treating a list of public email addresses as permission to email.
You’re done when: The message is accurate, relevant, and ready for your channel’s sending requirements.
Specify the audience, constraints, and shape of the output.
Get the steps & prompt
Describe what you will use the answer for.
Provide a good example or a clear quality bar.
Ask for a revision against the unmet requirement.
Try this · replace the [brackets]
I need [output] for [audience] to achieve [goal]. Context: [context]. Constraints: [constraints]. Format: [format]. Here is a good example: [example]. If essential information is missing, ask a focused question; otherwise state assumptions and proceed.
Watch out: Adding adjectives instead of explaining what needs to change.
You’re done when: You can use the answer for the task with minimal rewriting.
Open current primary sources and read the relevant sections.
Separate verified facts, inferences, and unknowns.
Try this · replace the [brackets]
Verify the important claims in [text]. For each, provide an original source link and supporting passage, or mark it unverified. Check dates and scope. If you cannot browse or access a source, say so. Distinguish evidence from inference.
Watch out: Trusting a citation because the link looks plausible.
You’re done when: You opened the key sources and they support the exact claims.
Check your organization’s rules and the tool’s data settings.
Remove credentials and unnecessary personal details.
Replace identities with consistent placeholders.
Try this · replace the [brackets]
Help with [task] using this sanitized example: [example]. People and account details use placeholders. Do not request real credentials or personal identifiers. Tell me which additional non-sensitive details are essential.
Watch out: Pasting access keys or customer records when a synthetic example would work.
You’re done when: The input is appropriate for the approved tool and still sufficient to solve the task.
Match the tool’s access and capabilities to the task.
Get the steps & prompt
Identify whether you need web, files, code execution, or app access.
Check the tool actually has that access.
Try one representative task and inspect the result.
Try this · replace the [brackets]
For [task], identify required capabilities: current web sources, document retrieval, code execution, or app actions. Explain which are available in this session and what is missing. Suggest a workflow and a small test of whether the result is usable.
Watch out: Asking a disconnected chatbot to verify live data or modify your repository.
You’re done when: The tool can access the necessary evidence and produce a verifiable result.
About these playbooks & further reading
These are editorial starting points, not guaranteed outcomes or model rankings. Adapt the prompts to your tool’s access and your project. Review the result before publishing, sending, or merging. The references below explain related practices; they do not validate every prompt.