360 Secure SkillHub
360 安全技能中心

thinking-five-whys-plus

该 Skill 用于故障已定位且近因已知、但系统性根因未明的情形。它要求逐步构建证据关联的 Why 链,分支候选原因,做反事实检验,遵守停止判据,并为每个保留根因给出对策与验证方式;不采集证据,也不执行修复。

tjboudreaux
tjboudreaux
热度 8.37
最近更新 2026-08-05 07:51:46
分类:数据依赖:纯提示词应用场景:调试排错 / 报告撰写 / 研究

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add thinking-five-whys-plus
Metadata
name
thinking-five-whys-plus
description
When a fault is localized and the proximate cause is known but the systemic root is not, chain evidence-linked whys with a counterfactual stop and a countermeasure.
disable-model-invocation
true

Five Whys Plus

Build an evidence-linked causal chain from a known proximate fault to an actionable systemic root, then prescribe a countermeasure that would have blocked it.

When to Use

  • A fault is already localized to a component, path, or subsystem.
  • The proximate cause is known, but recurrence or systemic root is not.
  • Prior symptom-only fixes failed and the failure returned.
  • You need prevention that addresses why the proximate cause was possible.

When NOT to Use

  • Fault is not localized or multiple candidate causes remain — discriminate first.
  • Root is evidenced and actionable — fix it.
  • No evidence can answer the next "why" — gather evidence.
  • One-off error without a process, tooling, or design enabler.
  • Selective defect needing IS/IS-NOT analysis.
  • Forward failure forecasting before commitment.

Procedure

  1. State the localized problem. Record the observable symptom, confirmed component/path, time window, scope, and impact. Stop if localization is missing.
  2. Chain why with evidence. Make the prior answer the new effect; propose a cause; cite logs, code, config, metrics, or witnesses; name and rule out alternatives. Stop on speculation.
  3. Branch before descending. Ask what else could produce the same effect; keep every evidenced independent pathway. Treat the retained branches as a causal set rather than forcing one root.
  4. Counterfactually test each pathway and the set. For each candidate ask, "Would removing this cause block this pathway?" Then ask, "Would removing the retained set block the observed failure?" Retain independently sufficient branches whose removal blocks their own pathway; do not reject them merely because another branch could still cause the failure.
  5. Enforce stop criteria per branch. Stop a branch only when its cause is evidenced, controllable, actionable, recurrence-preventing, non-blame (not merely "someone erred"), and counterfactual-positive for that pathway. If it hits human error, ask why the error was possible.
  6. Prescribe a countermeasure for every retained root. Name the systemic fix, owner-capable action, and how recurrence will be checked. Prefer removing enabling conditions over only patching the proximate symptom.
  7. Stop when verified or blocked. Halt when stop criteria pass and a countermeasure is specified, or when further steps lack evidence. Do not pad by habit.

Output

Problem: <localized symptom + component>
Chain:
  Why1: <cause> | Evidence: <...> | Ruled out: <...>
  WhyN: ...
Causal set check: would removing all retained roots block the failure? yes/no
Roots:
  - <systemic cause> | Pathway counterfactual: <...>
    Countermeasure: <action that removes the enabling condition>
    Verification: <how to confirm this pathway is blocked>

Verification

  • Falsify the chain if any step lacks evidence, if alternatives were never considered, if a retained root does not pass its pathway counterfactual, or if the full causal set does not explain the failure.
  • Stop applying this skill once the root is fixed and verified, or when the problem is still pre-localization.
  • Over-application guard: skip a full chain for a single known one-line defect; do not end at blame; do not invent depth without data.