agentsclimarketplace

Eou diagnose

Skill xiaolai/eou-foundry/skills/eou-diagnose

Diagnose an EOU failure using the F-code taxonomy and recommend the smallest-blast-radius repair, producing either a diagnosis (path to $ecp-propose) or a no-change record. <example> Context: An incident has been filed; owner wants a structured diagnosis before deciding whether to open an ECP. user: "$eou-diagnose foundry/incidents/inc-0042.yml" assistant: "I'll classify the failure under one or more F-codes, rank repair options by blast radius, and emit either a diagnosis YAML (decision: change) or a no-change record under foundry/audits/incidents/." </example> <example> Context: User wants to diagnose from an audit finding rather than a full incident. user: "$eou-diagnose foundry/audits/eou-audits/eou-promote.audit.yml" assistant: "I'll diagnose the audit's findings; if evidence is insufficient for a change, I'll write a no-change record explicitly rather than silently doing nothing." </example>From its SKILL.md

Install
npx -y skills add xiaolai/eou-foundry --skill eou-diagnose

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

5.3 KB, as published. Nobody here has run it

Diagnose EOU Failure

Diagnose the failure described in $target and recommend the minimum repair path.

Inputs

  • $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.

Required reading

  1. foundry/failure-taxonomy.yml — F1–F12 class definitions and repair heuristics
  2. foundry/constitution.yml — invariants that constrain repair options
  3. schemas/incident.schema.yml — validate the input incident report against this schema if it is a structured YAML file

Stop conditions

Halt and request clarification if:

  • $target does not identify an EOU ID and one cannot be inferred from the content.
  • The incident report contains no observable failure symptom — only a conclusion or label.
  • foundry/failure-taxonomy.yml does not exist — failure classification cannot proceed without it.

Procedure

  1. Read $target (incident report or audit finding) and extract the observable failure symptom.
  2. For each symptom, classify it against the F1–F12 taxonomy. One symptom may match multiple classes — list all that apply, ranked by confidence.
  3. For each classified failure, identify the minimum repair action using this precedence (smallest blast radius first):
    • schema field addition or constraint
    • validator strengthening
    • stop condition
    • regression case
    • context manifest repair
    • ECP (structural EOU change)
    • human approval gate
    • EOU split / merge / retire
  4. Rule out prompt-only explanations: if the failure recurs despite correct inputs, classify as structural (F3–F12), not F1 (prompt ambiguity).
  5. Write the diagnosis report.

Output

Every diagnosis produces one of two outcomes:

  • Change warranted — write the diagnosis report, then use $ecp-propose to open an ECP.
  • No change warranted — write a no-change record to 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

Constraints

  • Do not treat every failure as a prompt problem (F1). Require observable evidence for F1 classification.
  • Do not recommend retirement without evidence that the EOU's operational value is gone.
  • Do not recommend ECP when a stop condition or validator would suffice.
  • Do not invent an incident_id — use the one from $target or generate from {eou_id}-{YYYYMMDD} if absent.
  • Confidence ratings (high/medium/low) for failure class matches must be grounded in observable signals, not subjective judgment.

Scope Note

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

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.