Diagnose a missed AI instruction by isolating conflicts, missing context and task complexity, then test a smaller prompt and decide when to finish manually.

Direct answer: First check whether the missed instruction conflicts with another requirement, relies on information you have not supplied or asks the assistant to do something the application cannot support. Then test that instruction alone with a small synthetic example, adding the remaining requirements back one at a time. If the same bounded task still fails, check the requirement manually or with a fixed rule in your existing software rather than assuming repeated reminders will guarantee compliance.

Adding stronger wording is an understandable response to a repeated mistake. It can also make the prompt harder to diagnose. You may end up with several overlapping demands, examples that contradict them and a conversation full of earlier instructions that no longer describe the desired result.

The useful question is which condition produces the failure. The parent guide, A Useful AI Workflow for Focused Knowledge Work, establishes the wider boundary between assistance and judgement. Here, use the instruction isolation sequence, an editorial troubleshooting method for locating one unreliable requirement without redesigning your entire workflow.

Applies to: ordinary text tasks in AI chat applications, particularly formatting, extraction and short drafting. The examples are synthetic and have not been executed as product tests.

Define a failure you can actually observe

Replace “it doesn't listen” with one checkable statement. Examples include a response containing four bullets when you asked for two, a missing source field, or an invented value where the input was blank. Keep style preferences separate from objective failures.

Then write the smallest acceptable output yourself. This exposes contradictions before you spend time experimenting. If you cannot create a response that satisfies the requested length, detail and format simultaneously, the task needs a decision from you rather than another generation attempt.

For instance, asking for one sentence containing every detail of a complex report may be incompatible with a strict short limit. Decide whether completeness or brevity takes priority. Do not leave the assistant to silently choose and then treat every compromise as the same kind of failure.

Save the original prompt and one representative failure. Use synthetic or authorised material for diagnosis. Screenshots and chat exports can include private information, so remove that information before sending evidence to a support service or another tool.

Use the instruction isolation sequence

Separate the task from the material

Make it clear which text is an instruction and which text is the source to be transformed. A pasted email may contain requests intended for its recipient, not for the AI application. Your task should identify that distinction.

OpenAI's API prompting guidance recommends separating instructions from context and specifying the desired output. Anthropic's prompting guidance also emphasises clear requirements and relevant examples. These are vendor recommendations, not guarantees that a particular prompt will work across every model or chat application.

Remove conflicting preferences

Read every instruction, including the example, looking for incompatible outcomes. “Use only information from the source” conflicts with “fill every field” when a field is missing, unless you define what to output for missing information.

Also check relevant saved preferences or project instructions in the application. OpenAI documents custom instructions for ChatGPT, which is one example of settings outside the current message that can affect responses. Do not assume another application handles such preferences the same way.

If you temporarily change a personal preference for diagnosis, copy it first and restore it afterwards. Do not remove workplace controls or security protections. When a restriction belongs to an organisation or service, clarify the permitted task instead of trying to bypass it.

Test the missed requirement alone

Use a short input whose correct result you already know. For example, supply a fictional event with a title, date and location, then ask for the title and date only. If the failure involves missing values, create a second event without a date.

The following is an illustrative, untested prompt:

> Extract the event title and date from the source below. Return two labelled lines: Title and Date. Copy the supplied values without adding other details. If a value is absent, write “Not supplied” for that field. Source: Event title: Library workshop. Location: Room C.

The expected content is the supplied title and a missing-date marker. You can check that directly. If the assistant invents a date, the failure is visible without assessing a long prose answer.

Repeat with a different short source before declaring success. One correct response establishes only that the task worked once under those conditions.

Add requirements back individually

Once the small task works adequately, restore one removed condition at a time. Perhaps you add a third field, then a word limit, then the requirement to produce a short explanation. Keep the inputs and checking criteria consistent.

Record the point where failure returns. If the two-field extraction succeeds but adding an explanation causes extra content to appear in the output fields, separate extraction from explanation. The resulting two-step process may be easier to inspect even if it needs another interaction.

Do not change the model, input length and prompt wording together unless you only need a working result and do not care which change mattered. For diagnosis, changing several things at once prevents you from identifying the cause.

Distinguish a prompting problem from a task limit

A model is the system generating the response; the application determines what files, tools, settings and permissions it can use. Asking for live information does not establish that the current application can browse. Asking it to edit a file does not establish access to that file.

Check the application's official documentation when the task depends on a capability. If the feature is unavailable to your account, prompt refinement is not the missing step. Supply authorised source material, choose a supported workflow or complete the task elsewhere.

Even with a clear task, generated output can be inconsistent. NIST's Generative AI Profile includes divergence from prompts among the output risks it describes. Treat that as a reason to verify important constraints, not as evidence that every failure has the same technical cause.

My recommendation is to enforce exact counts, required fields and file formats outside the model when those requirements repeatedly cause rework. A spreadsheet check, a document editor's count or a simple manual review may be sufficient. You do not need to build software to make a reliable check.

Read a small experiment without overstating it

Suppose you create 12 synthetic event notices, including missing dates, long titles and irrelevant extra details. This example is entirely illustrative; no application was tested and the counts are not a product benchmark.

Your first prompt produces six outputs that fail at least one required formatting or missing-value check. The failure rate within this fictional set is 6 ÷ 12 × 100 = 50%.

After removing a conflicting example, the revised prompt produces two failing outputs. The corresponding rate is 2 ÷ 12 × 100 = 16.7%, rounded to one decimal place. That is four fewer failures, or a reduction of approximately 33.3 percentage points within the sample.

It is not proof of a 16.7% future failure rate. The same small examples helped you revise the prompt, so they are no longer an independent check of unfamiliar inputs. Try new synthetic notices before deciding the change generalises, and keep the actual work subject to the checks it needs.

Also inspect what failed. Two invented dates may matter more than six cosmetic punctuation differences. Count each failure type separately and decide which ones make an output unusable. A single combined score can conceal the error you most need to prevent.

Keep the working prompt small enough to maintain

Save the final prompt with a description of its task, accepted input and checks. Remove abandoned experiments from that saved version. A colleague should be able to understand what each instruction is doing without replaying the whole conversation.

Keep a few representative synthetic inputs alongside it, including cases that previously failed. Revisit them when the application or selected model changes, or when real work develops a new kind of exception. The goal is a maintainable process, not a prompt that claims to anticipate every possible failure.

Diagnose one recurring failure in 25 minutes

  1. Spend five minutes defining the exact failure and writing a correct small example yourself.
  2. Use ten minutes to remove conflicts and test the missed instruction on synthetic material. Keep a record of each change and result.
  3. Use another five minutes to restore the minimum additional requirements and identify any point where failure returns.
  4. In the final five minutes, choose whether to keep the simpler prompt, split the task or finish it manually. Save the working version and its checks.

This is an editorial time limit for a small recurring text task. Stop earlier if the application lacks the required capability or a service restriction prevents the action. For a one-off piece of work, manual correction can be the most sensible finish once further experimentation costs more attention than the remaining task.

Frequently asked questions

Will writing the instruction in capital letters make it work?

There is no general guarantee that capital letters solve an instruction-following problem. They may make a requirement more visually prominent to a human reading the prompt, but they do not resolve a contradiction, supply missing information or create an unavailable capability. Diagnose those causes first. If you try different emphasis, compare the same task and inputs rather than judging one fortunate response. Keep the final wording readable and remove repeated demands that add no meaning. A short explicit output rule is easier to maintain than a page of escalating warnings around the same unresolved requirement.

Should I start a new conversation when an instruction keeps failing?

It can be a useful diagnostic step when the conversation contains obsolete or conflicting requirements. Preserve the source material and current task first, then try the smallest version in a fresh conversation. However, do not assume that a new chat removes every application-level preference or project rule. Check the documented behaviour of the service you use. If the small task succeeds, reintroduce only the context it needs. If it still fails, investigate the requirement itself or the application's capability instead of repeatedly opening new chats and hoping for a different result.

Why does asking the assistant to explain its mistake not fix it?

An explanation generated after a failure is not a verified account of the system's internal cause. It may suggest a useful hypothesis, but the next output can still violate the same requirement. Treat the explanation as something to test against observable changes. If the assistant says the prompt was ambiguous, rewrite that ambiguity and compare results on known inputs. Do not accept an apology or promise as evidence of improved reliability. The useful result is a corrected output that passes your checks, together with a process that remains manageable when another failure occurs.

Can I solve an exact word limit with a better prompt?

You can request a target length, but check the finished count in the tool where the text will be used. Different counting conventions can also disagree over hyphenated terms, numbers or headings. Define what counts before treating a small difference as a model failure. When a submission has a strict maximum, leave room and edit the final text to the required count instead of repeatedly generating near-identical drafts. If the needed content genuinely cannot fit, prioritise it yourself. A more forceful prompt cannot make incompatible length and completeness requirements simultaneously reasonable.

Is switching to a paid model the next step after prompt repair fails?

Not automatically. First establish whether the problem is a model limitation, an application restriction or an impossible task definition. A paid option is relevant only when a documented capability or a representative trial supports improvement for this requirement. Compare the same inputs and checks, and include additional cost and remaining review effort. For occasional formatting mistakes, manual correction or an existing editor may be more sensible. If the task is consequential, payment does not remove the need to verify it. Do not infer suitability from a model's general reputation or a polished demonstration.

What should I do when a legitimate request is refused?

Check whether the request is clear, permitted and supported in the current application, then consult its official help or support route if the refusal appears mistaken. Describe the legitimate task and relevant context plainly, without disguising its purpose or attempting to remove protections. A refusal is a different problem from an omitted formatting instruction and should not be counted as the same experimental failure. If the service cannot support the task, use an authorised alternative or complete it manually. Preserve only the non-sensitive details needed for support, rather than sending confidential material to demonstrate the issue.

Sources and verification

  • OpenAI: Best practices for prompt engineering with the API, checked 9 September 2026 for documented instruction, context and output-format guidance. API recommendations are not presented as chat-interface guarantees.
  • Anthropic: Prompting best practices, checked 9 September 2026 for clear requirements and examples. No model-specific benchmark claim is used.
  • OpenAI: ChatGPT Custom Instructions, checked 9 September 2026 for the existence of application preferences outside the current message.
  • NIST: Generative AI Profile, section 2.2, consulted for risks including output divergence from instructions.
  • The instruction isolation sequence and 12-output experiment are editorial and illustrative, not recorded product tests. The assigned parent was read in supplied project content; its specified public URL could not be reached, so supplied internal paths are retained.
Twokq Tech

This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.