failure-classify
Skill0 starsChanged 37 days agoMITView on GitHub
Group failing tests by naming convention so a real assertion failure is not hidden among tests that exist to verify a system rejects something. Use after running the test suite and before reading the report.
In this repository11 other files it gives its agents.
- drift-checkSkill
- drillSkill
- failure-classifySkill
- init-loopSkill
- report-renderSkill
- test-loop-bootstrapSkill
- drift-checkSkill
- drillSkill
- init-loopSkill
- report-renderSkill
- test-loop-bootstrapSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
After every test run that produced at least one failing test.
- Distinctive: line 23
Before triaging a CI failure manually.
- Distinctive: line 26
Do not use this skill to decide whether a regression is "important enough to fix".
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
failure-classify
Triage failing tests so a real regression does not get lost among tests that are expected to fail (because they verify that the system rejects bad input).
When to use
- After every test run that produced at least one failing test.
- Before triaging a CI failure manually.
- In the report-render skill's input pipeline.
Do not use this skill to decide whether a regression is "important enough to fix". That is a human judgement. The skill only sorts.
Inputs
| Name | Required | Default | Description |
log_path | yes | none | Path to the test runner's output. The skill scans for ✘ lines (or FAIL lines, depending on the language pattern). |
language | no | swift | One of swift, python, go, rust. Picks the line-extraction regex and the classification patterns. |
self_test | no | false | When true, runs the skill's internal unit tests and exits. Use after editing the classification rules. |
Output
| Channel | Content |
| stdout | A JSON object with three keys: failures (deduplicated list of failing test names), failures_by_class (counts per class), failures_grouped (test names bucketed by class). |
| exit code | 0 on success regardless of test outcomes. 1 if the log could not be read. 2 on self-test failure. |
Classification taxonomy
Seven classes. Order matters: the first matching pattern wins. A test
name that matches no pattern falls into ASSERTION_FAILURE by default.
| Class | Meaning | Trigger keyword (regex fragment) |
EXPECTED_FAILURE | the test verifies the system rejects something | Reject, Refuse, ErrorContains, WithInvalid, DataCorrupted, InvalidDuration, LongSessionOnBattery |
IO_BACKEND | the test exercises a system API (IOKit, libusb, raw sockets) | language-specific prefix, e.g. powerAssertion* in Swift |
ENVIRONMENT_ERROR | the test depends on a live system reading | PowerSourceMonitor, BluetoothState, NetworkLink |
TEST_SCAFFOLD | the test depends on a missing setup artifact | reserved; no patterns in v0.1 |
ASSERTION_FAILURE | real bug | default bucket |
PRECONDITION_MISSING | required env var / file is missing | requireEnv, skipIf markers |
UNKNOWN | could not classify | fallback (rare; usually means the runner produced an unexpected line format) |
Algorithm
- Extract failing test names from the log. Swift Testing emits two
✘lines per failing test (one for the issue, one for the summary). The skill deduplicates while keeping the first-seen order. - Classify each name against the patterns, first-match-wins.
- Emit JSON: list, counts, grouped.
Worked example (Swift)
Log:
✔ Test foo() passed after 0.001 seconds.
✘ Test barRejectsZero() failed after 0.001 seconds with 1 issue.
✘ Test bazShouldBehave() failed after 0.001 seconds with 1 issue.Output:
{
"failures": ["barRejectsZero", "bazShouldBehave"],
"failures_by_class": {
"EXPECTED_FAILURE": 1,
"ASSERTION_FAILURE": 1
},
"failures_grouped": {
"EXPECTED_FAILURE": ["barRejectsZero"],
"ASSERTION_FAILURE": ["bazShouldBehave"]
}
}The first test is an expected-failure pattern (Rejects). The second
is a real regression candidate.
Anti-patterns
- Treating
EXPECTED_FAILUREas a green light. A failure classified asEXPECTED_FAILUREstill failed. The classification only means the failure is the test's purpose, not that the system under test behaves correctly. The test author must read the message. - Adding patterns that match everything. Patterns are first-match
wins. A pattern like
.*would swallow every test into one bucket. - Assuming a runner that is not in the language list still works. The v0.1 patterns cover Swift Testing only. For other runners, the user must extend the patterns and add a self-test.
Cross-references
- report-render — consumes the JSON output and embeds it in the Markdown report.
- drill — uses this skill to verify the loop reacts to a real failure.
- drift-check — the previous step in the loop.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

