Compare design options
Compares two to four technical options against the criteria that matter, weighs reversibility and risk, and recommends one. Use when a team is stuck choosing between approaches or tools.
Teams lose weeks debating options in the abstract. A useful comparison fixes the criteria first, judges every option against the same criteria, separates hard constraints from preferences, and says what evidence would settle the remaining doubt. The result should be ready to turn into an architecture decision record.
Problem: Only if [OPTIONS] is given: Options: Only if [CRITERIA] is given: Criteria that matter, most important first: Only if [CONSTRAINTS] is given: Hard constraints:
- If no options were given, propose two or three realistic ones. Always consider keeping the current approach or doing nothing when that is viable.
- If no criteria were given, derive at most six from the problem and say that you derived them. Put hard constraints first: an option that breaks one is out, with the reason.
- Judge each option against each criterion as strong, adequate or weak, with a one-line reason specific to this problem.
- For each option, state how hard it is to reverse later (two-way door or one-way door), the biggest risk, and the cost of being wrong.
- Recommend one option. If the decision hinges on an unknown, recommend the cheapest experiment that would settle it and the option to pick if the experiment is not possible.
- Compare at most four options.
- No numeric scores or weighted sums unless the user supplied weights. Qualitative ratings with reasons are more honest than false precision.
- Do not invent benchmarks, prices, product limits or licence terms. When a choice depends on one, say what to check and where.
- Treat every option fairly: each gets its real strengths and real weaknesses, including the recommended one.
- Separate what you verified from what you inferred. Mark inferences as such.
- When you do not know, say "I don't know" once and state what would settle it.
Recommendation
Two to four lines: the option, the main reason, and the main cost of choosing it.
Criteria
Numbered, hard constraints first.
Comparison
Table: one row per criterion, one column per option, each cell "strong, adequate or weak: reason".
Options in detail
One short subsection per option: reversibility, biggest risk, cost of being wrong.
What would change the recommendation
Bullets: the facts or measurements that would flip it.
Open questions
Bullets, or "None".
1 required value still a placeholder; the assistant will ask for it.
details
- kind
- Prompt: a task you run by name to get one finished thing back
- domain
- Software engineering
- category
- Architecture
- level
- Intermediate
- made for
- Software architect, Tech lead / staff engineer, Software engineer, Engineering manager
- risk
- read-only
- version
- v1.0.0 · experimental
- reviewed
- 2026-10-02
- works in
- Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Antigravity, OpenCode, Windsurf, Zed, Continue, AGENTS.md, ChatGPT, claude.ai
use in
npx @hermes-hq/hodios install compare-design-options --target claude-codenpx skills add hermes-hq/hodios-dist --skill compare-design-options -a claude-codeclaude plugin marketplace add hermes-hq/hodios-distclaude plugin install hodios-software-engineering@hodiosThe plugin brings every entry in this domain at once.
pairs well with
All of ArchitectureSoftware architect
Acts as a pragmatic software architect who designs from requirements and constraints, names trade-offs and failure modes, and keeps designs as simple as the problem allows.
software-architectWrite an architecture decision record
Writes an architecture decision record that states one decision, the forces behind it, the options weighed and the honest consequences. Use when a significant technical choice is made or proposed.
write-adrDesign an API contract
Designs an API contract before implementation, with operations, schemas, errors, pagination, idempotency and evolution rules. Use when adding an API that other teams or clients will call.
design-api-contractReview a system design
Reviews a design document or proposal for failure modes, scaling limits, data and consistency risks and operability gaps, and returns ranked findings. Use before a design review or before building.
review-system-designWrite an engineering design doc
Writes an engineering design doc or RFC with context, goals and non-goals, options and trade-offs, the decision, risks and a rollout plan. Use before building a change that needs review or buy-in.
write-design-docAPI design track
Takes a new API from consumer needs to a resource model, a reviewed contract, error and versioning rules, and a mock with contract tests, pausing for approval between steps.
api-design-track