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