What should i consider

Skill radustefandumitru/overdrive/skills/what-should-i-consider

Use when the user asks what they are missing, wants a plan pressure-tested, requests architectural review, asks for hidden risks/tradeoffs, or is about to make a consequential technical/product decision. Surfaces blind spots, implicit decisions, structural assumptions, scaling risks, failure modes, and decisions not yet made. Be objective and direct, not flattering.From its SKILL.md

Install

npx -y skills add radustefandumitru/overdrive --skill what-should-i-consider

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

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
18 stars18 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.

SKILL.md

2.7 KB, 490 tokens by cl100k_base, as published. Nobody here has run it

What Should I Consider?

Use this as a senior-system-architect pressure test. The goal is not to be encouraging. The goal is to make invisible risk visible before the user commits time, money, code, or reputation.

Operating Mode

Restate the decision or plan in one sentence only if needed for clarity.
Identify the hidden assumptions the plan relies on.
List the highest-impact considerations first.
Separate actual blockers from tradeoffs.
Name decisions the user has not made yet.
End with an honest recommendation: proceed, simplify, pause, research, prototype, or reject.

What To Look For

Architecture boundaries that will be painful to change later.
Data ownership, migration, retention, privacy, and deletion assumptions.
Auth, permission, billing, rate-limit, and abuse cases.
Reliability, observability, rollback, recovery, and support paths.
Performance and scaling assumptions that are untested.
User workflow friction, edge cases, and degraded states.
Vendor lock-in, operational burden, and maintenance cost.
Build-vs-buy choices and premature abstractions.
Launch, legal, SEO, accessibility, and trust implications when relevant.
Places where the plan solves the visible problem while creating a larger hidden one.

Output Format

Use this structure unless the user asks for something else:

Verdict: <one-sentence honest read>

Highest-risk assumptions
- ...

What you should consider
- [High] ...
- [Medium] ...
- [Low] ...

Decisions not yet made
- ...

Recommended next move
<specific action, prototype, research step, or simplification>

Rules

Do not invent certainty. If evidence is missing, say what would prove or disprove the concern.
Do not pad with generic “consider scalability/security/accessibility” advice. Make each point specific to the user's situation.
Do not default to “yes, great idea.” If the plan is weak, say so plainly and explain why.
Prefer fewer, sharper points over long exhaustive lists.
If current documentation, pricing, platform limits, API behavior, or legal/compliance rules matter, research before making claims.

Attribution

Original Overdrive skill by Radu Stefan Dumitru and Codex, created to make agents more objective when reviewing architecture, product, and implementation plans.

What ships with it: 1 file

418 B alongside SKILL.md

agents/

openai.yaml418 B