Help us improve
Share bugs, ideas, or general feedback.
From eou-foundry
Diagnose an EOU failure using the F-code taxonomy and recommend the smallest-blast-radius repair, producing either a diagnosis or a no-change record.
npx claudepluginhub xiaolai/eou-foundry --plugin eou-foundryHow this skill is triggered — by the user, by Claude, or both
Slash command
/eou-foundry:eou-diagnose INCIDENT_OR_AUDIT_PATHINCIDENT_OR_AUDIT_PATHtargetThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Diagnose the failure described in `$target` and recommend the minimum repair path.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Diagnose the failure described in $target and recommend the minimum repair path.
$target (required) — path to an incident report or audit finding. Accepted paths: foundry/audits/incidents/{id}.yml, foundry/audits/eou-audits/{id}.audit.yml, or any structured YAML file containing an observable failure symptom.foundry/failure-taxonomy.yml — F1–F12 class definitions and repair heuristicsfoundry/constitution.yml — invariants that constrain repair optionsschemas/incident.schema.yml — validate the input incident report against this schema if it is a structured YAML fileHalt and request clarification if:
$target does not identify an EOU ID and one cannot be inferred from the content.foundry/failure-taxonomy.yml does not exist — failure classification cannot proceed without it.$target (incident report or audit finding) and extract the observable failure symptom.Every diagnosis produces one of two outcomes:
$ecp-propose to open an ECP.foundry/audits/incidents/{incident_id}.no-change.yml with fields: incident_id, eou_id, diagnosis_summary, decision: no_change, rationale, reviewed_by, reviewed_at, reopen_condition.A no-change record is not a failure of the diagnosis process. It is evidence that the system reviewed and rejected a change rather than silently ignoring the incident.
Write the diagnosis report to foundry/audits/incidents/{incident_id}.diagnosis.yml with the following structure:
incident_id: # from $target or generated
eou_id: # EOU under diagnosis
failure_classes: # list of F-codes with confidence (high/medium/low)
symptoms: # observable signals that led to each classification
repair_options: # ordered list, smallest blast radius first
- repair_type: # schema_field | validator | stop_condition | regression_case | context_manifest | ecp | human_gate | eou_lifecycle
description: # one sentence — what changes
blast_radius: # narrow | medium | wide
requires_ecp: # true | false
recommended: # index into repair_options of the recommended minimum fix
rationale: # why that fix and not the next one up
incident_id — use the one from $target or generate from {eou_id}-{YYYYMMDD} if absent.high/medium/low) for failure class matches must be grounded in observable signals, not subjective judgment.Upstream: receives incident reports (foundry/incidents/) or audit failures (foundry/audits/eou-audits/).
Downstream: dual outcome — decision: change produces a diagnosis fed to $ecp-propose; decision: no_change produces a no-change record under foundry/audits/incidents/.
Related: $eou-refactor (sibling — also a path to ECP from audit findings, but produces structural options rather than F-code classification); $generate-regression-cases (sibling — converts incidents to durable test memory).
Pipeline: incident | audit failure → eou-diagnose → (change) ecp-propose | (no_change) no-change record