h-diagnose

name	h-diagnose
description	Diagnose a concrete failure with parallel rival-hypothesis testing. Use when symptoms are observable but cause is unclear. Stabilize the signal, generate distinct explanations, test them read-only in parallel, and rank by evidence while keeping losing rivals visible. This skill is independent and ordinarily non-persistent; save a diagnosis frame or hypothesis portfolio only on explicit request or when current Work supplies a concrete operator-named or agent-inferred receiving use that needs replay.
when_to_use	A test, runtime, data, integration, or operational failure has more than one plausible cause. For a feature or redesign question use h-frame.
argument-hint	[observed failure]
allowed-tools	Bash Read Grep Glob Agent mcp__haft__haft_problem mcp__haft__haft_solution mcp__haft__haft_query

h-diagnose — Test rival explanations

Abduction is an internal routine of this skill, not a separate public skill. Use FPF source when an FPF distinction or diagnostic pattern is material to the current failure; a purely mechanical failure needs no ritual source query. Before relying on FPF diagnostic semantics, inspect a known SourceID or UnitID with mcp__haft__haft_query(action="fpf", mode="inspect", identifier="..."), or use mode="concern" with the concrete failure question and inspect the direct pattern body. Query returns source candidates, not a selected cause or verdict. A candidate_set is incomplete: select by the current condition and required result kind, then inspect one exact PatternID. If no candidate fits, abstain. Never use a query performed after the diagnosis or edit as proof that the earlier work followed that source.

Conditional project-memory orientation

When this diagnosis is context-heavy, multi-session, or reliance-bearing and the exact EntityOfConcern is not already current, resolve its identity with haft_query(action="memory", memory_request={"mode":"resolve", "contract_version":"haft.memory.v1","basis":{"kind":"project_current"}, "query":"...","max_candidates":5}). Select the exact candidate by the current use rather than rank, then use the closed memory_request neighborhood branch advertised by the tool schema with projection_profile_ref="agent_orientation.v2".

Inspect result_kind before relying on content. project_basis_unavailable, known absence, or explicit abstention is visible but non-blocking: continue the diagnosis without inventing a profile, entity, artifact, or human gate. This read does not replace code-graph preflight before a later code edit. Never persist typed memory merely because a read failed; persistence requires an explicit operator save request or a concrete operator-named or agent-inferred receiving use supplied by current Work, with provenance.

Procedure

1. Stabilize the observed signal without naming a cause. State time window, scope, reproducibility, and what remains unaffected.
2. Inspect the failing code, logs, tests, and related Haft decisions when they are current. Treat stale governing assumptions as one possible hypothesis, not as proof.
3. Generate at least three rival hypotheses that differ in kind. For each, state a discriminating probe that could refute it.
4. Run read-only probes in parallel where possible. Give each investigator one hypothesis and the same signal; prohibit edits.
5. Rank by evidence for, evidence against, and remaining uncertainty. Keep refuted and inconclusive rivals visible when they matter to fallback or replay.
6. State the smallest supported conclusion. Inconclusive is valid; a plausible story is not a root-cause finding.

Persistence boundary

Default to a conversational diagnosis. Do not automatically create a ProblemCard or SolutionPortfolio. Persist only on explicit save intent or when a concrete operator-named or agent-inferred receiving use needs the diagnosis to remain addressable. In that case, record the stable diagnosis problem and the rival hypotheses with their evidence limits; do not present hypothesis ranking as a binding decision.

Result

Return the leading explanation, concrete evidence, live rivals, and the next discriminating probe if uncertainty remains. Diagnosis does not authorize a fix. Implement only when the operator separately asks for the change.