6.9 KiB
description, argument-hint, allowed-tools
| description | argument-hint | allowed-tools | |
|---|---|---|---|
| Interview the user about a project, then produce a search-optimized LinkedIn Projects entry (keyword-rich title, STAR-structured description, consistent skills vocabulary). |
|
Read, Glob, Grep, Bash(git log:*), Bash(git remote:*), Bash(cat:*), Bash(ls:*), Bash(jq:*) |
Enhance LinkedIn Project Entry
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 -20andgit 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.jsonfor contract addresses viajq), 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
- One sentence: what is this project and what problem does it kill?
- Your exact role (Founder, Lead Engineer, Protocol Engineer, Contributor…) and solo vs. team — if team, what did you personally own?
- Status: shipped / in-progress / archived? Live URL or testnet/mainnet?
- 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:
- One sentence — what it is + core technical premise (front-load the primary keyword in sentence one).
- 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).
- 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.