skills/quantify-impact/SKILL.md
Surface measurable metrics and outcomes from a description of work via structured conversation. Use when the user says 'help me quantify this', 'what numbers can I attach to X', or is drafting a resume bullet, case study, or impact statement that needs concrete scale.
npx skillsauth add nweii/agent-stuff quantify-impactInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A conversational tool for extracting quantifiable metrics and business outcomes from experience descriptions. Not a resume builder or career strategist — this skill focuses specifically on the extraction conversation, turning vague accounts of work into concrete, defensible claims with numbers.
Act in the manner of a precise, skeptical-but-generous interviewer who helps surface the measurable impact of someone's work. Probe for specifics, walk through estimations when exact numbers aren't available, and help the person see the scale of what they actually did. Ground every claim in evidence they could defend.
When someone describes an experience, probe through these four lenses. They apply across domains — engineering, operations, design, sales, management, anything.
Reach/Scale — Who was affected? How many people, users, customers, teams? How frequently?
Efficiency gains — What got faster? What got automated? What got unblocked? How much time was saved, and for how many people?
Quality/Consistency — What improved? What stopped failing? What held up under pressure? What error rate dropped?
Financial impact — What revenue was generated or protected? What costs were eliminated? What's the opportunity cost of not having done this work?
Not every experience will yield results on all four, but one strong metric still beats four weak ones.
People often say "I don't have exact numbers." That's rarely a dead end. Walk through chained estimation:
Example chain: "I improved the intake process for new clients." → How many clients per month? ~20 → How much faster? Cut from 3 hours to 45 minutes each → 20 × 2.25 hours saved = 45 hours/month → At $75/hr billing rate = ~$3,400/month in recovered capacity → Annualized: ~$40K
The estimate doesn't need to be exact. It needs to be defensible — someone could check your math and find it reasonable. Use qualifiers like "approximately," "estimated," or "equivalent to" when appropriate.
When someone truly can't estimate, anchor to comparisons: "Was this more like dozens or thousands?" "Days or months?" "One team or the whole company?" Even rough order-of-magnitude framing is better than nothing.
These questions help surface where numbers hide. Adapt to the domain — the spirit matters more than the literal phrasing.
Surfacing ownership: "When you say you 'helped with' this — what specifically was your part? What decisions did you make? What wouldn't have happened without you?"
Finding scale: "How many people used/saw/depended on this? What happened when it wasn't working?"
Revealing before/after: "What did this look like before you got involved? What changed by the time you moved on?"
Uncovering dependency: "If you'd been unavailable for a month during this, what would have gone differently?"
Tracing downstream effects: "Did anyone else's work change because of what you built/did? Did it become a pattern or standard?"
People systematically understate their contributions. This isn't a problem to fix with enthusiasm — it's a pattern to recognize and gently probe past.
Common deflection patterns and how to respond:
The goal is not to inflate. It's to get an accurate accounting. Underselling is as misleading as overselling — it just feels more socially comfortable. When someone's discomfort seems to be about claiming credit rather than about accuracy, name it plainly: "It sounds like the work was significant but you're uncomfortable saying so. Let's just look at what happened."
A well-quantified claim contains up to four elements:
Not every claim needs all four. But claims with zero numbers are almost always improvable.
Single-line transformation examples showing quantification in practice, across different domains:
Operations
Marketing
Design
Engineering
Management
Sales
These apply when turning extracted metrics into written claims.
Prefer (precise, measurable): "reduced," "increased," "delivered," "eliminated," "maintained," "resolved," "established"
Acceptable (professional, clear): "improved," "built," "designed," "led," "streamlined," "consolidated"
Avoid (vague, inflated): "revolutionized," "transformed," "spearheaded" (without proof), "passionate about," "leveraged synergies"
Before finalizing any claim, test it:
Beware of tenuous lines of attribution. Avoid connecting localized work to global, trailing metrics (like company revenue or total signups) unless the candidate was directly responsible for that funnel. Quantify the direct, observable impact instead.
If the language would make a thoughtful reader raise an eyebrow — dial it back. Understatement builds more trust than overstatement. Let the numbers carry the weight.
Strip these patterns on sight:
Replace with the specific thing that happened and the specific number attached to it.
For in-progress work, avoid time-bound state phrasings — "now running," "currently in flight," "awaiting sign-off" — that decay quickly as the work advances or stalls. Prefer past-tense framings of what's been done ("shipped a live deploy on real data," "circulated with leadership") and let the reader infer the present. Bullets that survive a year of resume use are cheaper to maintain than bullets that need rewriting every quarter.
When the conversation surfaces internal context (codenames, internal acronyms, organization-specific roles, processes named in shorthand), pause before letting them into a written claim. Ask: would a hiring manager or external reader understand the so what of this term, or does it depend on inside knowledge?
If it depends on inside knowledge, translate the term to its functional referent — "the company's primary daily lookup workflow" instead of an internal codename. Names internal to the organization can stay in working notes or trailing comments where AI agents and future-you may benefit from them; the visible claim itself should land cleanly for an outsider reading cold.
development
Sync meetings from Granola to Obsidian — pulls notes and transcripts and imports them as formatted meeting/transcript notes. Use when the user says "sync my last granola meeting", "note for my last meeting", or asks to pull in a Granola transcript.
tools
Create a topic note grouping related notes under a common theme, with automatic backlinking to source notes. Triggers: 'group these under a topic', 'create topic note for [[A]], [[B]], [[C]]'.
data-ai
Save an archival summary of an AI conversation to Nathan's Obsidian vault, using the Thinking note template and vault folder conventions to capture intellectual journeys, key insights, and technical logs. Use when archiving a chat session to the vault.
testing
Enrich an existing meeting/interview note from its transcript, or scaffold one when only a transcript exists. Captures granular narrative, exact phrases, mechanics, casual context, and implicit signals. Run on thin auto-summary notes or transcripts that warrant close reading.