Red-team your own AI tool before launch.
Send a crowd of AI testers at your tool before your users find the awkward parts. Some will hunt for security flaws. Others will misunderstand it, get lost, use strange inputs or try the thing you forgot to consider. Turn their findings into a better working version.
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
- Investigate what your AI tool is supposed to do and organize many AI testers across security, usability, confusion and edge cases.
- Run bounded testing waves, reproduce findings, repair the tool and retest the affected behavior.
What to have ready
- A working tool or test build, its intended users and any known concerns.
- Access to the permitted test environment, requirements and relevant user feedback; sample or synthetic data can be used.
Where you come in
- Confirm the test scope, important success criteria and any product decisions the findings expose.
- Review the corrected tool and decide what the remaining evidence means for launch.
What you'll get
A tested and improved tool, reproducible findings, a record of actual test coverage and a clear account of what remains unresolved.
You're done when
A tested and improved tool, reproducible findings, a record of actual test coverage and a clear account of what remains unresolved.
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. ### Establish the tool and an actual test environment Use many AI agents to test this AI tool before launch. Cover security flaws, usability problems, confusing instructions or responses, edge cases and failures of the intended task. Do the testing and subsequent repair work using available tools; do not stop at a list of questions for people to check manually. Read the tool’s interface, configuration, instructions, retrieval sources, available actions and current implementation where accessible. Search requirements, development discussions, user requests, issue reports, prior test results and relevant emails, chats and transcripts. Use the tool and project names to establish who it serves, what users are trying to accomplish, expected outputs, intended permissions and prior failures. Ground user perspectives in actual roles, needs, vocabulary and feedback; mark invented test personas as constructed cases. Inspect the environment and test access with a small supported operation. Establish the exact build, accounts, data and systems in scope. Use an isolated test environment and synthetic or explicitly permitted data. Keep irreversible actions, external messages, payments and production changes out of the tests unless a separately approved test arrangement makes their boundaries explicit. Do not probe third-party systems outside the authorized scope. If access is missing, investigate the documented connection or test setup and prepare the smallest necessary request. Continue inspecting supplied code, screenshots or example conversations, but distinguish static review from interacting with the tool. A crowd of agents imagining a screen is not a crowd that has tested it. ### Define what good behavior looks like Translate the tool’s purpose into representative user tasks and observable completion criteria. Identify the most consequential claims, calculations, retrieval results, decisions and actions it produces. Establish source-backed expected answers or a rubric where an exact answer is inappropriate. Ask me to settle product choices the records cannot establish, one question at a time. Make a test map covering the important combinations of user role, task, data state, permission and interface path. Include ordinary success paths as well as failure cases. Prioritize consequential or likely combinations rather than claiming every possible input can be tested. Preserve some cases for a fresh pass after repairs. ### Organize many useful AI testers Inspect actual agent and session capacity. Propose enough distinct bounded assignments to cover the test map, using successive waves when the platform cannot run them all at once. More identical prompts are not broader testing. Useful lanes include: - Security and access: can a user obtain data outside their role, expose hidden test secrets, cause retrieved or uploaded text to redirect the tool, or induce an action outside its intended authority? Use controlled fixtures and authorized test accounts; record the exact boundary tested. - Usability: can different evidence-informed users find the starting point, complete a real task, understand the result, correct a mistake and know what happens next? - Confusion and interpretation: try ambiguous requests, unfamiliar vocabulary, contradictory instructions, misleading labels and outputs that look more certain than their evidence. - Edge cases and resilience: missing, malformed, oversized, duplicate or conflicting inputs; unavailable sources; interrupted sessions; retries; empty results; and failure recovery where relevant. - Core task quality: source fidelity, reasoning, calculations, omissions, appropriate uncertainty and whether the result actually helps the user do the job. Give each tester the actual tool/build and permitted access, a neutral user/task brief, its bounded cases, source references needed to assess outputs, prohibited out-of-scope actions and a return format. Usability testers receive only context a user would have, not the builder’s explanation of how to succeed. Security or factual reviewers may need additional implementation or source evidence; keep that role distinction explicit. Require each return to identify test case, starting state, steps or exact input, observed output, expected behavior and its basis, evidence location, consequence, reproducibility and anything untested. Agents should actually operate the tool where possible and preserve screenshots, traces or outputs appropriate to the environment. Keep initial findings independent before sharing a proposed diagnosis. Track assignments, access, completed cases and missing coverage. If agents must share mutable test data, isolate their fixtures or run those cases in separate waves to prevent one tester’s changes from corrupting another’s result. Without subagents, use fresh sessions or bounded sequential passes with explicit handoffs; state the lack of independence and actual scale achieved. ### Reproduce and prioritize the findings Collect the actual results. Group duplicates without losing the different contexts in which a problem occurs. Separate observed failures from speculative concerns or tester misunderstandings. A misunderstanding can be a real usability finding even when the code behaves as designed; identify the interface or expectation that caused it. Reproduce material failures from the saved input and state, or state why they could not be reproduced. Inspect the tool and evidence to find the cause. Rank findings by consequence, likelihood and affected users, not by how dramatic the tester sounds. Flag missing tests and inaccessible behavior separately from passed cases. Do not interpret silence or a plausible AI explanation as evidence of safety. Present the few findings requiring a product decision in plain language with concrete before/after behavior. Ask me to resolve a consequential tradeoff while continuing independent repairs. Keep the fuller reproducible record available without making me coordinate the testing team. ### Repair, retest and check the experience again Implement the supported fixes within the agreed scope, preserving a recoverable prior version. Changes may involve instructions, retrieval, interface copy, validation, permissions, code or the intended workflow; a prompt warning alone does not establish an enforced permission boundary. Verify the actual behavior that failed. Have the relevant tester rerun the original cases on the identified revised build. Run nearby cases and essential ordinary tasks that the change could affect. Use fresh testers and the held-back cases for important repairs, including another uncoached usability attempt where confusion was the issue. Preserve failed tests and corrected results with their build versions. Repeat for unresolved material findings; broaden testing when a repair exposes a new concern, not merely to accumulate agent reports. If you cannot modify the tool, prepare specific changes and a complete developer handoff with reproduction evidence. Retesting remains pending until a changed build is available. Do not claim a repaired or launch-ready tool from a report alone. ### Deliver the improved tool and the evidence Provide the working revised tool or exact access point, a concise account of consequential fixes, the reproducible findings and the coverage record. State how many AI testers or distinct sessions actually ran, which tasks and conditions they exercised, which reviews were independent and what remains inaccessible or untested. Do not equate the number of agents with proof of comprehensive coverage. Compare the actual results with the agreed launch criteria. Identify unresolved findings that need a decision and the evidence still missing. Let me decide launch or wider release; completing these tests does not publish the tool. Finish with the usable improvement and an honest account of its tested behavior, not a blanket security or usability certification. 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
Red-team your own AI tool before launch.
What the AI will do
- Investigate what your AI tool is supposed to do and organize many AI testers across security, usability, confusion and edge cases.
- Run bounded testing waves, reproduce findings, repair the tool and retest the affected behavior.
What you can provide
- A working tool or test build, its intended users and any known concerns.
- Access to the permitted test environment, requirements and relevant user feedback; sample or synthetic data can be used.
Where you'll take part
- Confirm the test scope, important success criteria and any product decisions the findings expose.
- Review the corrected tool and decide what the remaining evidence means for launch.
What you'll get
A tested and improved tool, reproducible findings, a record of actual test coverage and a clear account of what remains unresolved.
Activity context
Send a crowd of AI testers at your tool before your users find the awkward parts. Some will hunt for security flaws. Others will misunderstand it, get lost, use strange inputs or try the thing you forgot to consider. Turn their findings into a better working version.
For the user
Bring the tool, even if it is rough. The AI will work out what it can access and recruit as many useful testing perspectives as the available environment can support, using successive waves when needed. You provide product judgment; the AI carries testing, diagnosis, repairs and rechecks.
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
Establish the tool and an actual test environment
Use many AI agents to test this AI tool before launch. Cover security flaws, usability problems, confusing instructions or responses, edge cases and failures of the intended task. Do the testing and subsequent repair work using available tools; do not stop at a list of questions for people to check manually.
Read the tool’s interface, configuration, instructions, retrieval sources, available actions and current implementation where accessible. Search requirements, development discussions, user requests, issue reports, prior test results and relevant emails, chats and transcripts. Use the tool and project names to establish who it serves, what users are trying to accomplish, expected outputs, intended permissions and prior failures. Ground user perspectives in actual roles, needs, vocabulary and feedback; mark invented test personas as constructed cases.
Inspect the environment and test access with a small supported operation. Establish the exact build, accounts, data and systems in scope. Use an isolated test environment and synthetic or explicitly permitted data. Keep irreversible actions, external messages, payments and production changes out of the tests unless a separately approved test arrangement makes their boundaries explicit. Do not probe third-party systems outside the authorized scope.
If access is missing, investigate the documented connection or test setup and prepare the smallest necessary request. Continue inspecting supplied code, screenshots or example conversations, but distinguish static review from interacting with the tool. A crowd of agents imagining a screen is not a crowd that has tested it.
Define what good behavior looks like
Translate the tool’s purpose into representative user tasks and observable completion criteria. Identify the most consequential claims, calculations, retrieval results, decisions and actions it produces. Establish source-backed expected answers or a rubric where an exact answer is inappropriate. Ask me to settle product choices the records cannot establish, one question at a time.
Make a test map covering the important combinations of user role, task, data state, permission and interface path. Include ordinary success paths as well as failure cases. Prioritize consequential or likely combinations rather than claiming every possible input can be tested. Preserve some cases for a fresh pass after repairs.
Organize many useful AI testers
Inspect actual agent and session capacity. Propose enough distinct bounded assignments to cover the test map, using successive waves when the platform cannot run them all at once. More identical prompts are not broader testing. Useful lanes include:
- Security and access: can a user obtain data outside their role, expose hidden test secrets, cause retrieved or uploaded text to redirect the tool, or induce an action outside its intended authority? Use controlled fixtures and authorized test accounts; record the exact boundary tested.
- Usability: can different evidence-informed users find the starting point, complete a real task, understand the result, correct a mistake and know what happens next?
- Confusion and interpretation: try ambiguous requests, unfamiliar vocabulary, contradictory instructions, misleading labels and outputs that look more certain than their evidence.
- Edge cases and resilience: missing, malformed, oversized, duplicate or conflicting inputs; unavailable sources; interrupted sessions; retries; empty results; and failure recovery where relevant.
- Core task quality: source fidelity, reasoning, calculations, omissions, appropriate uncertainty and whether the result actually helps the user do the job.
Give each tester the actual tool/build and permitted access, a neutral user/task brief, its bounded cases, source references needed to assess outputs, prohibited out-of-scope actions and a return format. Usability testers receive only context a user would have, not the builder’s explanation of how to succeed. Security or factual reviewers may need additional implementation or source evidence; keep that role distinction explicit.
Require each return to identify test case, starting state, steps or exact input, observed output, expected behavior and its basis, evidence location, consequence, reproducibility and anything untested. Agents should actually operate the tool where possible and preserve screenshots, traces or outputs appropriate to the environment. Keep initial findings independent before sharing a proposed diagnosis.
Track assignments, access, completed cases and missing coverage. If agents must share mutable test data, isolate their fixtures or run those cases in separate waves to prevent one tester’s changes from corrupting another’s result. Without subagents, use fresh sessions or bounded sequential passes with explicit handoffs; state the lack of independence and actual scale achieved.
Reproduce and prioritize the findings
Collect the actual results. Group duplicates without losing the different contexts in which a problem occurs. Separate observed failures from speculative concerns or tester misunderstandings. A misunderstanding can be a real usability finding even when the code behaves as designed; identify the interface or expectation that caused it.
Reproduce material failures from the saved input and state, or state why they could not be reproduced. Inspect the tool and evidence to find the cause. Rank findings by consequence, likelihood and affected users, not by how dramatic the tester sounds. Flag missing tests and inaccessible behavior separately from passed cases. Do not interpret silence or a plausible AI explanation as evidence of safety.
Present the few findings requiring a product decision in plain language with concrete before/after behavior. Ask me to resolve a consequential tradeoff while continuing independent repairs. Keep the fuller reproducible record available without making me coordinate the testing team.
Repair, retest and check the experience again
Implement the supported fixes within the agreed scope, preserving a recoverable prior version. Changes may involve instructions, retrieval, interface copy, validation, permissions, code or the intended workflow; a prompt warning alone does not establish an enforced permission boundary. Verify the actual behavior that failed.
Have the relevant tester rerun the original cases on the identified revised build. Run nearby cases and essential ordinary tasks that the change could affect. Use fresh testers and the held-back cases for important repairs, including another uncoached usability attempt where confusion was the issue. Preserve failed tests and corrected results with their build versions. Repeat for unresolved material findings; broaden testing when a repair exposes a new concern, not merely to accumulate agent reports.
If you cannot modify the tool, prepare specific changes and a complete developer handoff with reproduction evidence. Retesting remains pending until a changed build is available. Do not claim a repaired or launch-ready tool from a report alone.
Deliver the improved tool and the evidence
Provide the working revised tool or exact access point, a concise account of consequential fixes, the reproducible findings and the coverage record. State how many AI testers or distinct sessions actually ran, which tasks and conditions they exercised, which reviews were independent and what remains inaccessible or untested. Do not equate the number of agents with proof of comprehensive coverage.
Compare the actual results with the agreed launch criteria. Identify unresolved findings that need a decision and the evidence still missing. Let me decide launch or wider release; completing these tests does not publish the tool. Finish with the usable improvement and an honest account of its tested behavior, not a blanket security or usability certification.
Done when
A tested and improved tool, reproducible findings, a record of actual test coverage and a clear account of what remains unresolved.
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.