Alternatives before code

Skill alinafe82/cognitive-deadlift/skills/alternatives-before-code

AI coding skills, hooks, and plugins that keep developers thinking instead of autopiloting

Install

npx -y skills add alinafe82/cognitive-deadlift --skill alternatives-before-code

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Compare viable solution paths before implementation. Use when architecture, refactors, data model changes, workflow changes, tool choices, or irreversible decisions make the first idea too sticky. NOT for one-line fixes, constrained chores, or changes with only one safe path.

SKILL.md

3.2 KB, as published. Nobody here has run it

Alternatives Before Code

Purpose

Prevent the first plausible implementation from becoming the decision by default.

Preserves

Tradeoff analysis.

Required Evidence

Decision to be made.
Constraints that affect reversibility, blast radius, cost, or testability.
Existing architecture notes or code boundaries if available.

Failure Signs

Only the anchored solution is considered.
The no-build or minimal option is hidden.
Complexity is recommended without naming the cost it buys.

When To Use

The change affects architecture, data shape, workflow, dependencies, or public behavior.
Multiple implementation strategies are plausible.
Reversibility, blast radius, or testability matters.
The user has already anchored on one solution.

When Not To Use

One-line fixes with obvious verification.
Formatting, renames, generated files, or lockfile-only work.
Emergency mitigation where delay would increase impact.

Inputs Expected

Decision to be made.
Constraints such as time, compatibility, migration risk, ownership, and test surface.
Existing architecture notes, ADRs, or code boundaries if available.

Output Expected

Decision:
Option A - Minimal:
Option B - Structural:
Option C - Conservative/no-build:
Recommendation:
Change-my-mind evidence:

Process

Name the decision in one sentence.
Produce a minimal option, a structural option, and a conservative/no-build option.
Compare cost, reversibility, blast radius, testability, and cognitive load.
Recommend one option.
State what evidence would change the recommendation.

Quality Bar

A good alternatives pass makes the tradeoff obvious enough that a reviewer can disagree with the recommendation without first reconstructing the decision.

Examples

Simple case: "Should we add a config flag or hardcode this timeout?" The skill should compare local constant, config flag, and no-change options.

Complex case: "Should failed billing sync move to a queue?" The skill should compare synchronous retry, scheduled retry, queue-based retry, and no-build operational mitigation.

See examples/simple.md and examples/edge-case.md.

Failure Modes

Only one option appears viable: explain which constraints eliminated the others.
Missing architecture context: inspect ADRs or code before recommending.
Emergency request: recommend immediate mitigation and defer deeper alternatives.
The boring option looks worse: explain the specific cost it fails to handle.

Safety And Privacy

Do not include private vendor details, customer names, or confidential architecture diagrams. Use generic labels when examples need sensitive context.

Anti-Slop Rules

Do not create fake options just to fill a template.
Do not hide the no-build option.
Do not recommend a complex option without naming the complexity it buys.
Do not use vague tradeoff words without specifics.