---
name: job-application
description: Tailor a resume, cover letter, or application answers to a specific job description. Use when the user shares a JD and asks to apply, tailor their CV, write a cover letter, answer application questions, or draft outreach to a hiring manager or recruiter.
---

# Job application

The job is to make a true story land against *this* JD. Never to invent one.

## Hard rules

1. **No fabrication, ever.** Every claim traces to something the candidate
   actually did. If the JD wants experience they don't have, say so and find the
   nearest honest adjacency — don't manufacture it. A single invented number
   destroys the whole document in a reference check.
2. **Never inflate a title or a role.** If they were the founding builder, say
   founder. If they supported, say supported. Precision reads as confidence;
   inflation reads as a red flag to anyone who's hired before.
3. **Outcomes over responsibilities.** "Owned the roadmap" says nothing.
   "Grew X from A to B in N months by doing Y" says everything. Every bullet
   should survive the question "so what happened?"
4. **Their words, not yours.** Mirror the JD's vocabulary for the same concept.
   If they say "discovery", don't write "user research". This is honest
   translation, and it's what keyword screens and skimming hiring managers key
   on.
5. **Cut before you add.** A tailored one-pager beats a comprehensive two-pager.
   Anything not serving this specific JD comes out.

## Sequence

### 1. Read the JD as a product spec
Extract, before writing anything:
- **The real job** — what problem are they hiring to solve? It's usually
  visible in the first responsibility and in what's repeated.
- **Must-haves vs nice-to-haves** — treat repeated items as must-haves
  regardless of which list they appear in.
- **The unstated shape** — company stage, whether this is a first hire or a
  backfill, whether they want a builder or an optimizer, who this person will
  fight with.

### 2. Score the fit honestly
A short table: requirement · evidence from the candidate's history · 🟢 strong /
🟡 adjacent / 🔴 gap.

Report the 🔴s to the user plainly. Then decide together: a couple of 🔴s on
nice-to-haves is normal and worth applying to. A 🔴 on the core competency means
the application is a lottery ticket — say that, rather than dressing it up.

### 3. Pick the three proof points
Not everything. Three stories that map onto the must-haves, each with a
concrete outcome and a number where one honestly exists. These become the resume
bullets, the cover letter spine, and the interview answers — the same three,
consistently, so the story compounds across touchpoints.

### 4. Write

**Resume.** Reorder and rewrite bullets against the must-haves; drop what
doesn't serve them. Lead each bullet with the outcome. Keep the factual spine
(titles, dates, employers) untouched — tailoring means emphasis and phrasing,
never revised history.

**Cover letter.** Four short paragraphs, max one page:
- The specific thing about *this* company or problem that's real for the
  candidate. If there's nothing real, skip the letter or keep it functional —
  fake enthusiasm is transparent.
- Proof point one, mapped to their biggest must-have.
- Proof points two and three, compressed.
- What they'd do in the first 90 days, concretely. This is the paragraph most
  candidates skip and it's the one that gets replies.

No "I am writing to express my interest." No listing adjectives about oneself.

**Application questions.** Answer the question asked, in their word count, with
a specific example. Reuse the three proof points.

**Outreach to a human.** Under 120 words. One line on why them specifically, one
proof point, one clear low-friction ask. Never attach the cover letter.

### 5. Adversarial pass
Before handing it over, read it as a skeptical hiring manager and report what
you find:
- Any claim that can't be substantiated → cut or soften it.
- Any number without a source the candidate could defend live → flag it.
- Any sentence that would read identically on someone else's application →
  rewrite or delete it.
- Any 🔴 gap the document is quietly hiding → tell the user, so they're not
  ambushed in the screen.

## Candidate facts

Pull the canonical career facts from the user's memory and resume source files
rather than from this skill, and **confirm anything load-bearing with the user
before it ships** — titles, ownership scope, and headline metrics are exactly
what a reference check probes. Where memory and a resume disagree, ask; don't
silently pick one.

Keep a per-application folder: the JD, the fit table, the tailored artifacts,
and a short log of what was sent when. Applications get resurrected months
later, and the fit table is the fastest way back into context.