Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →notque/decision-helper
Weighted decision scoring for architectural choices.
Passed 20 of 22 test cases with the skill, and 8 of 22 without it.
and 18 more in the full report
13 fixed7 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
After completing a weighted decision analysis for an authentication service, what exact bash command is executed to check if an active Architecture Decision Record session exists?
| Checked | Without skill | With skill |
|---|---|---|
| Executes cat .adr-session.json 2>/dev/null to check for active ADR session | Missed | Passed |
The instructions your model reads when the skill loads.
Structured weighted scoring for architectural and technology choices. Runs inline (no context fork) because users adjust criteria and weights interactively.
Goal: Turn the user's question into a clear, scorable decision.
If the user's request is too vague to frame, ask clarifying questions. Do not guess at options. If someone invoked this skill, the decision is not obvious -- run the full framework even when a quick answer feels tempting.
Gate: Decision statement defined, 2-4 options listed, hard constraints applied.
Goal: Establish what matters for this decision and how much.
Present the default criteria table unless the user provides custom criteria. Ask if they want to adjust weights or add/remove criteria.
| Criterion | Weight | What It Measures |
|---|---|---|
| Correctness | 5 | Does it solve the actual problem? |
| Complexity | 3 | How much complexity does it add? (lower = better) |
| Maintainability | 3 | How easy to change/debug later? |
| Risk | 3 | What can go wrong? How bad is the failure mode? |
| Effort | 2 | Implementation time and difficulty |
| Familiarity | 2 | Team/user comfort with this approach |
| Ecosystem | 1 | Library support, documentation, community |
WHY these defaults: Correctness dominates because a wrong solution has zero value regardless of other factors. Complexity/Maintainability/Risk form a middle tier because they determine long-term cost. Effort/Familiarity are lower because they're temporary (teams learn, effort is one-time). Ecosystem is lowest because it rarely decides between otherwise-equal options.
Use defaults unless the user has a strong reason to change them. Agonizing over whether Complexity should be weight 3 or 4 rarely changes the outcome -- the framework exists to make decisions faster, not slower. Set weights before scoring; adjusting weights after seeing results to make a preferred option win is confirmation bias with extra steps.
If the user wants sensitivity analysis, re-score with adjusted weights after the initial pass to test recommendation stability.
test cases passed, vs 8 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.