silent-failures

/silent-failures — audit error handling for hidden failures

Delegate the audit to the silent-failure-hunter subagent. The subagent runs the methodology in isolation and returns severity-ranked findings. The findings are for your grounding — synthesize before surfacing anything to the user.

How to delegate

Use the Agent tool with subagent_type="silent-failures:silent-failure-hunter" — plugin agents are namespaced by plugin name. Pass the diff or specific files under review (default: git diff of unstaged + staged changes). The subagent returns severity-ranked findings.

How to handle the findings

Findings are for you, not the user. Default handling by severity:

• CRITICAL (silent failure, broad/empty catch, mock-in-production) — fix immediately if mid-implementation, or surface for the user to decide
• HIGH (poor user message, unjustified fallback, missing propagation) — surface concisely with your recommendation
• MEDIUM (missing context, could be more specific) — absorb silently unless several cluster around the same code

Don't paste the subagent's full report. Synthesize what's actionable.

After the review

• If you fixed issues mid-implementation: briefly note what was fixed
• If nothing actionable: "Audited error handling. No issues."
• If user input is needed: present the issues concisely with recommendations, not as a wall

Common pitfalls

• Pasting the full subagent report — defeats the isolation. Synthesize.
• Treating every finding as user-facing — most MEDIUM findings are nits; absorb silently.
• Skipping because "the diff looks fine" — the subagent's job is to catch what looks fine but isn't.
• Findings without recommendation — surfacing raw findings forces the user to do the synthesis. Always pair an issue with a concrete suggested fix.