diff --git a/.claude/commands/linkedin-project.md b/.claude/commands/linkedin-project.md index 38a7dee..9a74f02 100644 --- a/.claude/commands/linkedin-project.md +++ b/.claude/commands/linkedin-project.md @@ -1,113 +1,99 @@ --- -description: Interview the user about a project, then produce a search-optimized LinkedIn Projects entry (keyword-rich title, STAR-structured description, consistent skills vocabulary). -argument-hint: [project name | repo path | repo URL | one-line description] -allowed-tools: Read, Glob, Grep, Bash(git log:*), Bash(git remote:*), Bash(cat:*), Bash(ls:*), Bash(jq:*) +description: Read a project YAML file, interview the user to fill gaps (especially quantified metrics), then rewrite it in place as a search-optimized LinkedIn Projects entry. +argument-hint: [path/to/project.yml] +allowed-tools: Read, Write, Edit, Glob, Grep, Bash(git log:*), Bash(git remote:*), Bash(cat:*), Bash(ls:*), Bash(jq:*), Bash(yq:*) --- -# Enhance LinkedIn Project Entry +# Enhance LinkedIn Project Entry (YAML-driven) -- [Enhance LinkedIn Project Entry](#enhance-linkedin-project-entry) - - [Phase 0 — Ground yourself (silent, fast)](#phase-0-ground-yourself-silent-fast) +- [Enhance LinkedIn Project Entry (YAML-driven)](#enhance-linkedin-project-entry-yaml-driven) + - [Phase 0 — Parse and ground (silent, fast)](#phase-0-parse-and-ground-silent-fast) - [Phase 1 — Interview (ask, then STOP and wait)](#phase-1-interview-ask-then-stop-and-wait) - - [Phase 2 — Produce the entry](#phase-2-produce-the-entry) - - [Phase 3 — Validate against the checklist](#phase-3-validate-against-the-checklist) + - [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) -You are optimizing a single LinkedIn **Projects** entry for maximum search visibility and recruiter/investor conversion. The seed for this project is: +The argument is a path to a project YAML file: > $ARGUMENTS -Your job is **not** to write a generic blurb. It is to (1) ground yourself in whatever real evidence exists, (2) **interview the user thoroughly** to extract accurate, specific facts and metrics, and (3) produce a polished entry that follows the ranking principles below. **Never fabricate a metric, technology, link, or outcome.** If the user doesn't have a number, you flag the gap or omit it — you do not invent one. +The file follows this schema: + +```yaml +title: Layer-1 Blockchain & Decentralized Identity Ecosystem +start: 2022-01-01 +project-url: https://github.com/sonr-io/sonr +skills: + - Go + - Kubernetes + - WebAuthn +description: | + - Bullet one… + - Bullet two… +associated-with: ../experience/sonr.yml +``` + +Your job: **rewrite this file in place** so it follows the LinkedIn ranking principles below — without losing the schema, and **without inventing any fact, metric, technology, or link.** If the user has no number for a claim, you flag it or keep the claim qualitative; you never manufacture one. --- -## Phase 0 — Ground yourself (silent, fast) +## Phase 0 — Parse and ground (silent, fast) -If `$ARGUMENTS` points at a local repo path or a repo URL you can resolve, gather facts before asking anything. Where useful, inspect: +1. **Read the YAML** at `$ARGUMENTS`. Capture every field; treat `description` as the source-of-truth content to *refine*, not discard. +2. **Read `associated-with`** (resolve the relative path) to learn the role, company, and date context this project hangs off of. +3. **Inspect `project-url`** if it's a resolvable repo. Pull real signals: `README`, `package.json` / `go.mod` / `Cargo.toml`, `git log --oneline -20`, deploy artifacts (`jq` on any `run-latest.json` for contract addresses). Use this to *verify* the claimed stack and surface any tech the description omits. -- `README.md`, `package.json` / `Cargo.toml` / `go.mod` (name, description, deps → real tech stack) -- `git log --oneline -20` and `git remote -v` (commit history as proof of work, repo URL) -- Monorepo layout, `turbo.json`, Dockerfiles, CI config (architecture + DevOps signals) -- Deployment artifacts (e.g. `run-latest.json` for contract addresses via `jq`), docs, whitepapers - -Extract a *draft* of: real technologies in use, the repo URL, any deploy/contract links, and the apparent scope. **Pre-fill answers you can verify so you don't ask the user things the code already tells you.** Then move to the interview only for what you genuinely cannot determine. - -If `$ARGUMENTS` is just a name or rough description with no inspectable source, skip straight to Phase 1. +Then diagnose the file against the framework and note, internally, the specific weaknesses. For the example above the diagnosis would be: title is a generic anti-pattern (no role, no stack, ranks for nothing); description bullets are strong on *what/how* but contain **zero quantified outcomes**; skills list is close but should be a tight consistent set; no ongoing flag. --- ## Phase 1 — Interview (ask, then STOP and wait) -Ask in **2–3 focused batches**. Present each batch, then **stop and wait for the reply** before continuing. Lead each batch with what you already inferred from Phase 0 so the user only confirms or corrects ("From the repo I see X, Y, Z — correct any of these"). Keep it tight; this person is technical, so don't over-explain why you're asking. +Ask in **2–3 focused batches**, leading each with what you already inferred so the user only confirms or corrects. Stop and wait after each batch. This person is technical — don't pad. -**Batch A — Identity, role, scope** -1. One sentence: what is this project and what problem does it kill? -2. Your exact role (Founder, Lead Engineer, Protocol Engineer, Contributor…) and solo vs. team — if team, what did *you personally* own? -3. Status: shipped / in-progress / archived? Live URL or testnet/mainnet? -4. Which **Experience or Education entry** should this attach to, and the date range (and is it ongoing)? +**Batch A — Title, role, status** +1. The current `title` is generic and will not rank. I'll reframe it as `[Product] — [Role] | [Tech · Tech · Tech]`. What's the product name to lead with, and your exact role on it (Founder, Lead Protocol Engineer, …)? +2. Solo or team? If team, which of these description bullets did *you personally* own vs. direct? +3. Is this ongoing (no end date) or did it end? (Drives the Present/end flag.) -**Batch B — Stack, architecture, hard problems** -5. Full technology stack — languages, frameworks, protocols, infra. (Confirm/extend the list I pulled from the repo.) Aim toward the high-value categories: chain/L2, identity/auth, smart contracts/AA, libraries, architecture pattern, frontend, infra, payments. -6. The 1–3 *non-obvious* architecture decisions or hard problems you solved (the things a knowledgeable reader would respect). -7. Any **proof-of-work links**: GitHub repo, live demo, block-explorer/contract addresses, docs, whitepaper, hackathon placement. +**Batch B — Stack + the hard problems (confirm, don't re-list)** +4. From the repo + skills I see: [list inferred stack]. Anything searchable missing or wrong? (Targeting chain/L2, identity/auth, smart contracts/AA, libraries, infra, frontend, payments.) +5. For each description bullet, the one non-obvious decision worth signaling to a knowledgeable reader — so I sharpen the verb and the technical specificity. -**Batch C — Quantified outcomes (push hard here)** -8. Any external traction? (users, transactions, partners, downloads, stars.) -9. If there are no external numbers yet, give me **internal/engineering metrics** instead — these count: latency (ms), bundle size (gzip KB), test coverage, contracts/endpoints shipped, testnet txns processed, deploy-time reduction, packages in the monorepo, cold-start improvement, gas reduction, lines of code. I need at least one concrete number; tell me which you can stand behind. +**Batch C — Quantified outcomes (push hardest here)** +6. The description has no numbers anywhere; that's the single biggest miss. For each bullet, give me a real metric. External (users, txns, partners, stars) *or* internal engineering metrics, which count equally: latency (ms), gzip bundle size, test coverage, contracts/endpoints shipped, testnet txns processed, deploy-time reduction, monorepo package count, cold-start improvement, gas reduction, node count in the testnet, LOC. +7. I need at least one number you can stand behind per bullet, or that bullet stays qualitative. Which can you back? -**Hard rule:** if after Batch C the user has no real metric for a claim, do not manufacture one. Write the claim qualitatively or drop it, and note the gap in Phase 3. +**Hard rule:** no real metric → no invented metric. Flag it in Phase 3 instead. --- -## Phase 2 — Produce the entry +## Phase 2 — Rewrite the YAML (same schema) -Apply these principles (highest-leverage first): +Transform each field, preserving the structure: -- **Project Name = highest-weighted field.** Use: - `[Product/Initiative] — [Role] | [Tech 1] · [Tech 2] · [Tech 3]` - Embed role-title language + top 2–3 keyword technologies. No vague six-word titles, no "innovative/passionate." -- **Description = keyword-density engine, 150–300 words, three parts:** - 1. One sentence — what it is + core technical premise (front-load the primary keyword in sentence one). - 2. 2–3 sentences — concrete tech, architecture decisions, what *you* built. Active verbs, real protocol/framework/language names. Target ~15–25 searchable keywords total, woven in naturally (no stuffing). - 3. 1–2 sentences — the quantified outcome (number, %, scale, or benchmark). STAR framing: action verb + specific method + measurable result. -- **Skills:** propose a **consistent closed set of 4–6** that should repeat across the user's other projects (e.g. `Blockchain Development · TypeScript · Distributed Systems · Smart Contracts · Web Application Development`). If they've used this command before, reuse the same vocabulary for the compounding effect. -- **Association + URL + media:** state which Experience entry it links to, the URL to attach, and recommend one specific media thumbnail (architecture diagram, live screenshot, repo card, or Loom). +- **`title`** → `[Product] — [Role] | [Tech 1] · [Tech 2] · [Tech 3]`. Highest-weighted field; embed role-title language + top 2–3 keyword technologies. Kill generic phrasing ("Ecosystem," "revolutionary"). +- **`start`** → keep. Add an `end:` field only if the project ended; otherwise it reads as Present. +- **`project-url`** → keep (this is the proof-of-work link). +- **`skills`** → reduce to a **consistent closed set of 4–6** using LinkedIn's canonical skill names. Reuse this exact set across the user's other project files for the compounding-skill effect — if you've seen their other files, match that vocabulary. +- **`description`** → keep the bullet format (it's the pipeline's convention), but rewrite each bullet on the STAR pattern: **front-load the primary keyword**, active verb, specific tech, **then a quantified outcome**. Weave ~15–25 searchable keywords across the set naturally — no stuffing, no filler buzzwords. Every bullet that has a confirmed metric ends on it. +- **`associated-with`** → keep unchanged. -Output in this exact shape: - -``` -PROJECT NAME: -[name — role | tech · tech · tech] - -ASSOCIATED WITH: [experience entry] -DATE: [start] – [Present/end] ONGOING: [yes/no] -URL: [link] - -DESCRIPTION: -[three-part description, 150–300 words] - -SKILLS (consistent closed set): -• … • … • … • … • … - -MEDIA TO ATTACH: [specific recommendation] -``` - -Then provide **two title variants** (one keyword-maximal, one more readable) so the user can pick. +Show the **full rewritten YAML in a fenced block first** for review, plus a one-line note on each title variant if you're torn between a keyword-maximal and a more readable version. Then **write it back to `$ARGUMENTS` in place** (preserving key order and the `description: |` block scalar). If the user prefers a non-destructive write, save to a sibling `*.enhanced.yml` instead — ask only if ambiguous. --- -## Phase 3 — Validate against the checklist +## Phase 3 — Validate and report gaps -End with a quick pass/flag against each item. Mark ✅ / ⚠️ and be honest about gaps rather than papering over them: +Pass/flag each item (✅ / ⚠️), honestly: -- Project Name embeds role + top 2–3 tech keywords -- Description opens with the primary keyword in sentence one -- At least one quantified outcome (and it's a *real* number the user confirmed) -- URL points to repo / live demo / docs -- Media thumbnail recommended -- 4–6 skills from a consistent closed vocabulary -- Correct Experience/Education association + ongoing flag -- Reads naturally to a human — no keyword stuffing, no filler buzzwords +- `title` embeds product + role + top 2–3 tech keywords (no generic anti-pattern phrasing) +- First bullet opens with the primary keyword +- Each bullet carries a **real, user-confirmed** quantified outcome (or is explicitly flagged as qualitative) +- `project-url` present and pointing at repo/live/docs +- `skills` is a consistent closed set of 4–6 canonical names +- `associated-with` resolves and the date context is coherent +- Reads naturally to a human — no keyword stuffing -If any item is ⚠️, say exactly what the user needs to supply to close it. Do not silently fill the gap. +For every ⚠️, state exactly what the user must supply to close it. Do not silently fill the gap, and do not overwrite the file with an invented number to make a box go green.