diff --git a/.claude/commands/linkedin-project.md b/.claude/commands/linkedin-project.md new file mode 100644 index 0000000..38a7dee --- /dev/null +++ b/.claude/commands/linkedin-project.md @@ -0,0 +1,113 @@ +--- +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:*) +--- + +# Enhance LinkedIn Project Entry + + +- [Enhance LinkedIn Project Entry](#enhance-linkedin-project-entry) + - [Phase 0 — Ground yourself (silent, fast)](#phase-0-ground-yourself-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) + + +You are optimizing a single LinkedIn **Projects** entry for maximum search visibility and recruiter/investor conversion. The seed for this project is: + +> $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. + +--- + +## Phase 0 — Ground yourself (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: + +- `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. + +--- + +## 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. + +**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 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 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. + +**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. + +--- + +## Phase 2 — Produce the entry + +Apply these principles (highest-leverage first): + +- **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). + +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. + +--- + +## Phase 3 — Validate against the checklist + +End with a quick pass/flag against each item. Mark ✅ / ⚠️ and be honest about gaps rather than papering over them: + +- 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 + +If any item is ⚠️, say exactly what the user needs to supply to close it. Do not silently fill the gap.