research

# Research ## Operating principles (override YAGNI/KISS/DRY for this skill) Research is a deliverable, not a code change. The general "ship the smallest thing" rules **do not apply here**. For this skill: - **Be deep, not shallow.** Surface findings are useless - dig until you understand *why*, not just *what*. - **Evaluate multiple options.** Never recommend one approach without comparing at least 2–3 viable alternatives on the same criteria. A single-option report is a failure. - **Brutal honesty.** Call out tradeoffs, deprecation, weak maintainership, security holes, vendor lock-in, hidden costs. No marketing language. No hedging. - **Straight to the demand.** The user asked a specific question - answer *that* question completely before adding context. No filler, no padding, no recap of what they already know. - **Cover every angle the user implied.** If they ask "what's the best message queue", they implicitly want: throughput, durability, ops burden, language support, cost, lock-in. Address all of them. - **No premature simplification.** Long is fine if every section earns its place. Trim filler, never trim depth. ## Modes | Mode | When | Queries | Report scope | |---|---|---|---| | **default** | Standard technical research | up to 5 search calls | Full template below | | **`--deep`** | High-stakes decisions, multi-component architectures, security-critical choices | up to 12 search calls | Expanded comparison matrix, edge-case analysis, migration paths, failure mod...