Build a tool that improves itself from feedback.

What the AI will do

• Examines how your tool is used and where people succeed, struggle or complain.
• Builds a recurring improvement loop that proposes tested fixes or applies the kinds of fixes you have chosen to trust it with.

What you can provide

• An existing AI-built tool or one you are building, with access to its code or editable setup.
• Whatever usage records, support messages or user feedback already exist; the AI finds useful evidence and adds measurement where it is missing.

Where you'll take part

• Explain what successful use should mean when the existing record cannot establish it.
• Choose the review cadence and which changes need your review or may be applied automatically.
• Review a real example of the loop finding a problem, testing a repair and reporting the result.

What you'll get

A tool with working usage measurement and a recurring, tested improvement process, plus a record of what it found, changed and learned.

Activity context

When you build a tool with AI, give it a way to learn from being used. Who comes back? Where do people get stuck? Which complaints keep returning? That evidence can feed a regular loop that proposes improvements or, once trusted within defined limits, makes them.

For the user

Give the AI a starting point for the tool: a link, project folder or rough description. It will inspect the tool and its available evidence, add what it needs to observe real use, and build the improvement loop. You will define useful success and choose how much freedom the loop has to make changes.

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

Understand the tool and what useful success means

Add a self-improvement feature to my existing tool or the tool we are building. The result must be a working loop that measures actual use, identifies recurring problems, develops and tests fixes, and either proposes them or applies them within the authority I choose.

Inspect the tool's code, configuration, documentation and user-facing behavior. Identify its intended users, their tasks and what a successful result means. Search relevant project emails, chats and other messages, including WhatsApp where accessible, product and support meeting transcripts, calendar-linked user sessions, issue trackers, release notes, support tickets and user feedback. Use the tool's name, feature names, error messages and relevant teams as search terms. Establish what people were trying to do, the failures they reported and any previous decisions about how the tool should behave. Distinguish a documented user need from your proposed improvement.

Inspect and try the available code, application, logs, analytics and feedback access before asking me to gather anything. Where a source is unavailable, investigate its supported connection or export route and ask for the smallest necessary action. If records do not yet exist, instrument the tool and begin collecting them; do not invent a history. A prototype with no real usage can demonstrate the loop using clearly labeled test cases, but cannot yet show that users benefited.

Make use and failure observable

Inventory the existing measurements and identify the missing evidence. Propose a small set of events tied to meaningful tasks, rather than treating clicks or time spent as success by themselves. Capture:

• Who uses the tool, at an appropriate user or team level, and whether useful differences exist among their needs.
• When and how often they use it, and which actions or workflows they attempt.
• Which attempts succeed, fail, are abandoned or require a workaround, using an observable definition where possible.
• Relevant errors, tool and model versions, timing and operating cost when these help explain the experience.
• Available complaints, feedback and support outcomes, connected to a task or release when the record supports that link.

Use existing approved identities and data handling rules; record only what is needed to understand and improve use. Keep task content out of event records when a reference or outcome will do. Ask me to resolve any important ambiguity about success, acceptable failure or who the tool serves.

Implement the missing telemetry in the actual tool and its storage. Verify that events arrive, retries are not counted as separate people or successes, and an unavailable measurement remains unknown rather than being recorded as a success. Where outcomes require human judgment, build a light way to collect that judgment instead of fabricating a metric.

Build the recurring diagnosis and repair loop

Agree on a useful review cadence and a manageable first scope. On each run, have the system group recurring failures and complaints by task, affected users and version, then examine representative examples and counterexamples. Separate how often a problem occurs from how severe it is. Distinguish observed patterns from proposed causes.

For each promising improvement, identify the evidence, reproduce the problem where possible, and state a testable explanation of its cause. Choose a bounded repair with an expected user benefit and a way to check that benefit. Avoid changing several unrelated behaviors so the effect cannot be understood.

Build the loop so it can create and test a proposed code or configuration change in an isolated environment, preserving the original. Use representative successful uses as regression cases as well as the failure examples. Keep some evaluation cases separate from the examples used to produce the fix; check the repair against intended behavior, not merely against the new implementation. Consult current official documentation for the actual runtime, model, telemetry and deployment interfaces as needed.

Where useful, give a diagnosis agent bounded evidence and a repair agent the confirmed problem. Have a separate reviewer inspect the proposed change, intended behavior and evaluation results without the repair agent's defense. The lead reconciles findings and keeps the evidence and change history. When agents are unavailable, use separate passes and explicit handoffs, and disclose that the review shares context.

Choose how much the loop may change by itself

Show me the proposed operating rule after a repair is concrete enough to review. In proposal mode, produce the repair, evidence, test results and expected effect for the appropriate person to accept. If I want trusted automatic fixes, define the permitted change categories, evaluation requirements and bounds first; then build automatic application for changes that satisfy those rules. Anything outside them remains a proposal. Reuse authority already given, and wait for a consequential unresolved choice.

Make every applied change traceable to the observations that motivated it and the checks it passed. Retain the previous version, provide a simple way to pause or revert, and compare subsequent use with the pre-change baseline. Define the condition that triggers a rollback or sends the issue back for review. Improvements to the loop's own acceptance rules require the same chosen authority; it must not quietly lower its standards to pass a repair.

Run the loop and verify the result

Connect the scheduled job, evidence store, repair workspace and chosen review or deployment destination. Verify a complete cycle: a measured failure or complaint is collected, diagnosed, turned into a bounded change, evaluated and delivered as a proposal or applied under the agreed rule. Exercise a failed evaluation too, and verify that it cannot be applied automatically. Confirm that later observations can be associated with the changed version.

For existing tools, use a real problem when accessible and report which parts of the result have real usage evidence. For new tools, label demonstration events as test data and report the first real feedback review as pending. Configure and verify the next scheduled run and make absent or stale telemetry visible.

Deliver the working feature, its location, measurement definitions, schedule and change record. Give me a short report that answers: what did it learn, what did it change or propose, did the checks pass, and what evidence will show whether people are better served? If you cannot access the code, runtime or deployment destination, build and test as much as the available environment permits and identify the exact missing action. Do not present an improvement plan or a simulated loop as a running feature.

Done when

The tool records meaningful usage and has completed a demonstrated diagnosis-and-repair cycle, with a verified recurring schedule and the proposal or automatic-change rules you chose. Evidence from test use and real users is clearly distinguished; missing access is identified as unfinished work.

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.