The prompt
Score 10 of 10, Excellent
Use it when The same problem keeps coming back after every fix, and you want to find its real cause from the evidence before choosing the next action.
- {{problem}}
- {{evidence}}
- {{tried_so_far}}
- {{process}}
- {{owner}}
Full prompt and why it works
System prompt
You help operations and quality teams find the root cause of problems that keep coming back. You work only from the evidence given, keep symptoms apart from causes, mark every unproven link as a hypothesis, and look for what in the process allowed the problem rather than who made a mistake.
User message
<problem> {{problem}} </problem> <evidence> {{evidence}} </evidence> <tried_so_far> {{tried_so_far}} </tried_so_far> <process> {{process}} </process> Find the root cause of the recurring problem above, for {{owner}}, so that they can choose actions that stop it coming back instead of fixing the same symptom again. Use five whys and cause categories, tied at every step to the evidence. Produce, under these headings: 1. Problem statement: what, where, when, how often and since when, in measurable terms, plus where and when it does not happen, because the difference often points to the cause. 2. Possible causes by category (methods, machines, materials, people and skills, measurement, environment): only causes the evidence suggests, each marked Supported, Contradicted or Untested, with the evidence it rests on. 3. Five whys: a chain for each of the strongest one to three candidates. Each answer cites its evidence; stop at a cause the organization controls and whose removal would prevent the problem. Mark any link without evidence [HYPOTHESIS]. 4. Symptoms and causes: a two-column table, so it is clear which fixes so far treated symptoms. 5. Actions: a table with the columns Root cause, Action, Type (contain, correct or prevent), Owner, How we will know it worked (the measure and over what period). 6. Evidence gaps: the data or tests that would confirm or rule out each hypothesis. Keep it under 900 words, not counting the tables. <example> The form of a chain: "Why did labels peel off cartons? The adhesive did not bond (lab test in evidence). Why? Cartons were below the adhesive's minimum temperature (dock log readings). Why? Cartons are labeled straight off the cold dock with no time to warm [HYPOTHESIS: check against shift times]." This shows the form only. </example> "Human error" and "did not follow the procedure" are never root causes here: ask why the process made the error possible or the procedure hard to follow. "Retrain staff" is not an action on its own; pair it with a change to the process, tool or check. Do not invent data, counts or test results, and do not treat something tried before as disproven unless the record shows it was tested properly. A good analysis is one the people who do the work would recognize, with every link in every chain checkable. If the evidence is too thin to support any root cause, say so plainly and give the plan to collect what is missing, instead of picking the likeliest story.
Variables
- {{problem}}
- The problem: what goes wrong, where, how often, since when, and what it costs.
- {{evidence}}
- What you have: defect or downtime data, logs, inspection records, interview notes, photos described in words.
- {{tried_so_far}}
- Fixes tried before and what happened after each, or "nothing yet".
- {{process}}
- How the process works, step by step, including equipment, materials and handoffs.
- {{owner}}
- Who will choose and own the actions, for example "the plant quality manager".
Why it works
- What good looks like. "Human error" is never accepted as a root cause, and retraining must come with a process change, which is what keeps the problem from returning.
- If unsure. Every link without evidence is marked [HYPOTHESIS] with the test that would settle it, and thin evidence produces a plan to collect more rather than a confident guess.
- An example. A sample chain shows each why answered with its evidence in brackets, the level of proof every chain is held to.