7 role prompts from idea to done

I want to complete this: [TASK OR AGREED PLAN].

Pick up from the current state and keep going until [THE FINAL RESULT I CAN SEE, USE, OR CHECK].

Read the relevant files to understand the project. Look up information you need. Use the tools available to you.

Own the work from start to finish: understand the task, implement it, run it, check it, and fix what fails. Don’t stop after every step to ask whether you should continue.

For anything involving a page, use the available browser tools, including the built-in browser, to open it and actually use it. Click the buttons, fill in the forms, and complete the flows a user would follow. Fix any problems you find, then go back and check again.

For larger tasks, you can delegate independent parts to other available agents. You are responsible for bringing the results together and making sure the whole thing works.

Keep moving within the agreed scope. Ask me when you need a decision, additional access, or a change in scope.

At the end, show me the finished result. Tell me how to use it, what you checked, and what remains unfinished.

I want to build [IDEA]. Here’s what I have so far: [NOTES, SCREENSHOTS, REFERENCES, OR PROJECT].

First, help me clarify who will use it, what problem it solves, where the user starts, and what they should get at the end.

Find the things I haven’t considered that could affect the result. Look up anything you can answer from the materials yourself. For decisions I need to make, ask the most important question first. Don’t dump a questionnaire on me.

Once we’ve worked through it, write a task brief I can hand directly to another engineer. They should understand what to do, what is out of scope, what constraints apply, and what “done” looks like without reading our conversation.

Flag anything we haven’t settled. Don’t turn your assumptions into confirmed requirements.

Leave implementation decisions to the engineer. Show me the brief for approval first.

Here’s the problem: [PROBLEM].

Steps I took: [STEPS].
Expected result: [RESULT].
Screenshots or errors: [MATERIALS].

First, follow my steps to reproduce it. Find the cause, then fix it. After the fix, repeat the same steps to confirm the problem is gone and that nearby functionality still works.

Tell me what caused it, what you changed, and how you verified the fix.

If you haven’t found the cause, keep investigating. If you can’t reproduce it from my steps, tell me what else you need. Don’t just hide the error.

[PAGE OR FEATURE] is slow when [USAGE SCENARIO].

Find out where the time is going before changing anything. Don’t mistake simpler code for faster code.

Compare before and after using the same actions and data, and confirm the results are still correct. Tell me what changed and whether the changes introduced any other problems.

Don’t claim an improvement you haven’t measured.

Build [PAGE] using [REFERENCE IMAGE OR DESIGN REQUIREMENTS], keeping it consistent with the rest of the project.

Check more than the normal state. What happens with no data, while loading, when something fails, or when the text is unusually long? Does it still work on a phone?

Open the finished page and check the UI first: do the layout, fonts, colors, and spacing match the reference?

Then check the UX: can users find the buttons, fill in the forms easily, tell whether an action worked, and understand what to do next when something goes wrong?

Fix the problems you actually find and show me screenshots of the result.

Don’t assume the page is finished just because the code runs.

Make [FEATURE] work all the way through.

When the user does [ACTION], they should get [RESULT]. Follow the project’s existing approach and connect the data that needs to be read, saved, or updated.

Actually try it. Does the normal flow succeed? What happens with invalid input, missing permissions, a failure halfway through, or a second click?

Confirm that what the page shows matches the data actually saved, and that existing features still work.

Tell me how to try it and which scenarios you tested.

Consider the developer experience (DX), too: how to call the API, what parameters to send, and how to investigate errors. Give the next person an example they can run directly.

Independently review this change: [CHANGE OR TASK LOCATION].
The original requirement was: [REQUIREMENT].

Don’t rely on the implementer’s summary of what they completed. Inspect the result yourself. Look for missed requirements, user actions that could cause failures, and changes that break previously working features.

Run whatever checks you can. For each issue, explain how it occurs, what impact it has, and where the problem is.

Report the issues before changing anything. If you find nothing worth fixing, say so. Don’t invent findings to fill a list.