whylisted

# Why The user typed `/why`. They just got a recommendation from you — a library, an approach, a file layout, a fix, a tradeoff call — and want a quick, honest, well-rounded look at it: why it matters, the real reasoning, and, critically, what it might be missing. They can already see the recommendation. Don't re-explain the conversation. Explain and pressure-test the *pick*. **Trigger:** this skill runs ONLY on the explicit `/why` command. The word "why" used normally in conversation is not a trigger — never fire on it. **Lightweight by design.** This is not `/impartial-review` (no five-bucket panel, no broad audit). But a model reviewing its *own* previous turn tends to rubber-stamp — same blind spots, same biases. So `/why` borrows exactly one trick from real review: a single fresh subagent with no memory of this session, to get genuine distance on the weak spots. Everything else you do yourself, fast. ## Step 1: Lock onto what's being reviewed - **Default: the assistant message directly before the user's `/why`** — your own immediately-preceding turn. That's the recommendation they're reacting to. Don't scan further back unless that turn has nothing to review. - If the user passed an argument (`/why the caching approach`, `/why picking Wouter`), let it scope or redirect — they may mean a specific pick inside that previous turn, or an earlier one. Honor the argument over the default. - If that previous turn made **several** distinct recommendations and the argument do