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

---
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

<!--toc:start-->
- [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)
<!--toc:end-->

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.