Use when: Brainstorming, prioritizing, and documenting technical fault hypotheses and fault trees based on symptoms, measurements, and functional blocks. Creates a ranked list of probable failure causes with verification paths. Fehlerhypothesen, Fehlerursachen, Fehleranalyse, Priorisierung, Fehlersuche, fault tree, root cause analysis.
Use when: Brainstorming, prioritizing, and documenting technical fault hypotheses and fault trees based on symptoms, measurements, and functional blocks. Creates a ranked list of probable failure causes with verification paths. Fehlerhypothesen, Fehlerursachen, Fehleranalyse, Priorisierung, Fehlersuche, fault tree, root cause analysis.
<skill_purpose>
Generates a structured, prioritized list of failure hypotheses based on symptoms, observed evidence, and functional block knowledge. Guides the technician toward the highest-value diagnostic action first.
</skill_purpose>
- Symptom description (e.g., "device turns off under load", "intermittent connection", "won't charge")
- Functional block map (from `functional_block_reconstruction` or equivalent)
- Component inventory (from `board_image_intake` or equivalent)
- Optional: Any prior measurements or observations to factor in
1. Interpret the reported symptoms from a purely technical viewpoint — separate the observable symptom from the inferred cause.
2. Compare mechanical failure modes (cracks, contact resistance, lifted pads) with electrical modes (short, open circuit, degraded component).
3. Derive at least three verifiable fault hypotheses covering different failure classes.
4. Prioritize by: symptom match strength, typical failure probability for this component class, and required verification effort.
5. For each hypothesis, identify the single fastest confirming or disconfirming measurement.
<output_format>
Create or update analysis/04_fault_hypotheses.md (or the path specified by the user).
Per hypothesis, use this mandatory table format:
Hypothesis [N]: [Short descriptive title]
Field
Content
Technical mechanism
[How this failure mode produces the observed symptom]
Supporting evidence
[Observations / measurements that support this hypothesis]
Counter-evidence
[Observations that argue against this hypothesis]
Priority
[1 = highest priority to investigate]
Fastest verification
[Single measurement or visual check to confirm or refute]
Example (do not copy verbatim — adapt to the actual case):
Hypothesis 1: Cold solder joint at battery connector J1
Field
Content
Technical mechanism
Increased contact resistance under current load causes voltage drop → undervoltage shutdown
Supporting evidence
Intermittent symptom correlates with load [Symptom]; flux residue visible at J1 [Image]
Counter-evidence
No visible crack under normal-angle inspection
Priority
1
Fastest verification
Measure V_battery at cell terminals vs. V at circuit input pad simultaneously under load
Load-dependent voltage drop: battery internal resistance, trace resistance under current
Switch or discrete transistor failure: leakage, stuck open or closed
IC-level failure: assign only after discrete and mechanical causes are ruled out
Weight "intermittent" or "worse after shaking / flexing the board" symptoms strongly toward mechanical causes. Distinguish "voltage present at idle" from "voltage maintained under load" — these represent different fault classes requiring different measurements.
</prioritization_logic>
- Always compare at least three hypotheses — never conclude after the first plausible explanation.
- Assign Priority 1 to an IC failure only if simpler mechanical or discrete causes do not fit the symptom.
- Every hypothesis must have at least one verifiable measurement that can confirm or refute it.
- Cite evidence sources with tags: [Image], [Measurement], [Research], [Domain Knowledge].
