What this prompt does
This prompt builds a weighted decision matrix to help you choose between [options] for a specific [purpose]. Rather than an opinionated "use X," it forces a defensible process: weight each criterion in [criteria] from 1-5, score every option 1-10 with justification, compute a weighted total, and then layer on pros/cons, ecosystem data, learning curve, long-term viability, migration cost, total cost of ownership, and a final recommendation with a confidence level and risk-mitigation plan.
The structure works because it separates what you value (the weights) from how each option performs (the scores), which is exactly the distinction that survives a stakeholder review. The [team_size] and [team_experience] placeholders pull human factors into the math, and [current_stack] forces an honest migration-cost line so the shiny option does not win on raw features alone. The output is reproducible: change a weight and the recommendation can flip transparently.
When to use it
- Choosing a framework, database, or language for a new project that stakeholders will question.
- Comparing
[options]where the "best" choice depends on your team, not just benchmarks. - Documenting a technical decision so future you (or an auditor) can see the reasoning.
- Settling a team debate with scores and weights instead of loudest-voice-wins.
- Estimating the real cost of migrating off your
[current_stack]. - Pressure-testing a gut choice before committing budget to it.
Example output
You get a scored decision matrix: a table of [criteria] rows against [options] columns, each cell holding a 1-10 score plus a one-line justification, with a weighted total per option at the bottom. Around it sit pros/cons lists, an ecosystem comparison (stars, downloads, Stack Overflow activity), a learning-curve note for your team, viability and migration-cost sections, a TCO estimate, and a final recommendation with a stated confidence level.
Pro tips
- Set the weights in
[criteria]before you look at scores, so you don't unconsciously tune them to your preferred option. - Make
[team_experience]honest; a SvelteKit win is hollow if your team is[team_experience]and would ramp slowly. - Treat the ecosystem numbers as directional, not gospel; ask the model to flag which figures it is estimating versus recalling.
- Always fill
[current_stack]even for greenfield-adjacent work, since migration cost often decides ties. - Re-run with adjusted weights to see how fragile the recommendation is; a result that survives reweighting is one you can defend.
- Use the confidence level as a prompt to gather more data, not as a final verdict.
