Weak Spots

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. <…>