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.

1. For each category, list weak spots with: trigger condition,

severity, likelihood, suggested mitigation.

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