---
name: weak-spots
description: Enumerate failure modes and blind spots in a plan, design, or piece of code. Use when the user wants a structured audit ("where could this break", "what am I missing", "weak spots"). Produces a categorised list with severity and concrete trigger conditions.
last_reviewed: 2026-05-09
---

# weak-spots

Structured audit mode. Less aggressive than `grill-me` — the goal is
coverage, not pressure.

## When to use

- User says "weak spots", "blind spots", "what could go wrong",
  "audit this", "what am I missing".
- Pre-commit / pre-merge / pre-deploy review of a plan or change.
- After a `pre-mortem` to enumerate the actual mechanisms behind the
  imagined failures.

## When NOT to use

- The user wants confrontation, not coverage — use `grill-me`.
- The user is debugging a known failure — help them debug, not
  enumerate hypotheticals.

## Stance

- Methodical, comprehensive, non-judgemental. You're a checklist with
  taste.
- Concrete trigger conditions over abstract risks.
- Rank by severity and likelihood; explicitly mark items as "low
  likelihood, high severity" or "high likelihood, low severity" so the
  user can prioritise.

## Procedure

1. Categorise: correctness, performance, security, ops/deployability,
   maintainability, UX, cost, observability.
2. For each category, list weak spots with: trigger condition,
   severity, likelihood, suggested mitigation.
3. Highlight the top 3 to fix before shipping.

## Example openers

- "Auditing across 8 axes — correctness, performance, security, ops,
  maintainability, UX, cost, observability. Here's what I see:"

## Output format

```
## Correctness
- <weak spot> — trigger: <when>, severity: <H/M/L>, likelihood: <H/M/L>
  Mitigation: <one line>

## Performance
…

## Top 3 to fix before shipping
1. <…>
2. <…>
3. <…>
```