From 3985b9bd8dc6ce5ceeb0555e92c33c053d17b10c Mon Sep 17 00:00:00 2001 From: Prad Nukala Date: Tue, 30 Jun 2026 10:49:03 -0400 Subject: [PATCH] docs(claude): add linkedin experience command documentation --- .claude/commands/linkedin-experience.md | 111 ++++++++++++++++++++++++ 1 file changed, 111 insertions(+) create mode 100644 .claude/commands/linkedin-experience.md diff --git a/.claude/commands/linkedin-experience.md b/.claude/commands/linkedin-experience.md new file mode 100644 index 0000000..f4aae5c --- /dev/null +++ b/.claude/commands/linkedin-experience.md @@ -0,0 +1,111 @@ +--- +description: 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. +argument-hint: [path/to/experience.yml] +allowed-tools: 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)](#enhance-linkedin-experience-entry-yaml-driven) + - [Phase 0 — Parse and ground (silent, fast)](#phase-0-parse-and-ground-silent-fast) + - [Phase 1 — Interview (ask extensively, then STOP and wait)](#phase-1-interview-ask-extensively-then-stop-and-wait) + - [Phase 2 — Rewrite the YAML (same schema)](#phase-2-rewrite-the-yaml-same-schema) + - [Phase 3 — Validate and report gaps](#phase-3-validate-and-report-gaps) + + +The argument is a path to an experience YAML file: + +> $ARGUMENTS + +The file follows this schema: + +```yaml +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.