# Cige Failure Classification > Use immediately after any CIGE test run completes, pass or fail, before any repair. Classifies the outcome (infrastructure failure, outdated test logic, product defect, or false positive) and names which self-healing skill, if any, is allowed to act. - Skill: `vivekkrishna/cige-failure-classification` (Agent Skill) - Install (CLI): `npx skillmds@latest add vivekkrishna/cige-failure-classification` - Raw SKILL.md: https://api.skillmd.com/api/skills/vivekkrishna/cige-failure-classification/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: vivekkrishna (https://skillmd.com/u/vivekkrishna) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vivekkrishna/cige-failure-classification --- # CIGE: Failure Classification (Dispatcher) Use this skill immediately after any CIGE test run completes — pass or fail — and before any repair action is taken. It classifies the outcome and names which skill, if any, is allowed to act on it. Classification is not optional and not skippable: no agent may repair a test it has not been dispatched to. ## When to invoke - A test run just finished, regardless of result - You are deciding whether a "pass" was actually a false positive - You need to know which self-healing skill is allowed to touch a given failure For the CIGE format itself, see `cige-test-authoring`. This skill only decides what happens *after* a run. --- ## The Decision Flow This mirrors the CIGE runtime workflow: reveal minimal context → run execution with guardrails → classify → repair → replay → human review → commit. ``` Run execution with guardrails │ ▼ Failure? ──No──▶ False Positive? ──No──▶ Store evidence, mark pass │ │ Yes Yes │ │ ▼ ▼ Classify failure Dispatch to cige-stale-execution-repair │ (Mode B — guardrail strengthening) │ ┌────┼────────────────┐ ▼ ▼ ▼ Infra Outdated Product Fail Test Logic Defect │ │ │ ▼ ▼ ▼ cige- cige-stale- cige-product- environ execution- defect- ment- repair (Mode A) escalation recovery │ │ │ └────┴────────────────┘ │ ▼ Replay in isolated environment │ ▼ Human review and commit ``` A **false positive** — the run reports pass, but the pass doesn't hold up (a shortcut satisfied the letter of Execution without the evidence Guardrails actually require) — is checked even when there was no Failure. Don't skip this check just because the run looked clean. --- ## Classifying a Failure | Signal | Classification | Dispatch to | |---|---|---| | Execution fails before reaching the system under test (auth error, service unreachable, missing seed data, environment not bootstrapped) | Infrastructure Failure | `cige-environment-recovery` | | Execution steps fail mid-flow (element not found, endpoint 404, workflow step gone), but `specRef` confirms the intended outcome is still a valid product requirement | Outdated Test Logic | `cige-stale-execution-repair` (Mode A) | | Execution reached the system, environment is healthy, steps are current — but the outcome contradicts Intent | Product Defect | `cige-product-defect-escalation` (needs `specRef` *and* `buildRef` correlated — see that skill's Case B/D) | | Run reports pass, but the evidence backing that pass is weak or gameable (UI text alone, no backend confirmation, etc.) | False Positive | `cige-stale-execution-repair` (Mode B) | Classify by elimination in this order: check Infrastructure first (did execution even reach the system?), then Outdated Test Logic vs. Product Defect (does `specRef` still describe today's expected behavior?), and treat False Positive as a check on every apparent pass, not just failures. **Rule:** If you cannot confidently classify, do not guess and do not repair. Halt and surface the ambiguity — an unclassified failure routed to the wrong skill is exactly how a field-mutation boundary gets violated. --- ## Field Mutation Rules (master table) This is the single source of truth for which field each self-healing skill may write. Each agent skill restates only its own row — if you find a discrepancy, this table wins. | CIGE Field | `cige-environment-recovery` | `cige-stale-execution-repair` | `cige-product-defect-escalation` | |---|---|---|---| | `Context` | Read-only (uses to restore env) | Read-only | Read-only (uses `specRef`) | | `Intent` | Never touch | Never touch | May *propose* update — **human approval required** | | `Guardrails` | Never touch | May *add or strengthen* — **only** to repair a confirmed false positive, **never** loosen/remove, **human approval required** | Never touch | | `Execution[]` | Never touch | **Writes** (Mode A) — human approval required | Never touch | Two invariants hold regardless of classification: - No skill may modify `Intent` autonomously — `cige-product-defect-escalation` may only *propose*, and only under the supervised-intent-evolution sequence. - No skill may ever *loosen or remove* a Guardrail. The one write path to `Guardrails` is strictly additive, human-gated, and scoped to `cige-stale-execution-repair`'s Mode B. An agent that reaches outside its field boundaries has misclassified the failure — stop and reclassify, don't let the write happen. --- ## Run Summaries Every classification produces a short summary, whether or not a repair followed: ```json { "testId": "checkout-happy-path", "runDate": "2026-04-16", "result": "pass | fail | self-healed", "failedStep": "e3", "failureType": "outdated-test-logic | product-defect | infrastructure | false-positive", "recoveryAction": "StaleExecutionAgent updated e2, e3 — approved by human", "intentUnchanged": true } ``` Write this even for a clean pass (`failureType` omitted, `recoveryAction` omitted) — future runs read the summary history first to spot patterns (e.g. the same step repeatedly needing execution repair may itself be a signal worth escalating) before deciding whether to run the full test or investigate first. **Rule:** Never let a repair happen without this classification step first, and never let a dispatched skill run without this step having named it explicitly.