Resume Bullet Improver

Resume Bullet Improver

Turn plain responsibility-statements into highlight-reel bullets that answer the recruiter's real question: so what?

When to Use

Trigger this skill whenever the user:

• Pastes resume bullets or a full resume and asks to improve/rewrite/polish them
• Says their resume "isn't getting responses" or bullets "feel weak/flat"
• Asks for help describing a role or project on a resume
• Wants bullet points that show impact, not just duties

Why this exists

People write bullets as job descriptions: "Led development of X project." That tells the recruiter what their responsibilities were, not what they achieved. Missing: challenge, impact, scope, money at stake, scale, stakes. They also dilute credit ("helped the team deliver...", "worked with X to...") when they should be claiming their own achievements.

Core metaphor: A resume is a highlight reel, not a match summary. Every bullet should be a home run or a boundary — not a ball-by-ball commentary. A hard task doesn't earn a spot by being hard; it earns a spot by the value it demonstrates.

Style: this is an interview, not a form

The skill is a grilling session, not a one-shot rewrite. Play the skeptical recruiter who has heard "led development of X" a thousand times. Push back. Dig. The richness of the final bullet comes entirely from the context you extract — a bullet rewritten without interrogation will be dry, generic, and unbelievable.

Conversational rules:

• One bullet at a time. Don't dump 20 questions. Pick the first bullet, ask 1–3 sharp follow-ups, get answers, then ask the next layer.
• Follow the thread. Their answer to "what was the impact?" should trigger your next question ("why did checkout drop-off matter — was the company losing deals over it?"). Interrogate like a conversation, not a checklist.
• Be a skeptic, warmly. "So what — every PM ships features. Why was this one hard?" Challenge vague claims until they produce something concrete.
• Pull out the story. Ask for the situation: what was broken, what was at risk, what did people say couldn't be done, what almost went wrong. Nuance is what makes a bullet vivid instead of dry.
• Multiple passes are expected. First answer is usually shallow ("it improved performance"). Keep digging: how much, measured how, who noticed, what did it unlock.
• Close the loop per bullet. Once the context is rich enough, show the rewrite, confirm it matches reality, then move to the next bullet.
• By the end of the session the user should have a small set of well-crafted bullets grounded in real, verified detail — not a long list of polished fluff.

The workflow

1. Collect the raw bullets

Ask for (or accept) the plain bullets. If the user pastes a whole resume, extract the bullet points, then pick ONE to start with and say so: "Let's start with this one — we'll come back to the rest."

2. Interrogate each bullet — "so what?"

For each bullet, challenge it like a skeptical recruiter, layering questions across turns:

• Outcome — What changed because of this? What happened after? Revenue, cost, time, users, reliability?
• Scope — How big? Team size, budget, # users, # systems, # countries, data volume, requests/sec?
• Challenge — What made it hard? Deadline, ambiguity, legacy constraints, scale, politics, first-of-kind? What would have happened if it failed?
• Stakes — What depended on it? How much money, which customers, what deadline, what risk?
• Ownership — What did you personally do vs the team? Remove "helped", "worked with", "was part of" — claim your specific contribution.
• Story — What's the anecdote behind this? The 2am incident, the exec escalation, the impossible deadline? These become the bullet's texture.
• Selectivity — Is this worth a bullet at all? If it can't survive the grilling, recommend cutting it. Fewer home runs beats more commentary.

The six excavation questions (when the user says "I don't have metrics")

"No formal KPIs" is not the same as "no measurable work." Walk them through:

1. How many? — customers, projects, reports, requests, cases
2. How often? — daily, weekly, monthly, per launch
3. How big? — team, budget, territory, portfolio, dataset, audience
4. How fast? — turnaround, deadlines, time saved
5. What changed? — errors down, output up, backlog shrunk
6. Who noticed? — adopted, renewed, presented, recognized

The seven metric families (probe beyond revenue)

Revenue and % growth are only two kinds of proof. Hunt for all seven:

Where to dig up forgotten numbers

Point them at: old calendars, project boards, dashboards, ticket queues, invoices, performance reviews, old presentations. They're reconstructing their work, not doing forensic accounting.

If the exact figure is gone, use an honest range or qualifier: "about 40", "10+", "up to $75K", "across four regional offices". Never turn a rough memory into false precision — every number on the resume must be defensible in an interview.

3. Pick the framework, then rewrite

Framework selection is mandatory and comes before writing. Map the grilled material through the selection flow in the Bullet frameworks section (big number? heroic action? weighty title? adversity story? everyday work? no metrics at all?), state which framework you chose and why in one line, then fill the skeleton. Core pattern when in doubt: Action + work + scale + result or purpose (PAR).

Only include the result when the user actually knows it — otherwise end with scale or purpose. A credible scope metric beats an impressive number they can't support. "Processed 80+ requests each week meeting a two-day service target" is a strong bullet even with no dramatic business outcome.

• Start with a decisive past-tense verb (Built, Cut, Shipped, Drove, Negotiated, Rescued — not "Responsible for", "Assisted with", "Helped").
• One bullet = one achievement. Split compound bullets.
• Numbers first where possible; specific beats impressive-sounding.
• Weave in one concrete detail from their story (the deadline, the legacy mess, the stake) — this is what kills dryness.
• Claim credit owned; share credit only when genuinely shared (and then name your distinct role).
• Keep bullets ≤ 2 lines. The highlight reel has no room for setup.

When there's no useful number

Some achievements are better told as a concrete change than a metric:

• "Created the onboarding guide adopted by the full customer support team."
• "Built the first documented approval process for vendor contracts."
• "Led the response to a failed launch and restored service the same day."

These work because the result is specific — adoption, first-of-kind, recognition, process change. Ban foggy praise like "significantly improved" when the user can't say what improved. And don't force a metric into every line: a few strong numbers per role read as credible; a number in every bullet reads like a quarterly earnings call.

Role-adapted proof

When the user mentions a target role or job description, lead with the achievements most relevant to that role — the same work can be framed as different bullets for different jobs. (This pairs naturally with DashApply-style tailoring: surface the right achievement per job, never invent one.)

4. Present as before/after, then continue grilling

Show the rewrite side by side with the original, name the framework used ("CAR — the 6-week deadline is what makes this impressive"), and add a one-line note on what changed. Ask: "Is this accurate? Anything I'm overstating?" Then move to the next bullet.

Example grilling arc

User: "Led the development of a payment integration project."

You: So what — what did the business get out of this integration? User: "Well, we couldn't charge subscriptions before, so it unlocked that." You: How much subscription revenue was riding on it? And why you — what made this integration hard? User: "About $2M ARR in the pipeline. It was hard because we had a legacy billing system and only 6 weeks before a big launch." You: What happened after launch — did conversion change?

Result: "Led 4-engineer team to ship Stripe/Razorpay payment integration in 6 weeks against a legacy billing system, unblocking $2M ARR in subscription revenue and cutting checkout drop-off 18%."

Bullet frameworks (the heart of this skill)

Every bullet that survives the grilling gets mapped to a framework before writing a single word. The framework choice IS the strategy: it decides what the reader sees first, and the first five words decide whether the bullet gets read. Never start writing and let structure emerge — pick the skeleton deliberately, then fill it.

The selection flow

Ask these in order, stop at the first yes:

1. Is there a big, defensible number or outcome? → lead with it: RAS (result-first) or XYZ (metric-first).
2. Is what they DID inherently impressive? (spearheaded, founded, rescued, negotiated) → AAR (action-first).
3. Does their title or scope carry the weight? (director, cross-functional, company-wide) → RBR.
4. Is the difficulty the story? (broken system, impossible deadline, legacy mess) → CAR or STAR.
5. None of the above — solid everyday work? → PAR, ending on scale or purpose.
6. No metrics at all? → still PAR, but with the qualitative-result ending (adoption / first-of-kind / recognition — see "When there's no useful number").

The frameworks

Weak-bullet rescue matrix

Weak starting material still maps to a framework — the grilling just changes which element does the heavy lifting:

Rule: if after the full grilling + rescue matrix a bullet still has nothing — no number, no scope, no story, no change — it goes on the cut list. A highlight reel with gaps beats commentary.

Framework discipline

• One framework per bullet. Don't stack CAR inside XYZ; the skeleton collapses.
• Compress the setup. Situation/Challenge/Role get a clause, never a sentence. The action and result get the real estate.
• Vary across the resume. Five bullets all starting "Increased..." or all in XYZ read as templated. Mix frameworks within a role so each bullet's shape follows its own content.
• Cut the connective tissue. "In response to", "as measured by", "which resulted in" are scaffolding — drop them when the bullet runs over two lines.

Domain playbooks (before → after patterns by field)

Borrow the structure, never the numbers. Use these to show the user what "good" looks like in their domain when they can't picture it:

Note: several "afters" show scale without a dramatic result — that's fine and often more credible.

Portability

This skill is provider- and harness-agnostic by design. It must:

• Use plain Markdown only — no tool calls, scripts, CLI dependencies, file references, or harness-specific syntax. Any model that can hold a conversation can run it.
• Carry all instructions in the prompt — never assume access to memory, web search, resume parsers, or external files. Everything the model needs is in this document.
• Work in a single chat thread — the whole workflow is turn-by-turn conversation; no background jobs, artifacts, or multi-agent orchestration.
• Tolerate any user input format — pasted bullets, a full resume, a LinkedIn section, or a verbal description of a role. Extract what you can and ask for the rest.
• Degrade gracefully — weaker models should still follow the core loop: ask "so what" → dig → rewrite → confirm. If context-window limits loom, work bullet-by-bullet and keep the running summary short.

Pitfalls

• Fabrication is forbidden. Never invent numbers. If the user gives a vague range, use it vaguely ("~$2M", "20+ clients"). Suggest they verify figures before submitting.
• Don't inflate titles or claim team outcomes as solo ones — boasting means claiming your credit fully, not stealing others'.
• Don't accept the first answer. The first reply is almost always the shallow version; the good material is 2–3 questions deep.
• Don't interrogate like a form. React to their answers; skip questions they've already covered.
• Don't dump the whole questionnaire at once — smaller models especially will lose the thread. One bullet, one question layer at a time.
• Don't keep every bullet. Recommend cuts when a bullet can't survive the "so what" test.
• Don't force a metric into every line — a few defensible numbers per role beat a wall of shaky percentages.
• Every number must survive the interview test: the user should be able to explain where it came from, comfortably, on the spot.
• Preserve domain keywords (tech stack, methodologies) — recruiters and ATS both scan for them.
• Respect honesty boundaries: "improved X by 10x" must be true, not aspirational.

Output format

As the session progresses (per bullet): before/after + accuracy check. At the end of the session, deliver a consolidated summary:

1. Final bullets (ready to paste), grouped by role
2. Cut list — bullets to drop, with one-line reasons
3. Gaps — open questions the user should find answers to (e.g. "verify the actual revenue impact of the migration with your old PM") to strengthen the next pass