Test before you trust. These prompts are starting points, not finished tools. Your data, your bot and the model behind it all change what comes back, and a prompt that works for us may need tweaking for you. Run each one on a small, known example first and check the result yourself before you rely on it. Don't paste it in and assume it works. We share these as-is, and we're not responsible for results from prompts used without testing.
A bot that knows fifty tools has a new problem: it will want to use all of them. A full FMEA for a two-line email. A fault tree for a lunch order. The first skill isn't running the tool. It's picking the right one.
What already exists
Two well-known guides do part of this:
- The IEC guide to risk assessment techniques, an international standard, describes several dozen techniques. It helps you choose by purpose, stage of the work, how much data you have, how uncertain things are, and how complex the decision is.
- Six Sigma tool guides sort tools by DMAIC phase: SIPOC in Define, fishbone and 5 Whys in Analyze, Pugh in Improve, and so on.
Both are useful. Neither covers management tools, and neither was written with bots in mind. This page borrows their logic and covers every tool in this series.
The selector in three steps
Step 1. What's the question?
Find the situation. Start with the first tool. Add the next ones only if you need them.
| Situation | Start with | Then, if needed | Don't start with |
|---|---|---|---|
| Starting a new product, service or bot | Kano model, SIPOC and turtle | APQP, QFD, Map the process | FMEA (nothing to analyze yet) |
| Finding risk before launch, broad | Pre-mortem | FMEA, then the 80 percent line | Fault tree (too narrow at first) |
| One outcome you can't accept | Fault tree analysis | Bow-tie | Risk matrix (too coarse) |
| Work handed between bots or teams | HAZOP guidewords | FMEA on the worst handoffs | — |
| A bot with powerful tools (send, spend, delete) | Hierarchy of controls | Bow-tie, poka-yoke, e-stops, Nothing ships without a yes | Writing more rules |
| Something is about to change | DRBFM | Lockout/tagout, Change on purpose, Verification | A full new FMEA |
| Something just went wrong | Contain it first (8D step 3) | Kepner-Tregoe, fishbone, 5 Whys, Fix the cause | Jumping to a fix |
| It reached a customer | 8D | Lessons learned entry | 5 Whys alone |
| The same problem keeps coming back | The 80 percent line, on real counts | Six Sigma DMAIC, design of experiments | Another quick fix |
| Choosing between options | Pugh or weighted matrix | Red team, pre-mortem on the winner | Gut feel in a meeting |
| Stuck on a trade-off ("stronger but lighter") | TRIZ | Time, cost, quality | Splitting the difference |
| Is this price or quote fair? | Should-cost | Pugh matrix for suppliers | Comparing three quotes only |
| Uncertain numbers adding up (fit, schedule, budget) | Monte Carlo | Design of experiments | Worst case only |
| Work is slow or wasteful | Value stream mapping | Lean, A3 | Speeding up the fastest step |
| Is it still working? | Verification and evals | SPC, control plan, tester bot | Waiting for complaints |
| Can we trust the checker? | SPC and checking the checker (MSA part) | Verification and evals | Trusting a checker that passes everything |
| Periodic step-back | Management review | Hoshin kanri | — |
| Rolling out a change to people | Stakeholder analysis | Force field analysis, RACI | The rollout plan alone |
| Who owns this? | RACI | Who owns what | — |
| Running a project | RAID log | After-action review at the end | — |
| A project or job just ended | After-action review | Lessons learned that actually get read | — |
| Looking outside the company | PESTLE and five forces | SWOT, then hoshin kanri | SWOT alone |
| What if a supplier, system or person disappears? | Business impact analysis | Fault tree | — |
| Any new job, any size | Lessons learned search | — | — |
Step 2. How much rigor?
The same question deserves different tools depending on what's at stake. See Risk sets the rigor.
| Rigor | When | Fits here |
|---|---|---|
| Light (minutes; a skim) | Two-way doors: drafts, internal notes, easy to undo | 5 Whys, risk matrix, SWOT, pre-mortem (short), A3, RAID log, Pugh, force field, stakeholder analysis, after-action review, PDSA |
| Medium (an hour of review) | Affects a customer, money, or other teams; undo is possible but costly | Fishbone, Kepner-Tregoe, FMEA (focused), 80 percent line, control plan, DRBFM, value stream map, should-cost, RACI, SIPOC/turtle, verification and evals, poka-yoke, lockout/tagout, PESTLE, business impact analysis |
| Heavy (a real review meeting, sign-off) | One-way doors: money moves, things ship, safety, legal, the brand | Fault tree, bow-tie, HAZOP, full FMEA with action priority, APQP, QFD, 8D, DMAIC, design of experiments, Monte Carlo, SPC and MSA, hierarchy of controls, e-stops and fail-safe, machine-safety risk assessment, hoshin kanri |
Rules: - Severity overrides size. A small job that could hurt someone, break a law or move money gets heavy tools. - Go up a tier after a change. A new model or new skills means the old results don't count yet. - Go down a tier only by decision, in writing.
Step 3. What do you have to work with?
Some tools need real data. Others work from documents. Others work from judgment. Using a data tool without data produces confident nonsense.
| Input you have | Tools that fit |
|---|---|
| Counts and measurements (defect logs, timestamps, test results, prices) | 80 percent line, SPC and MSA, Six Sigma, design of experiments, Monte Carlo, value stream mapping, Kepner-Tregoe, should-cost |
| Documents (drawings, process maps, skills, tool lists, plans) | FMEA, fault tree, HAZOP, bow-tie, DRBFM, quality chain, control plan, SIPOC/turtle, RACI, hierarchy of controls, business impact analysis, hoshin kanri |
| Customer words (complaints, reviews, interviews) | Kano model, QFD, APQP |
| Judgment and opinions | Pre-mortem, SWOT, risk matrix, red team, force field, stakeholder analysis, Pugh (weights) |
| History (old reports, past projects) | Lessons learned, after-action review, 8D step 7 |
If the tool needs data you don't have: collect it, or drop to a judgment tool and label the results as judgment. Never let a bot fill a data tool with invented numbers. See Don't make it up.
Common chains
Many jobs need tools in a sequence, each feeding the next.
| Job | Chain |
|---|---|
| New product | Kano → QFD → APQP → FMEA → the quality chain → control plan |
| New bot | SIPOC/turtle → map the process → HAZOP on handoffs → FMEA → hierarchy of controls → control plan → evals → SPC |
| Problem that reached a customer | 8D: contain → Kepner-Tregoe → fishbone → 5 Whys → fix the cause → verify → lessons learned |
| Chronic problem | 80 percent line → DMAIC → design of experiments → control plan → SPC |
| Change to a working process or bot | DRBFM → lockout/tagout → change on purpose → verification → tester bot |
| Big decision | Pugh → red team → pre-mortem on the winner → RAID log |
| Rolling out bots to a team | Stakeholder analysis → force field → RACI → after-action review |
| Annual planning | PESTLE and five forces → SWOT → hoshin kanri → management review |
The full matrix
Plan tools mostly look ahead, Do tools run or guard the work, Check tools watch it, Act tools fix and improve. The bot drafts every one; the "Person" column is the part to keep for a human.
| Tool | Answers | PDCA | Needs | Rigor | Person's part |
|---|---|---|---|---|---|
| Kano model | Which wants matter, and how? | Plan | Customer words | Light–Med | Confirm categories |
| QFD / House of Quality | Which specs deliver what customers want? | Plan | Customer words | Heavy | Set weights, judge strong links |
| APQP | How do we plan this to come out right? | Plan | Customer words, specs | Heavy | Real voice of the customer, sign-off |
| The quality chain | Does every spec reach a check? | Plan | Specs, FMEA, control plan | Medium | Sign off links |
| SIPOC and turtle | What are the edges and needs of this process? | Plan | Documents | Light–Med | Confirm with the people who do it |
| Map the process / data and schema | What are the steps and handoffs? | Plan | Documents | Medium | Agree the map |
| Time, cost, quality | Which side do we hold fixed? | Plan | Job description | Light | Choose |
| Should-cost | What should this cost? | Plan | Drawing, rate table | Medium | Check routing and cycle times |
| Pugh / decision matrix | Which option? | Plan | Evidence per option | Light–Med | Set weights first, decide |
| TRIZ | How to beat a trade-off? | Plan | Problem statement | Medium | Pick ideas to test |
| Monte Carlo | How does uncertainty add up? | Plan | Real ranges | Heavy | Supply inputs, accept risk |
| Pre-mortem | How could this fail? | Plan | Plan documents | Light | Pick the believable stories |
| Risk matrix | Where to look first? | Plan | Judgment | Light | Adjust placements |
| SWOT | Where do we stand? | Plan | Judgment, research | Light | Correct it |
| PESTLE and five forces | What's changing outside? | Plan | Sourced research | Medium | Read the high-impact items |
| FMEA | What could fail, how bad, how caught? | Plan | Process or design documents | Med–Heavy | Review severe rows, decide actions |
| The 80 percent line | Which few items matter most? | Plan/Act | Scores or counts | Medium | Confirm the line, severity first |
| Fault tree | How could the worst outcome happen? | Plan | System description | Heavy | Check gates, fix single points |
| Bow-tie | How do we prevent it and recover? | Plan | Tools, barriers, backups | Heavy | Confirm barriers are real |
| HAZOP guidewords | What if a handoff goes wrong? | Plan | Process map with handoffs | Heavy | Fix gaps with no safeguard |
| Machine-safety risk assessment | What can this bot touch, and how bad? | Plan | Tool and access list | Heavy | Accept residual risk |
| Hierarchy of controls | Strongest way to control this hazard? | Plan/Do | Tool and access list | Med–Heavy | Remove capabilities |
| Business impact analysis | What if it disappears? | Plan | Process map, suppliers, RACI | Medium | Correct impacts, choose fallbacks |
| Stakeholder analysis | Who's affected and who can stop it? | Plan | Plan, org chart | Light | Add what you know about people |
| Force field analysis | What pushes back? | Plan | Notes, comments | Light | Add the unspoken forces |
| RACI | Who does, who decides? | Plan/Do | Process, org chart | Medium | Settle conflicts; one A, a person |
| Hoshin kanri | Does all work connect to the goals? | Plan | Strategy, projects, KPIs | Heavy | Catchball |
| RAID log | What are we assuming? | Do | Notes, email | Light | Confirm or convert assumptions |
| Lessons learned search | Has this bitten us before? | Plan/Do | Archive | Light | Throw out bad matches |
| Poka-yoke | Can we make the mistake impossible? | Do | Process, failure list | Medium | Approve the change |
| Nothing ships without a yes | Who releases this? | Do | — | All | Say yes |
| Lockout/tagout | Is it safe to work on? | Do | Routine and access list | Medium | Lock and unlock |
| E-stops and fail-safe | Can we stop it, and does it fail safe? | Do | Routines, settings | Heavy | Know the real off switch |
| Control plan | What do we check, how often, and what then? | Do/Check | FMEA, specs | Medium | Own the reaction plan |
| Verification and evals | Did it come out right? Does the bot do it right? | Check | Results, test set | Medium | Write known answers, review samples |
| Tester bot / internal audit | Does the bot follow its instructions? | Check | Test scripts | Medium | Review runs now and then |
| SPC and MSA | Has it really changed? Can we trust the checker? | Check | Counts over time; repeat verdicts | Heavy | React to signals; supply known answers |
| Management review | Is the whole system working? | Check/Act | Records, tests, costs | Medium | Make the decisions |
| Value stream mapping | Where does work wait? | Check | Timestamps | Medium | Walk the process once |
| 5 Whys | Why did it happen? | Act | Evidence | Light | Check each why is real |
| Fishbone | What could be causing it? | Act | Evidence | Medium | Pick likely causes |
| Kepner-Tregoe | Where is it, and where isn't it? | Act | Records | Medium | Verify the top cause |
| 8D | How do we fix this and keep it fixed? | Act | Complaint, records | Heavy | Containment, sign-off |
| A3 | What's the problem and plan, on one page? | Act | Facts | Light | Take it to people, revise |
| DRBFM | What does this change touch? | Act/Plan | Before and after versions | Medium | Review unexpected effects |
| Change on purpose | Is this change approved and recorded? | Act | Change request | Medium | Approve |
| PDCA / PDSA | Did the change do what we predicted? | Act | Prediction, results | Light | Decide: adopt, adapt, drop |
| Six Sigma DMAIC | How do we cut a chronic problem? | Act | Baseline data | Heavy | Approve fixes, own Control |
| Design of experiments | Which factors actually matter? | Act | Test runs | Heavy | Pick factors, run tests |
| Lean (waste, jidoka) | Where's the waste? When do we stop? | Act | Process, logs | Medium | Decide what to cut |
| After-action review | What happened vs. the plan? | Act | Plan, records | Light | Discuss why, decide next time |
| Red team | What's wrong with this? | Check | The plan | Light–Med | Answer the top objections |
The selector bot brief
You are choosing an analysis tool. Do not run a tool yet.
Job: [description]. What's at stake: [money / customers / safety / legal / internal only].
Inputs available: [list files and data].
1. Name the situation from the "Step 1" table that fits best. If two fit, say both.
2. Set the rigor: Light, Medium or Heavy, using these rules: one-way door or
severe harm = Heavy; customer, money or other teams = Medium; else Light.
Severity overrides size. A recent change to the model or skills raises it one tier.
3. Check inputs against "Step 3". If a data tool's data is missing, say what to
collect, or choose a judgment tool and label results as judgment.
4. Recommend the smallest set of tools that answers the question: usually one,
at most three, in order. For each: why it fits, inputs it will use, what a
person must do.
5. Say which tools you considered and rejected, in one line each.
6. Always include the lessons-learned search for new work.
For Heavy jobs, a person confirms the tool choice before you start.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
Where bots differ
People tend to under-analyze, because analysis is slow. Bots tend to over-analyze, because it's cheap and they were asked to be thorough. Both are waste. The selector's job is to pick the smallest tool that answers the question, and stop.
Bots also like tools that produce big, impressive tables. A three-line pre-mortem that finds the real risk beats a hundred-row FMEA nobody reads. See The analysis got cheap.
What this means for you
- Put the selector brief at the top of any analysis skill.
- Ask "what's the question?" before "which tool?"
- Match the rigor to what's at stake.
- Don't use a data tool without data.
- Start small. Add tools only when the first one leaves a real question open.