name: have-you-considered description: Surface alternatives — different ways to address the same need.
Open doors, don't fix bugs. This skill suggests what could be different, not what is wrong.
Posture
"Have you considered..." is a mentor's question, not a reviewer's finding. The goal is to surface options the author may not have seen — a library that already does this, a simpler way to meet the user need, a different decomposition of the work.
This skill is orthogonal to review and validation. It doesn't judge correctness; it expands the solution space.
Scope
Applies to anything: specs, code, PRs, design docs, architecture, process. Invoked explicitly — not a default lens.
Domains
| Domain | Examples |
|---|---|
| Technique | Library that replaces custom code, pattern that simplifies structure, tool that automates manual step |
| Product | Different UX that addresses same user need, feature that already exists elsewhere, scope reduction that delivers 80% value at 20% cost |
| Process | Different work decomposition, alternative sequencing, team structure adjustment |
Workflow
1. UNDERSTAND THE INTENT
- What need is being addressed? (user need, technical constraint, business goal)
- What's the current approach?
- What are the implicit assumptions?
2. EXPLORE ALTERNATIVES (per subject)
- What else could address this need?
- What's already out there? (libraries, prior art, patterns)
- What would a different team try?
- If knowledge is insufficient → search (docs, GitHub, awesome-lists, Perplexity MCP)
3. FILTER
- Does the alternative have demonstrable net benefit?
- Is the benefit significant enough to warrant switching cost?
- **Does scope match project maturity?** (PoC → interface changes; production → extend existing patterns)
- Discard if: marginal gain, astronautics, solves different problem
4. OUTPUT (one suggestion per subject)
- The alternative
- The demonstrable benefit (quantified when possible)
- The cost/risk to adopt
- Why it fits this specific context
Demonstrable Benefit
Every suggestion must have a benefit that can be verified, not just asserted.
Demonstrable:
- "Library X has 12k stars, active maintenance, and handles edge cases you'd need to code yourself — see their test suite"
- "This approach removes 3 API calls from the critical path — latency drops from ~800ms to ~200ms"
- "Scope reduction: users need export, not necessarily Excel export — CSV covers 90% of reported use cases per support tickets"
Not demonstrable (don't suggest):
- "This pattern is more elegant"
- "Rust would be faster" (without profiling showing CPU-bound bottleneck)
- "Microservices would scale better" (without evidence of scaling need)
Research
When agent knowledge is insufficient:
- Search official documentation first
- GitHub (repos, issues, discussions)
- Awesome-lists for the domain
- Perplexity MCP for broader exploration
Cite sources. Don't suggest based on vague recall.
Output Format
Prose libre. One suggestion per subject identified in scope.
## [Subject: brief description]
**Current approach:** [what's being done or proposed]
**Have you considered:** [the alternative]
**Benefit:** [demonstrable gain — quantified if possible]
**Cost:** [switching effort, risks, tradeoffs]
**Fit:** [why this makes sense for this specific context]
**Sources:** [if research was needed]
Anti-Patterns
FORBIDDEN:
- Astronautics — Suggesting rewrites, new languages, or architectural overhauls without proportionate demonstrated need
- Solution seeking problem — Suggesting something interesting that doesn't address the actual need
- Familiarity bias — Suggesting what you know rather than what fits ("when you have a hammer...")
- Marginal gains — Suggesting alternatives with <20% improvement for non-trivial switching cost
- Unverified claims — "I think there's a library that..." → search first or don't suggest
ALLOWED:
- Suggesting the author's current approach is already good (no alternative needed)
- Suggesting not doing something ("have you considered dropping this requirement?")
- Suggesting research/spikes when uncertainty is high ("have you considered prototyping X before committing?")
Integration
- Standalone: Invoke explicitly on any artifact
- With code-review: Can follow a review to open horizons after correctness is established
- With spec work: Can precede implementation to explore solution space
- With architecture-review: Can surface alternatives during design phase
Not a replacement for any skill — a complement that expands options before or after validation.