Start with the result, not a list of fifty plugins
An old catalogue is a poor buying checklist. First describe the job: compare two supplied quotes, retrieve a current policy, draft a customer response or change a record. A file upload or a clearer brief may be enough; a connection is useful only when the task needs access it actually provides.
Do not treat an older product name as a promise about today's interface. Current OpenAI documentation distinguishes availability, connected-account access and runtime permission. A plugin can package reusable instructions and connections; its presence does not mean every person has authorised every connected service.
I need to [concrete result] using [documents or systems] for [audience] by [deadline]. First distinguish what can be done with text I supply, a redacted file, web research, or a connected tool. Do not invent available integrations or claim access to my accounts. Make a minimum-access plan, a sample output and a list of information I must verify in my actual product. Ask which system contains the authoritative record before recommending a connection.
Check what a connection can read and what it can change
Review the actual connection screen and official documentation. Availability, authorisation and permission are separate checks. Installing something for a team is not the same as granting everyone access to a shared account.
Begin with a small read-only test. Keep permission to send, delete, publish, buy or change records separate from permission to inspect information. Never paste passwords, tokens or authentication cookies into a prompt.
Help review this proposed AI connection [redacted permission screen and official documentation]. Our task is [job]. Separate data it can read, actions it can perform, account authorisation and administrator controls. Quote the supplied evidence; mark anything unknown. Propose one read-only test with non-sensitive sample data and a way to check the answer against the source. Do not connect, grant access or perform writes. Which permission is broader than this job requires?
Use voice and photographs without pretending they prove everything
A photograph can provide visible details, and a transcript can provide words to review. Neither proves hidden conditions, identity or what happened outside the supplied material. State what the assistant can actually inspect. Use a transcript or selected stills when direct audio or video inspection is unavailable.
Keep sensitive material out of a casual test. Ask for an evidence table before accepting a confident interpretation; label unclear text and uncertain observations.
Use [redacted photograph, accessible recording or transcript] to help me [task]. First state which material you can actually inspect. Separate visible or quoted evidence from interpretation and missing context. Mark unclear words instead of guessing, do not identify private people or infer medical conditions. Return [table or draft] and tell me what I need to check in the original. What single additional detail would change the answer most?
Turn a repeated task into reusable instructions, then test them
A reusable assistant should preserve the audience, output format, approved evidence and boundaries, not accumulate vague personality instructions. Keep a dated version of its brief and a few representative cases, including one with missing information.
A subscription comparison is also a task, not a permanent price table. Compare the dated official offers visible in your country and actual account. A model name, plan name or old screenshot is not proof that a particular tool is included.
Create reusable instructions for [repeated job]. Use these approved examples [anonymised input and desired output], rules [list] and limits [list]. Produce a short brief, three test cases including missing evidence, and a review checklist for factual accuracy and unauthorised actions. Do not claim the assistant is trained or tested merely because instructions exist. Keep uncertain product features unconfirmed until I provide dated official offers. Which failure should we test before using real customer data?
Accept the result only after checking the source and the action log
For the first run, inspect the underlying record and compare it with the generated answer. Before any authorised write, preview the exact change and its destination. Keep human approval for consequential actions and review whether the connection is still needed afterwards.
More tools do not guarantee a better answer. A useful test records the task, evidence, expected behaviour, observed failure and the next change. This guide does not report model rankings or tests we have not performed.
Review this tool-assisted result [output] against [source records and action log]. List supported statements, unsupported statements, missing records and any proposed changes. Do not execute changes. Suggest the smallest correction to the brief or access scope, then repeat the same test criteria. If access should end, point me to the relevant account controls without claiming to have revoked it. Which check must pass before I approve the next run?
Keep exploring
Sources and how this guide was prepared
Replaces our historical plugin catalogues and introductory tool articles. This is a task-based guide, not a current app catalogue or a comparative product test. Availability depends on the product, account and organisation settings.