cv/.claude/commands/linkedin-experience.md

description, argument-hint, allowed-tools

description	argument-hint	allowed-tools
Read an experience YAML file (and its linked projects), interview the user — including target roles to mirror — then rewrite it in place as a recruiter- and SEO-optimized LinkedIn Experience entry.	path/to/experience.yml	Read, Write, Edit, Glob, Grep, Bash(git log:*), Bash(git remote:*), Bash(cat:*), Bash(ls:*), Bash(jq:*), Bash(yq:*)

Enhance LinkedIn Experience Entry (YAML-driven)

• Enhance LinkedIn Experience Entry (YAML-driven)
  • Phase 0 — Parse and ground (silent, fast)
  • Phase 1 — Interview (ask extensively, then STOP and wait)
  • Phase 2 — Rewrite the YAML (same schema)
  • Phase 3 — Validate and report gaps

The argument is a path to an experience YAML file:

$ARGUMENTS

The file follows this schema:

title: iOS Developer
company: Britetwist
start: 2016-07-01
end: 2019-05-01
location: Ashburn, VA, USA
description: |
  - Bullet one…
  - Bullet two…
skills:
  - Executive Leadership
  - iOS Development
projects:
  - ../projects/superball.yml
  - ../projects/voluntree.yml

An Experience entry is the higher-level rollup that sits above its linked projects. The projects carry the deep-dive detail; this entry summarizes the role, its scope, and its aggregate impact — and points to the projects as the deeper dives. Your job: rewrite this file in place following the principles below, without inventing or inflating any fact, metric, or technology. Existing numbers must be confirmed, not embellished; missing ones get flagged, not fabricated.

---

Phase 0 — Parse and ground (silent, fast)

1. Read the experience YAML at $ARGUMENTS. Capture every field; description is source-of-truth content to refine, not discard.
2. Read every file in projects: (resolve relative paths). These are the deep dives. Use them to (a) aggregate real metrics, (b) confirm the true tech stack, (c) avoid duplicating any project's bullets verbatim in the rollup, and (d) catch contradictions (e.g. a download count in the experience that doesn't reconcile with the projects).
3. If any project links a repo URL, optionally inspect it (README, manifest, git log) to verify the stack.

Then diagnose the entry against the framework. For the example above the diagnosis would be: title undersells the role ("iOS Developer" when the first bullet says founded a studio — that's Founder-level); the description is metric-rich (1M downloads, 15K DAU, 40K reads) which is good, but has no target-role keyword mirroring and no customer/landing-page language; skills are reasonable but should be tuned to the roles being targeted.

---

Phase 1 — Interview (ask extensively, then STOP and wait)

This is an Experience entry tuned for recruiters and search, so the interview must surface things the YAML can't tell you — above all which roles you're targeting, so the wording can mirror real job-description language. Ask in 3 focused batches, leading each with what you inferred so the user only confirms or corrects. Stop and wait after each batch.

Batch A — Role, title, scope

1. The title reads as "iOS Developer," but the description says you founded the studio. What's the accurate role/title (e.g. "Founder & iOS Developer," "Founder & Lead Engineer")? LinkedIn's title field is the job title — keep it believable, but don't undersell ownership.
2. Solo, or did you lead a team? If team: size, and what you personally owned vs. directed.
3. Confirm company, location, and the start/end dates.

Batch B — Target roles + keyword zones (the recruiter lever) 4. What roles are you targeting next? (e.g. "Staff Engineer – Wallet & Onboarding," "Founding Engineer – Payments," "Eng Lead – Web3.") Name 1–3. I'll mirror their JD phrasing into the bullets. If you can paste a JD or two, even better. 5. Who was the customer/audience for this work, in their words? I'll add one landing-page-style line (the kind of phrasing buyers search) alongside the recruiter and tech phrasing — three overlapping keyword zones in one description. 6. Full tech stack for the role (confirm/extend what the linked projects imply): languages, engines/frameworks, backend, infra, platforms (iOS/Android/web), and any auth/payments/identity specifics.

Batch C — Metrics: confirm, reconcile, expand 7. Confirm each existing number (1M+ downloads, 15K DAU, 1,250 MAU, 40K article reads) — are these accurate as stated, and do they reconcile with the linked project files? 8. Any additional role-level metrics worth surfacing at this altitude: revenue/ARR, App Store ranking or feature, retention/D30, team size, fundraising, total titles shipped, aggregate review score? 9. For any bullet without a number, do you have one you can stand behind — or should it stay qualitative?

Hard rule: confirm or omit. Never inflate an existing metric or invent a new one to make a bullet land harder. Flag gaps in Phase 3 instead.

---

Phase 2 — Rewrite the YAML (same schema)

Transform each field, preserving the structure:

• title → accurate, ownership-reflecting job title. Optionally sharpen with an outcome/role frame if it stays a believable title (e.g. Founder & iOS Developer). Don't turn it into a sentence.
• company / location / start / end → keep (correct only if the user did).
• description → 3–5 STAR-style bullets, no long paragraphs, in this arc:
  1. Problem + audience — what you built and for whom (carry customer/landing-page language here).
  2. Scope + architecture — what the studio/role actually shipped (rollup level — reference the projects as deep dives; don't paste their bullets).
  3. Your specific contributions — active verbs, ownership, mirroring target-JD phrasing from Batch B.
  4. Impact metrics — the confirmed numbers, aggregated to role level.
  5. Tech + skills — dense, searchable, canonical names. Weave all three keyword zones (recruiter/JD terms, customer phrasing, tech specifics) naturally across the bullets — no stuffing, no filler buzzwords ("revolutionary," "passionate").
• skills → a consistent closed set of 5–8 canonical LinkedIn skill names, tuned to the target roles from Batch B (so this entry surfaces in the right recruiter searches). Reuse the same vocabulary across the user's other experience/project files for the compounding-skill effect.
• projects → keep the list unchanged (these are the linked deep dives).

Show the full rewritten YAML in a fenced block first for review, with a one-line note if you're torn between title variants. Then write it back to $ARGUMENTS in place (preserving key order and the description: | block scalar). If the user prefers non-destructive, save to a sibling *.enhanced.yml — ask only if ambiguous.

---

Phase 3 — Validate and report gaps

Pass/flag each item (✅ / ⚠️), honestly:

• title reflects true ownership/role (not undersold, not inflated)
• Bullet 1 leads with problem + audience in customer language
• Description mirrors the target-role JD phrasing from Batch B
• Each metric is confirmed and reconciles with the linked project files (no inflation)
• Description rolls up the projects without duplicating their bullets verbatim
• All three keyword zones present (recruiter / customer / tech)
• skills is a consistent closed set tuned to target roles
• projects links intact; dates and company coherent
• Reads naturally to a human — no keyword stuffing

For every ⚠️, state exactly what the user must supply to close it. Do not silently fill the gap, and never overwrite the file with an inflated or invented number to make a box go green.