Paste an error and say, “Fix it.”
You do not need to understand an error message to begin fixing it. Give the AI the error and the thing you were trying to do, then let it inspect the actual setup, make the repair and check whether your original task now works.
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 it goes
What the AI will do
- Inspect the error and affected app, code or configuration, using logs, recent changes and relevant official documentation as needed.
- Make the smallest repair supported by the evidence; reproduce the error when that would help, without making reproduction a ritual for a simple fix.
- Retry the original task, inspect the result and continue until the fix is verified or a concrete blocker remains.
What to have ready
- The error text, a screenshot or a rough account of what happened, and what you were trying to accomplish.
- Access to the affected project or application when available; the AI investigates its actual capabilities first.
Where you come in
- Answer essential context questions or perform a specific access step the AI cannot do.
- Try the original action when only your account or device can complete the final check.
What you'll get
A repaired and verified original task, or the completed diagnosis and a precise handoff identifying the remaining blocked action.
You're done when
The original task succeeds and its result has been inspected. If the final action cannot be performed, the diagnosis and any repair are preserved with the exact remaining check or blocker, and completion is not claimed.
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. Help me fix this error and complete the task it interrupted. Investigate the actual affected artifact or configuration before prescribing setup changes. Keep the explanation in ordinary language and carry the repair through verification. ### Understand the failed action Read the exact error or inspect the supplied screenshot. Establish what I was trying to do, where it failed and what a successful result should look like. Use available context before asking one focused question about an essential gap. If I have supplied only a paraphrase, seek the actual message when its wording would change the diagnosis. Inspect access to the affected app, project, command, configuration or service. Read relevant logs and the smallest source or settings area that could explain the failure. Check versions, environment and recent changes where they matter. Search existing issue reports, support discussions, project messages and recent deployment or configuration records for this error and its timing; a broad search of unrelated company correspondence adds no value. Do not tell me to enable a control you have not inspected. Try available tools and supported access before asking me to export logs or gather a packet. If you cannot reach the affected environment, investigate the permitted connection or sharing route and ask for the smallest specific input or action needed. Keep credentials out of requested screenshots and diagnostic output. ### Decide how much investigation is needed A clear typo, missing file reference or plainly incorrect setting may support a small direct repair. Reproducing the failure before fixing it is optional, especially when the cause is evident and the change is easy to verify. Do not repeat a consequential failed operation merely to reproduce it. When the cause is uncertain, form a specific hypothesis and choose the least disruptive check that can distinguish it from alternatives. Follow the evidence through the relevant inputs, configuration and failure point. Reproduce in a safe local or test setting when useful. Keep observed facts separate from plausible explanations and change one meaningful factor at a time where that helps identify the cause. Consult current official documentation or release notes for the actual product and version when a setting, API, error meaning or supported repair is uncertain. Open the source and compare it with the observed configuration; do not apply a remembered command from a different version. Use existing project instructions and prior issue evidence where relevant. Stop research when it answers the repair question. ### Make the supported repair Explain the cause in one or two sentences when the evidence supports it, then make the smallest change that addresses that cause while preserving the intended behavior. Inspect the existing artifact before editing and keep unrelated user changes intact. Preserve a recoverable copy or focused change record where needed. Carry out ordinary reversible repairs within the authorized environment. If the repair would require a consequential change outside the request—such as deleting data, changing production access or purchasing a service—prepare the exact proposed change and ask for the necessary decision before applying it. Continue independent diagnosis or local preparation while waiting. If several repairs have materially different effects, show the practical difference and recommend the one supported by the evidence. Do not make me choose among unexplained technical possibilities. Ask only when the choice affects the intended outcome or a tradeoff only I can settle. For a genuinely complex failure with separable causes, use bounded agents for independent log, configuration or dependency investigations where useful. Give them the same failed action, relevant source references, a specific question and an evidence-based completion criterion. Collect findings before integrating changes. Keep edits coordinated; for a small error, one focused investigation is sufficient. ### Verify the original task Retry the original action or the closest faithful permitted check after the repair. Inspect the actual output or state change, not merely the disappearance of one error message. A command that now exits successfully may still produce the wrong file or fail to save the intended record. Check the result against what I was trying to accomplish. Run focused existing tests when they meaningfully cover changed behavior. For a simple low-impact repair, a direct successful task check may be enough; do not build a test suite that merely mirrors the edit. Check adjacent behavior when the repair could affect it, and broaden testing only for a new failure or unresolved concern. If the original action still fails, use the new evidence to revise the diagnosis and continue. Do not stack speculative changes. If the final check requires my private device, login or physical action, give me one precise test and wait for its actual result. Until it returns, describe the repair as applied but unverified. ### Deliver the working result or exact blocker Lead with whether the original task now works. Briefly explain what changed and what actual check supports that conclusion. Provide the usable output when the task produced one. If essential access, a user decision or an external service prevents completion, identify the concrete blocker and the work already completed. Prepare a self-contained handoff containing the original task, exact error, relevant versions, inspected evidence, changes made, test results and next specific action. Distinguish an explanation or proposed repair from a verified fix. Do not stop at generic troubleshooting advice when you can continue investigating or repairing. 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.
View full AI instructions
Paste an error and say, “Fix it.”
What the AI will do
- Inspect the error and affected app, code or configuration, using logs, recent changes and relevant official documentation as needed.
- Make the smallest repair supported by the evidence; reproduce the error when that would help, without making reproduction a ritual for a simple fix.
- Retry the original task, inspect the result and continue until the fix is verified or a concrete blocker remains.
What you can provide
- The error text, a screenshot or a rough account of what happened, and what you were trying to accomplish.
- Access to the affected project or application when available; the AI investigates its actual capabilities first.
Where you'll take part
- Answer essential context questions or perform a specific access step the AI cannot do.
- Try the original action when only your account or device can complete the final check.
What you'll get
A repaired and verified original task, or the completed diagnosis and a precise handoff identifying the remaining blocked action.
Activity context
You do not need to understand an error message to begin fixing it. Give the AI the error and the thing you were trying to do, then let it inspect the actual setup, make the repair and check whether your original task now works.
For the user
Paste the error, attach a screenshot or describe what failed. Include the app or project if it is not obvious. The AI will inspect the situation and do the repair it can perform. Sometimes a missing setting or typo is enough; difficult failures need investigation. You may need to try the final action if it is available only on your device.
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
Help me fix this error and complete the task it interrupted. Investigate the actual affected artifact or configuration before prescribing setup changes. Keep the explanation in ordinary language and carry the repair through verification.
Understand the failed action
Read the exact error or inspect the supplied screenshot. Establish what I was trying to do, where it failed and what a successful result should look like. Use available context before asking one focused question about an essential gap. If I have supplied only a paraphrase, seek the actual message when its wording would change the diagnosis.
Inspect access to the affected app, project, command, configuration or service. Read relevant logs and the smallest source or settings area that could explain the failure. Check versions, environment and recent changes where they matter. Search existing issue reports, support discussions, project messages and recent deployment or configuration records for this error and its timing; a broad search of unrelated company correspondence adds no value.
Do not tell me to enable a control you have not inspected. Try available tools and supported access before asking me to export logs or gather a packet. If you cannot reach the affected environment, investigate the permitted connection or sharing route and ask for the smallest specific input or action needed. Keep credentials out of requested screenshots and diagnostic output.
Decide how much investigation is needed
A clear typo, missing file reference or plainly incorrect setting may support a small direct repair. Reproducing the failure before fixing it is optional, especially when the cause is evident and the change is easy to verify. Do not repeat a consequential failed operation merely to reproduce it.
When the cause is uncertain, form a specific hypothesis and choose the least disruptive check that can distinguish it from alternatives. Follow the evidence through the relevant inputs, configuration and failure point. Reproduce in a safe local or test setting when useful. Keep observed facts separate from plausible explanations and change one meaningful factor at a time where that helps identify the cause.
Consult current official documentation or release notes for the actual product and version when a setting, API, error meaning or supported repair is uncertain. Open the source and compare it with the observed configuration; do not apply a remembered command from a different version. Use existing project instructions and prior issue evidence where relevant. Stop research when it answers the repair question.
Make the supported repair
Explain the cause in one or two sentences when the evidence supports it, then make the smallest change that addresses that cause while preserving the intended behavior. Inspect the existing artifact before editing and keep unrelated user changes intact. Preserve a recoverable copy or focused change record where needed.
Carry out ordinary reversible repairs within the authorized environment. If the repair would require a consequential change outside the request—such as deleting data, changing production access or purchasing a service—prepare the exact proposed change and ask for the necessary decision before applying it. Continue independent diagnosis or local preparation while waiting.
If several repairs have materially different effects, show the practical difference and recommend the one supported by the evidence. Do not make me choose among unexplained technical possibilities. Ask only when the choice affects the intended outcome or a tradeoff only I can settle.
For a genuinely complex failure with separable causes, use bounded agents for independent log, configuration or dependency investigations where useful. Give them the same failed action, relevant source references, a specific question and an evidence-based completion criterion. Collect findings before integrating changes. Keep edits coordinated; for a small error, one focused investigation is sufficient.
Verify the original task
Retry the original action or the closest faithful permitted check after the repair. Inspect the actual output or state change, not merely the disappearance of one error message. A command that now exits successfully may still produce the wrong file or fail to save the intended record. Check the result against what I was trying to accomplish.
Run focused existing tests when they meaningfully cover changed behavior. For a simple low-impact repair, a direct successful task check may be enough; do not build a test suite that merely mirrors the edit. Check adjacent behavior when the repair could affect it, and broaden testing only for a new failure or unresolved concern.
If the original action still fails, use the new evidence to revise the diagnosis and continue. Do not stack speculative changes. If the final check requires my private device, login or physical action, give me one precise test and wait for its actual result. Until it returns, describe the repair as applied but unverified.
Deliver the working result or exact blocker
Lead with whether the original task now works. Briefly explain what changed and what actual check supports that conclusion. Provide the usable output when the task produced one.
If essential access, a user decision or an external service prevents completion, identify the concrete blocker and the work already completed. Prepare a self-contained handoff containing the original task, exact error, relevant versions, inspected evidence, changes made, test results and next specific action. Distinguish an explanation or proposed repair from a verified fix. Do not stop at generic troubleshooting advice when you can continue investigating or repairing.
Done when
The original task succeeds and its result has been inspected. If the final action cannot be performed, the diagnosis and any repair are preserved with the exact remaining check or blocker, and completion is not claimed.
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.