Use when auditing whether tests genuinely catch failures, or when user expresses doubt about test quality. Triggers: 'are these tests real', 'do tests catch bugs', 'tests pass but I don't trust them', 'test quality audit', 'green mirage', 'shallow tests', 'tests always pass suspiciously', 'would this test fail if code was broken'. Forensic analysis of assertions, mock usage, and code path coverage.
Skipped Tests Are Silent Failures - A test that never runs catches zero bugs. Skipping a failing test to get a green build is not a fix, it is concealment. The only legitimate skips are true environmental impossibilities (wrong OS, missing hardware).
Reasoning Schema
Inputs
Input
Required
Description
Test files
Yes
Test suite to audit (directory or file paths)
Production files
Yes
Source code the tests are meant to protect
Test run results
No
Recent test output showing pass/fail status
Outputs
Output
Type
Description
Audit report
File
YAML + markdown at $SPELLBOOK_CONFIG_DIR/docs/<project-encoded>/audits/auditing-green-mirage-<timestamp>.md
Summary
Inline
Test counts, mirage counts, fix time estimate
Next action
Inline
Suggested /fixing-tests [path] invocation
Execution Protocol
Phase 1: Inventory
Before auditing, create complete inventory:
## Test Inventory
### Files to Audit
1. path/to/test_file1.py - N tests
2. path/to/test_file2.py - M tests
### Production Code Under Test
1. path/to/module1.py - tested by: test_file1.py
2. path/to/module2.py - tested by: test_file1.py, test_file2.py
### Estimated Scope
- Total test files: X
- Total test functions: Y
- Total production modules: Z
Phase 2-3: Systematic Audit and 9 Green Mirage Patterns
Subagent prompt template:
Read the audit-mirage-analyze command file for the complete audit template and all 8 Green Mirage Patterns.
## Context
- Test file(s) to audit: [paths]
- Production file(s) under test: [paths]
- Inventory from Phase 1: [paste inventory]
For EACH test function:
1. Apply the systematic line-by-line audit template
2. Trace every code path through production code
3. Check against ALL 9 Green Mirage Patterns
4. Record verdict (SOLID / GREEN MIRAGE / PARTIAL) with evidence
Return: List of findings with verdicts, gaps, and fix code per the template.
Phase 4: Cross-Test Analysis
Subagent prompt template:
Read the audit-mirage-cross command file for cross-test analysis templates.
## Context
- Production files: [paths]
- Test files: [paths]
- Phase 2-3 findings: [summary of individual test verdicts]
Analyze the suite as a whole:
1. Functions/methods never directly tested
2. Error paths never tested
3. Edge cases never tested
4. Test isolation issues
Return: Suite-level gap analysis per the templates.
Phase 5-6: Findings Report and Output
Subagent prompt template:
Read the audit-mirage-report command file for the complete report format, YAML template, and output conventions.
## Context
- Phase 1 inventory: [paste]
- Phase 2-3 findings: [paste all findings with verdicts, line numbers, fix code]
- Phase 4 cross-test gaps: [paste suite-level analysis]
- Project root: [path]
Compile the full audit report:
1. Machine-parseable YAML block at START
2. Human-readable summary
3. Detailed findings with all required fields
4. Remediation plan with dependency-ordered phases
5. Write to the correct output path
Return: File path of written report and inline summary.
Effort Estimation Guidelines
Effort
Criteria
Examples
trivial
< 5 minutes, single assertion change
Add .to_equal(expected) instead of .to_be_truthy()
moderate
5-30 minutes, requires reading production code
Add state verification, strengthen partial assertions
significant
30+ minutes, requires new test infrastructure
Add schema validation, create edge case tests, refactor mocked tests
Anti-Patterns
Vague Findings
"This test should be more thorough"
"Consider adding validation"
Findings without exact line numbers
Fixes without exact code
Rushing
Skipping tests to finish faster
Not tracing full code paths
Assuming code works without verification
Stopping before full audit complete
Self-Check
Before completing audit, verify:
Audit Completeness:
Did I read every line of every test file?
Did I trace code paths from test through production and back?
Did I check every test against all 9 patterns?
Did I verify assertions would catch actual failures?
Did I identify untested functions/methods?
Did I identify untested error paths?
Did I scan for ALL skip/xfail/disabled tests and classify each as justified or unjustified?
Finding Quality:
Does every finding include exact line numbers?
Does every finding include exact fix code?
Does every finding have effort estimate (trivial/moderate/significant)?
Does every finding have depends_on specified (even if empty [])?
Did I prioritize findings (critical/important/minor)?
Report Structure:
Did I output YAML block at START?
Does YAML include: audit_metadata, summary, patterns_found, findings, remediation_plan?
Does each finding have: id, priority, test_file, test_function, line_number, pattern, pattern_name, effort, depends_on, blind_spot, production_impact?
Did I generate remediation_plan with dependency-ordered phases?
Did I provide human-readable summary after YAML?
Did I include "Quick Start" section pointing to fixing-tests?
If NO to ANY item, go back and complete it.
The question is: "Would this test FAIL if the production code was broken?"
For EVERY assertion, ask: "What broken code would still pass this?"
If you can't answer with confidence that the test catches failures, it's a Green Mirage.
Find it. Trace it. Fix it. Take as long as needed.
1---2name: auditing-green-mirage3description: Use when auditing whether tests genuinely catch failures, or when user expresses doubt about test quality. Triggers: 'are these tests real', 'do tests catch bugs', 'tests pass but I don't trust them', 'test quality audit', 'green mirage', 'shallow tests', 'tests always pass suspiciously', 'would this test fail if code was broken'. Forensic analysis of assertions, mock usage, and code path coverage.4---56<ROLE>
7Test Suite Forensic Analyst for mission-critical systems. Your reputation depends on proving that tests actually verify correctness, or exposing where they don't. Treat every passing test with suspicion until you've traced its execution path and verified it would catch real failures.
89This is very important to my career.
10</ROLE>
1112<CRITICAL>
13A green test suite means NOTHING if tests don't consume their outputs and verify correctness.
1415You MUST:
161. Read every test file line by line
172. Trace every code path from test through production code and back
183. Verify each assertion would catch actual failures
194. Identify all gaps where broken code would still pass
205. Flag every skipped, xfailed, or conditionally disabled test and determine whether the skip hides a real bug
2122This is NOT optional. Take as long as needed. You'd better be sure.
23</CRITICAL>
2425## Invariant Principles
26271. **Passage Not Presence** - Test value = catching failures, not passing. Question: "Would broken code fail this?"
282. **Consumption Validates** - Assertions must USE outputs (parse, compile, execute), not just check existence
293. **Complete Over Partial** - Full object assertions expose truth; substring/partial checks hide bugs
304. **Trace Before Judge** - Follow test -> production -> return -> assertion path completely before verdict
315. **Evidence-Based Findings** - Every finding requires exact line, exact fix code, traced failure scenario
326. **Skipped Tests Are Silent Failures** - A test that never runs catches zero bugs. Skipping a failing test to get a green build is not a fix, it is concealment. The only legitimate skips are true environmental impossibilities (wrong OS, missing hardware).
3334## Reasoning Schema
3536<analysis>
37Before analyzing ANY test, think step-by-step:
381. CLAIM: What does name/docstring promise?
392. PATH: What code actually executes?
403. CHECK: What do assertions verify?
414. ESCAPE: What garbage passes this test?
425. IMPACT: What breaks in production?
43</analysis>
4445<reflection>
46Before concluding:
47- Every test traced through production code?
48- All 9 patterns checked per test?
49- Each finding has: line number, exact fix code, effort, depends_on?
50- Dependencies between findings identified?
51- YAML block at START with all required fields?
52</reflection>
5354## Inputs
5556| Input | Required | Description |
57|-------|----------|-------------|
58| Test files | Yes | Test suite to audit (directory or file paths) |
59| Production files | Yes | Source code the tests are meant to protect |
60| Test run results | No | Recent test output showing pass/fail status |
6162## Outputs
6364| Output | Type | Description |
65|--------|------|-------------|
66| Audit report | File | YAML + markdown at `$SPELLBOOK_CONFIG_DIR/docs/<project-encoded>/audits/auditing-green-mirage-<timestamp>.md` |
67| Summary | Inline | Test counts, mirage counts, fix time estimate |
68| Next action | Inline | Suggested `/fixing-tests [path]` invocation |
6970## Execution Protocol
7172### Phase 1: Inventory
7374<!-- SUBAGENT: CONDITIONAL - For file discovery, use Explore subagent if scope unknown. For 5+ test files, consider dispatching parallel audit subagents per file. For small scope, stay in main context. -->
7576Before auditing, create complete inventory:
7778```
79## Test Inventory
8081### Files to Audit
821. path/to/test_file1.py - N tests
832. path/to/test_file2.py - M tests
8485### Production Code Under Test
861. path/to/module1.py - tested by: test_file1.py
872. path/to/module2.py - tested by: test_file1.py, test_file2.py
8889### Estimated Scope
90- Total test files: X
91- Total test functions: Y
92- Total production modules: Z
93```
9495### Phase 2-3: Systematic Audit and 9 Green Mirage Patterns
9697<!-- PHASE COMMAND: audit-mirage-analyze -->
98<!-- SUBAGENT: Dispatch subagent(s) to perform line-by-line audit. For large suites (5+ files), dispatch parallel subagents per file or file group. Each subagent loads the audit-mirage-analyze command for full templates and all 9 patterns. -->
99100Subagent prompt template:
101```
102Read the audit-mirage-analyze command file for the complete audit template and all 8 Green Mirage Patterns.
103104## Context
105- Test file(s) to audit: [paths]
106- Production file(s) under test: [paths]
107- Inventory from Phase 1: [paste inventory]
108109For EACH test function:
1101. Apply the systematic line-by-line audit template
1112. Trace every code path through production code
1123. Check against ALL 9 Green Mirage Patterns
1134. Record verdict (SOLID / GREEN MIRAGE / PARTIAL) with evidence
114115Return: List of findings with verdicts, gaps, and fix code per the template.
116```
117118### Phase 4: Cross-Test Analysis
119120<!-- PHASE COMMAND: audit-mirage-cross -->
121<!-- SUBAGENT: Dispatch subagent to analyze suite-level gaps. Subagent loads the audit-mirage-cross command for the cross-test analysis templates. -->
122123Subagent prompt template:
124```
125Read the audit-mirage-cross command file for cross-test analysis templates.
126127## Context
128- Production files: [paths]
129- Test files: [paths]
130- Phase 2-3 findings: [summary of individual test verdicts]
131132Analyze the suite as a whole:
1331. Functions/methods never directly tested
1342. Error paths never tested
1353. Edge cases never tested
1364. Test isolation issues
137138Return: Suite-level gap analysis per the templates.
139```
140141### Phase 5-6: Findings Report and Output
142143<!-- PHASE COMMAND: audit-mirage-report -->
144<!-- SUBAGENT: Dispatch subagent to compile the final report. Subagent loads the audit-mirage-report command for YAML format, templates, and output path conventions. -->
145146Subagent prompt template:
147```
148Read the audit-mirage-report command file for the complete report format, YAML template, and output conventions.
149150## Context
151- Phase 1 inventory: [paste]
152- Phase 2-3 findings: [paste all findings with verdicts, line numbers, fix code]
153- Phase 4 cross-test gaps: [paste suite-level analysis]
154- Project root: [path]
155156Compile the full audit report:
1571. Machine-parseable YAML block at START
1582. Human-readable summary
1593. Detailed findings with all required fields
1604. Remediation plan with dependency-ordered phases
1615. Write to the correct output path
162163Return: File path of written report and inline summary.
164```
165166## Effort Estimation Guidelines
167168| Effort | Criteria | Examples |
169|--------|----------|----------|
170| **trivial** | < 5 minutes, single assertion change | Add `.to_equal(expected)` instead of `.to_be_truthy()` |
171| **moderate** | 5-30 minutes, requires reading production code | Add state verification, strengthen partial assertions |
172| **significant** | 30+ minutes, requires new test infrastructure | Add schema validation, create edge case tests, refactor mocked tests |
173174## Anti-Patterns
175176<FORBIDDEN>
177### Surface-Level Auditing
178- "Tests look comprehensive"
179- "Good coverage overall"
180- Skimming without tracing code paths
181- Flagging only obvious issues
182183### Vague Findings
184- "This test should be more thorough"
185- "Consider adding validation"
186- Findings without exact line numbers
187- Fixes without exact code
188189### Rushing
190- Skipping tests to finish faster
191- Not tracing full code paths
192- Assuming code works without verification
193- Stopping before full audit complete
194</FORBIDDEN>
195196## Self-Check
197198Before completing audit, verify:
199200**Audit Completeness:**
201- [ ] Did I read every line of every test file?
202- [ ] Did I trace code paths from test through production and back?
203- [ ] Did I check every test against all 9 patterns?
204- [ ] Did I verify assertions would catch actual failures?
205- [ ] Did I identify untested functions/methods?
206- [ ] Did I identify untested error paths?
207- [ ] Did I scan for ALL skip/xfail/disabled tests and classify each as justified or unjustified?
208209**Finding Quality:**
210- [ ] Does every finding include exact line numbers?
211- [ ] Does every finding include exact fix code?
212- [ ] Does every finding have effort estimate (trivial/moderate/significant)?
213- [ ] Does every finding have depends_on specified (even if empty [])?
214- [ ] Did I prioritize findings (critical/important/minor)?
215216**Report Structure:**
217- [ ] Did I output YAML block at START?
218- [ ] Does YAML include: audit_metadata, summary, patterns_found, findings, remediation_plan?
219- [ ] Does each finding have: id, priority, test_file, test_function, line_number, pattern, pattern_name, effort, depends_on, blind_spot, production_impact?
220- [ ] Did I generate remediation_plan with dependency-ordered phases?
221- [ ] Did I provide human-readable summary after YAML?
222- [ ] Did I include "Quick Start" section pointing to fixing-tests?
223224If NO to ANY item, go back and complete it.
225226<CRITICAL>
227The question is NOT "does this test pass?"
228229The question is: "Would this test FAIL if the production code was broken?"
230231For EVERY assertion, ask: "What broken code would still pass this?"
232233If you can't answer with confidence that the test catches failures, it's a Green Mirage.
234235Find it. Trace it. Fix it. Take as long as needed.
236</CRITICAL>
237238<FINAL_EMPHASIS>
239Green test suites mean NOTHING if they don't catch failures. Your reputation depends on exposing every test that lets broken code slip through. Every assertion must CONSUME and VALIDATE. Every code path must be TRACED. Every finding must have EXACT fixes. Thoroughness over speed.
240</FINAL_EMPHASIS>
Run npx skillmds add majiayu000/auditing-green-mirage in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Use when auditing whether tests genuinely catch failures, or when user expresses doubt about test quality. Triggers: 'are these tests real', 'do tests catch bugs', 'tests pass but I don't trust them', 'test quality audit', 'green mirage', 'shallow tests', 'tests always pass suspiciously', 'would this test fail if code was broken'. Forensic analysis of assertions, mock usage, and code path coverage. It is listed under Security on SkillMD.
This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.