Everyone builds one AI tool for their job.
Something changes in someone's thinking when they actually build a working AI tool to solve a problem or create an opportunity they've struggled with. Give everyone on your team that experience. Include people on the front line, the receptionist and the maintenance team, as well as colleagues who spend their days at computers. Everyone knows something about their work that a useful tool could help with.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How to run it
Give every participant access to a capable LLM and a way to use it. Invite everyone to build one small tool they would actually use. They can bring a specific problem or simply start talking about their job. A personal project counts too: the point is to discover what it feels like to make something useful with AI.
Give each person the prompt below. It starts with “What's your job?” and guides a conversation towards something worth building. The AI will help choose a manageable idea, write a specification and plan, and then do the building. People contribute their experience, make the choices that matter and try what it makes.
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result. ### Start with the activity and the user's context Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear. Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them. ### Check the capabilities needed for this work Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit. When useful access is missing: - Explain what you cannot reach and how that material would help. - Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot. - If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response. - Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available. ### Ask focused questions and respect the answers Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful. Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements. ### Keep evidence and independent contributions distinct Distinguish evidence, inference, and missing information. Check your work against the source material. Use independent agents when your system actually supports delegation and independent investigation or review would improve the work: - Give each agent a bounded brief and the context appropriate to its role. - Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations. - Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately. ### Produce, check, and revise the result Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them. Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result. Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized. Let's build something together. Your first response should be: “What's your job?” Wait for my answer. You are helping me make a useful, finished AI tool, starting from my own experience. I don't need to know what to build or how to describe software. ### Find something I would actually use Interview me conversationally, asking one question at a time and building on what I tell you. Welcome a general description or a very specific problem. Find out what I do, what takes effort, where I get stuck, what information I repeatedly need and what I wish I could make possible. Include work done away from a desk: reception, maintenance, operations and other frontline work are fully in scope. A personal project is also welcome. If I want to work on something outside my job, follow that interest; learning to build a useful tool is the point. Don't insist on a business justification. Ask about the actual situation and people who would use it before proposing features. Once you know the relevant subject, inspect available access and search the narrow set of records that could clarify it. For a work task these might be role or process documents, relevant support tickets, manuals, recurring requests in email or chat, and meeting notes about the problem. Use them to understand the current method, terminology, recurring questions and what a useful result would look like. For a personal project, use the notes, messages, dates, preferences or other material I choose to provide or make accessible. Don't conduct a broad company investigation for a small personal tool. For tools used by other people, establish who they are and what they need from actual requests, correspondence or supplied examples where available. Distinguish their stated preferences from our guesses. If the relevant sources aren't accessible, ask for one useful example or a rough account instead of assigning me a research project. Use that account honestly; don't invent missing records. ### Choose one small tool with me Suggest a few ideas that fit what you've learned, or develop an idea I already have. Explain each through a concrete interaction: what I give it or click, what it does, and what useful result I get. Help me choose one before building. A maintenance worker might want an answerbot for a particular machine's manual: ask a question in ordinary language and receive an answer with the relevant manual passage. A family might want an interactive vacation website where loved ones post ideas and comments, then the tool researches those suggestions and presents useful findings. A receptionist's tool might answer recurring questions or help with a repeated task they describe. These examples show the range; don't force my idea into one of them. For a manual tool, establish the machine and correct manual and make source passages traceable. For a vacation tool, establish who will contribute, what posting and commenting should do, and what research should happen when a suggestion arrives. Keep people's actual preferences distinct from inferred preferences and current researched facts. Adapt the method with comparable care to the tool we choose. Inspect the tools and environment you can actually use for building, files, data, research, interactions and delivery. Try the relevant capabilities before telling me to set them up. Explain the practical building route in ordinary language. If my idea is too large for this session or these tools, propose smaller slices that each do something useful from beginning to end. Recommend a first slice and get my agreement; don't quietly drop the part that makes the tool useful. ### Write the specification and a manageable plan Create a short specification based on our conversation: who will use the tool, the problem it solves, its inputs, the essential interaction, its output, where I will open it again and what counts as finished. Include a representative example and any unresolved decision that affects the result. Show it to me in plain language and wait for my corrections or confirmation. Then make a build plan in manageable pieces, each producing usable behavior that we can check. Identify which source files or access you already have, what you can obtain yourself, and the specific missing contribution only I can make. Carry out the plan; the specification and plan are preparation for the tool. ### Build, try and improve it Build the agreed tool. Work through the useful slices in order, trying each before adding the next. Ask for my judgment at points that affect usefulness or a consequential choice, while carrying routine implementation yourself. Use the representative example to exercise the complete user journey. Check actual inputs, interactions and outputs, including whether the work persists or can be repeated in the way we agreed. For the manual answerbot, try questions the manual answers, inspect the cited passages, and try one it doesn't answer so we can see how it handles missing information. For the vacation site, try posting an idea and a comment, verify that other intended users can see them through the agreed access route, and run the research on a contributed suggestion. Check its sources and show which findings respond to that suggestion. A screen that only looks interactive does not fulfill those features. Show me the working result and invite me to use it on a real example. Ask what would make it more useful, make the agreed corrections and try the affected behavior again. Use a separate reviewer when available and useful, giving it the actual tool, specification, source material and test task without your account of how well you did. Reconcile its findings and correct substantive problems. If no independent reviewer is available, do a distinct review pass and say so only where relevant to the result. ### Continue across tools or sessions when necessary If building requires another capable tool, prepare a self-contained handoff: agreed purpose and specification, source files or references, decisions, completed work, remaining build steps, representative inputs and completion checks. Guide me through only the access or transfer steps you cannot perform. Have the receiving AI continue through building and testing; help inspect the returned result. Don't leave me with an opaque prompt and call the tool finished. For work too large for one session, divide it into bounded assignments or fresh sessions with the same explicit handoff. Use specialist agents only where they help, with defined inputs, deliverables and checks. Track what each has actually completed and own the integration. If an unresolved access issue blocks the essential behavior, explain the specific remaining step and preserve the work for continuation rather than claiming completion. ### Hand over a finished, useful tool Give me the working link, file or other usable deliverable and the short instructions I need to open and use it again. Demonstrate that the agreed essential task works and invite me to confirm that it helps with the problem we chose. Explain any unfinished part that changes what I can do. Finish only when we have built and checked the agreed useful tool, or state the concrete blocker if we cannot. A list of ideas, a specification, a build plan or an untried prototype is not the promised result. These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
Keep the ambition small enough to finish, and useful enough to matter. A maintenance worker might build an answerbot for a machine's manual. Someone planning a family vacation might make an interactive website where loved ones post thoughts and comments, then have the tool research their suggestions. If an idea is too big, ask the AI to find a smaller piece that still solves a real problem.
Have everyone try their tool on a real example, ask the AI to fix what isn't working, and make sure they know how to open it again. Give people a chance to show one another what they built and what it does. The result should be a finished tool they can use, with the AI carrying the work through the specification and plan to building and checking it.
How it goes
What the AI will do
- Interview each participant about their work or a personal interest and help choose a useful tool.
- Write the specification and plan, build in manageable pieces, and check and improve the working result.
What to have ready
- An invitation to the whole team, including frontline colleagues.
- Each person's experience, interests and a useful example or accessible source material.
Where you come in
- Choose the idea and agree what a useful finished version will do.
- Try the tool, give feedback and show others what you made.
What you'll get
A small, working tool for each participant and firsthand experience turning an idea into something useful with AI.
You're done when
Everyone taking part has built and tried one small, useful tool, knows how to use it again, and has had a chance to show what they made.
View full AI instructions
Everyone builds one AI tool for their job.
Something changes in someone's thinking when they actually build a working AI tool to solve a problem or create an opportunity they've struggled with. Give everyone on your team that experience. Include people on the front line, the receptionist and the maintenance team, as well as colleagues who spend their days at computers. Everyone knows something about their work that a useful tool could help with.
Step 1 — For the user
Give every participant access to a capable LLM and a way to use it. Invite everyone to build one small tool they would actually use. They can bring a specific problem or simply start talking about their job. A personal project counts too: the point is to discover what it feels like to make something useful with AI.
Step 2 — For the user
Give each person the prompt below. It starts with “What's your job?” and guides a conversation towards something worth building. The AI will help choose a manageable idea, write a specification and plan, and then do the building. People contribute their experience, make the choices that matter and try what it makes.
Step 3 — For the user
Keep the ambition small enough to finish, and useful enough to matter. A maintenance worker might build an answerbot for a machine's manual. Someone planning a family vacation might make an interactive website where loved ones post thoughts and comments, then have the tool research their suggestions. If an idea is too big, ask the AI to find a smaller piece that still solves a real problem.
Step 4 — For the user
Have everyone try their tool on a real example, ask the AI to fix what isn't working, and make sure they know how to open it again. Give people a chance to show one another what they built and what it does. The result should be a finished tool they can use, with the AI carrying the work through the specification and plan to building and checking it.
Done when
Everyone taking part has built and tried one small, useful tool, knows how to use it again, and has had a chance to show what they made.
Guidance for the AI
These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.
Start with the activity and the user's context
Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.
Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.
Check the capabilities needed for this work
Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.
When useful access is missing:
- Explain what you cannot reach and how that material would help.
- Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
- If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
- Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.
Ask focused questions and respect the answers
Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.
Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.
Keep evidence and independent contributions distinct
Distinguish evidence, inference, and missing information. Check your work against the source material.
Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:
- Give each agent a bounded brief and the context appropriate to its role.
- Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
- Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.
Produce, check, and revise the result
Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.
Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.
Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.
Your AI prompt
Let's build something together.
Your first response should be: “What's your job?” Wait for my answer. You are helping me make a useful, finished AI tool, starting from my own experience. I don't need to know what to build or how to describe software.
Find something I would actually use
Interview me conversationally, asking one question at a time and building on what I tell you. Welcome a general description or a very specific problem. Find out what I do, what takes effort, where I get stuck, what information I repeatedly need and what I wish I could make possible. Include work done away from a desk: reception, maintenance, operations and other frontline work are fully in scope.
A personal project is also welcome. If I want to work on something outside my job, follow that interest; learning to build a useful tool is the point. Don't insist on a business justification. Ask about the actual situation and people who would use it before proposing features.
Once you know the relevant subject, inspect available access and search the narrow set of records that could clarify it. For a work task these might be role or process documents, relevant support tickets, manuals, recurring requests in email or chat, and meeting notes about the problem. Use them to understand the current method, terminology, recurring questions and what a useful result would look like. For a personal project, use the notes, messages, dates, preferences or other material I choose to provide or make accessible. Don't conduct a broad company investigation for a small personal tool.
For tools used by other people, establish who they are and what they need from actual requests, correspondence or supplied examples where available. Distinguish their stated preferences from our guesses. If the relevant sources aren't accessible, ask for one useful example or a rough account instead of assigning me a research project. Use that account honestly; don't invent missing records.
Choose one small tool with me
Suggest a few ideas that fit what you've learned, or develop an idea I already have. Explain each through a concrete interaction: what I give it or click, what it does, and what useful result I get. Help me choose one before building.
A maintenance worker might want an answerbot for a particular machine's manual: ask a question in ordinary language and receive an answer with the relevant manual passage. A family might want an interactive vacation website where loved ones post ideas and comments, then the tool researches those suggestions and presents useful findings. A receptionist's tool might answer recurring questions or help with a repeated task they describe. These examples show the range; don't force my idea into one of them.
For a manual tool, establish the machine and correct manual and make source passages traceable. For a vacation tool, establish who will contribute, what posting and commenting should do, and what research should happen when a suggestion arrives. Keep people's actual preferences distinct from inferred preferences and current researched facts. Adapt the method with comparable care to the tool we choose.
Inspect the tools and environment you can actually use for building, files, data, research, interactions and delivery. Try the relevant capabilities before telling me to set them up. Explain the practical building route in ordinary language. If my idea is too large for this session or these tools, propose smaller slices that each do something useful from beginning to end. Recommend a first slice and get my agreement; don't quietly drop the part that makes the tool useful.
Write the specification and a manageable plan
Create a short specification based on our conversation: who will use the tool, the problem it solves, its inputs, the essential interaction, its output, where I will open it again and what counts as finished. Include a representative example and any unresolved decision that affects the result. Show it to me in plain language and wait for my corrections or confirmation.
Then make a build plan in manageable pieces, each producing usable behavior that we can check. Identify which source files or access you already have, what you can obtain yourself, and the specific missing contribution only I can make. Carry out the plan; the specification and plan are preparation for the tool.
Build, try and improve it
Build the agreed tool. Work through the useful slices in order, trying each before adding the next. Ask for my judgment at points that affect usefulness or a consequential choice, while carrying routine implementation yourself.
Use the representative example to exercise the complete user journey. Check actual inputs, interactions and outputs, including whether the work persists or can be repeated in the way we agreed. For the manual answerbot, try questions the manual answers, inspect the cited passages, and try one it doesn't answer so we can see how it handles missing information. For the vacation site, try posting an idea and a comment, verify that other intended users can see them through the agreed access route, and run the research on a contributed suggestion. Check its sources and show which findings respond to that suggestion. A screen that only looks interactive does not fulfill those features.
Show me the working result and invite me to use it on a real example. Ask what would make it more useful, make the agreed corrections and try the affected behavior again. Use a separate reviewer when available and useful, giving it the actual tool, specification, source material and test task without your account of how well you did. Reconcile its findings and correct substantive problems. If no independent reviewer is available, do a distinct review pass and say so only where relevant to the result.
Continue across tools or sessions when necessary
If building requires another capable tool, prepare a self-contained handoff: agreed purpose and specification, source files or references, decisions, completed work, remaining build steps, representative inputs and completion checks. Guide me through only the access or transfer steps you cannot perform. Have the receiving AI continue through building and testing; help inspect the returned result. Don't leave me with an opaque prompt and call the tool finished.
For work too large for one session, divide it into bounded assignments or fresh sessions with the same explicit handoff. Use specialist agents only where they help, with defined inputs, deliverables and checks. Track what each has actually completed and own the integration. If an unresolved access issue blocks the essential behavior, explain the specific remaining step and preserve the work for continuation rather than claiming completion.
Hand over a finished, useful tool
Give me the working link, file or other usable deliverable and the short instructions I need to open and use it again. Demonstrate that the agreed essential task works and invite me to confirm that it helps with the problem we chose. Explain any unfinished part that changes what I can do. Finish only when we have built and checked the agreed useful tool, or state the concrete blocker if we cannot. A list of ideas, a specification, a build plan or an untried prototype is not the promised result.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.
These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.