name: Leverage First
description: Before committing real effort to a chosen approach, spend a cheap cycle to find the higher-leverage path - an existing solution/tool/dataset, a more efficient method, or a smarter composition - instead of grinding the first workable idea on one track. Activate when about to build a tool, collect data the slow way, or write a lot of code; on "is there a better way", "what else could we try", "how should we do this"; or when you catch yourself about to hand-roll something, poll/scrape in a loop, or test one pet hypothesis. Signals: the obvious grind; about to reinvent something.
Leverage First
Purpose
The reliable failure isn't picking a wrong idea — it's executing the first workable
method on a single track when a dramatically better one was one cheap question away.
Hand-rolling a tool that already exists; collecting data live for hours that history
already holds; running five separate passes that could be one; testing your pet
hypothesis when the same data answers ten questions. Each is effort spent where leverage
was available. This skill inserts one cheap step before the grind: find the higher-leverage
path first. It is the "work smarter, not just harder" reflex, made explicit and non-optional.
When to use this skill
- You're about to build a tool, harness, or script — before writing it.
- You're about to collect/gather data the slow way (live polling, scraping, manual).
- You're about to run a heavy process or a long single-track computation.
- "How should we do this?", "is there a faster/better way?", "what else could we try?"
- You notice yourself reaching for the obvious grind, or a task that "will take hours".
When NOT to use
- The leverage pass is itself more expensive than just doing the small task (a one-off,
five-minute job — don't spend ten minutes looking for a shortcut to a five-minute task).
- You already did the pass this session for this problem and nothing changed.
- A true emergency where any working path now beats a better path later.
The procedure (one cheap pass, four questions)
Before committing effort, spend a few minutes on:
- Don't reinvent — does it already exist? Has someone solved this? Is there a dataset,
API, library, tool, or community knowledge that hands you 80% of it? Search/ask before
you build. (A free historical dataset existed instead of hours of live collection; the
answer was a documented endpoint away.)
- 10× not 10% — is there a fundamentally more efficient method? Not a faster version of
the same grind — a different shape: historical vs live, batch vs loop, existing index vs
fresh scrape, closed-form vs simulation. If the best case is "same approach but quicker",
keep looking for the shape change.
- Compose, don't isolate — can the steps share a resource and combine? If you're about
to run N separate passes over the same data/timeframe, make it one pass that computes all
N — it's cheaper AND reveals interactions (overlap, complementarity) siloed runs hide.
- Enumerate the question space — is the pet hypothesis the best use? A new capability
(dataset, tool, access) usually answers many questions. List them, rank by value, and
don't tunnel on the first one that occurred to you.
Then commit to the highest-leverage path you found. If all four come up empty, grind with
a clear conscience — but you asked.
- Adopting a tool? Evaluate before you integrate — unprompted. When Q1 lands on an
existing tool/library/dependency and you're about to add it, the adoption isn't done at
"installed." Deliver, without being asked: (a) what it is — its type and integration
model (CLI vs library vs AI-assistant skill vs MCP server vs background daemon), because
that governs what it touches and can see; (b) standard or per-case — does it belong
in every project or only where it earns its keep, with the threshold stated; (c)
alternatives — what else solves this and why this one (the category often moves);
(d) limitations, adversarially — where it's weak/wrong, up front; (e) what else it
enables — the deeper features beyond the headline use. This is the value/fit pass;
the safety pass on any third-party instruction files (
publish-hygiene /
security-pattern-review — treat them as untrusted code) is a separate, required gate.
Having to be prompted for this evaluation is the failure — it is part of adopting.
Quality bar
- Before any effortful build/collect/run, the four questions were actually asked (not skipped).
- You didn't hand-build what already exists, or grind live what history holds.
- Multi-pass work that could share a resource was composed into one pass.
- The effort spent is proportional to the value; leverage was sought before labor.
Common failure modes
- Grind reflex: starting to build/collect the instant the task is understood, skipping the
pass entirely. The pass is cheap; the wasted grind is not.
- 10%-thinking: optimizing the chosen grind (faster loop, more threads) instead of asking
if the whole approach should change. Speed-of-the-wrong-shape is still the wrong shape.
- Tunnel on the pet hypothesis: testing the one idea you had instead of the highest-value
question the new capability unlocks.
- Over-applying it: turning a five-minute task into a research project on how to avoid a
five-minute task. The
When NOT clause is part of the skill.
- Reinventing under deadline pressure: "no time to look for a tool" — then spending hours
building the tool that a two-minute search would have found.
Works with sibling skills
divergent-ideation widens ideas for an open problem; this widens method and resources
before execution — a distinct, later trigger. research-methodology is the deeper
source-gathering when question #1 ("does it exist?") turns into real research.
empirical-validation tests a claim cheaply once you've found the efficient way to test it.
effort-calibration sets how much rigor the task deserves; this makes sure the effort lands
on the leveraged path. deep-decomposition/plan-gate sequence the work after the approach
is chosen.
Provenance and maintenance
Added 2026-07 after a collaborator had to supply this move repeatedly in one session
("see how others did it", "find a more efficient way", "use them in the same timeframe",
"what other tests?") — each redirection replaced hours of grind with a cheap leverage step,
and one of them surfaced the session's actual finding. Extracted per
.claude/learnings/2026-07-09-leverage-first-before-grinding.md and
…-mine-the-collaborators-redirections.md. Deliberately shipped as a skill, NOT an
always-on snippet rule — the snippet is the proven, attention-scarce component and adding to
it can dilute it (see …-adding-to-the-proven-snippet-needs-an-ab.md). Re-verify by the
negative test: a session that hand-rolls what exists, or grinds live what history holds,
without asking the four questions — the trigger failed.
