tex/cv
1
0
Fork 0
mirror of https://github.com/prdlk/cv.git synced 2026-08-02 17:31:41 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(linkedin-project): clarify YAML-driven workflow and enhance documentation for linkedin project entry

Browse Source
This commit is contained in:
Prad Nukala
2026-06-30 10:41:23 -04:00
parent f9243b4cfe
commit d6b4b21d72
1 changed files with 62 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.claude/commands/linkedin-project.md
+62 -76
View File
@@ -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). 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: [project name | repo path | repo URL | one-line description] argument-hint: [path/to/project.yml]
allowed-tools: Read, Glob, Grep, Bash(git log:*), Bash(git remote:*), Bash(cat:*), Bash(ls:*), Bash(jq:*) 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)
<!--toc:start--> <!--toc:start-->
- [Enhance LinkedIn Project Entry](#enhance-linkedin-project-entry) - [Enhance LinkedIn Project Entry (YAML-driven)](#enhance-linkedin-project-entry-yaml-driven)
- [Phase 0 — Ground yourself (silent, fast)](#phase-0-ground-yourself-silent-fast) - [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 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 2 — Rewrite the YAML (same schema)](#phase-2-rewrite-the-yaml-same-schema)
- [Phase 3 — Validate against the checklist](#phase-3-validate-against-the-checklist) - [Phase 3 — Validate and report gaps](#phase-3-validate-and-report-gaps)
<!--toc:end--> <!--toc:end-->
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 > $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) 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.
- `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) ## 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** **Batch A — Title, role, status**
1. One sentence: what is this project and what problem does it kill? 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. Your exact role (Founder, Lead Engineer, Protocol Engineer, Contributor…) and solo vs. team — if team, what did *you personally* own? 2. Solo or team? If team, which of these description bullets did *you personally* own vs. direct?
3. Status: shipped / in-progress / archived? Live URL or testnet/mainnet? 3. Is this ongoing (no end date) or did it end? (Drives the Present/end flag.)
4. Which **Experience or Education entry** should this attach to, and the date range (and is it ongoing)?
**Batch B — Stack, architecture, hard problems** **Batch B — Stack + the hard problems (confirm, don't re-list)**
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. 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.)
6. The 1–3 *non-obvious* architecture decisions or hard problems you solved (the things a knowledgeable reader would respect). 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.
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)** **Batch C — Quantified outcomes (push hardest here)**
8. Any external traction? (users, transactions, partners, downloads, stars.) 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.
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. 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: - **`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").
`[Product/Initiative] — [Role] | [Tech 1] · [Tech 2] · [Tech 3]` - **`start`** → keep. Add an `end:` field only if the project ended; otherwise it reads as Present.
Embed role-title language + top 2–3 keyword technologies. No vague six-word titles, no "innovative/passionate." - **`project-url`** → keep (this is the proof-of-work link).
- **Description = keyword-density engine, 150–300 words, three parts:** - **`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.
1. One sentence — what it is + core technical premise (front-load the primary keyword in sentence one). - **`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.
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). - **`associated-with`** → keep unchanged.
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: 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.
```
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 ## 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 - `title` embeds product + role + top 2–3 tech keywords (no generic anti-pattern phrasing)
- Description opens with the primary keyword in sentence one - First bullet opens with the primary keyword
- At least one quantified outcome (and it's a *real* number the user confirmed) - Each bullet carries a **real, user-confirmed** quantified outcome (or is explicitly flagged as qualitative)
- URL points to repo / live demo / docs - `project-url` present and pointing at repo/live/docs
- Media thumbnail recommended - `skills` is a consistent closed set of 4–6 canonical names
- 4–6 skills from a consistent closed vocabulary - `associated-with` resolves and the date context is coherent
- Correct Experience/Education association + ongoing flag - Reads naturally to a human — no keyword stuffing
- 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. 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.