mirror of
https://github.com/prdlk/cv.git
synced 2026-08-02 17:31:41 +00:00
100 lines
6.5 KiB
Markdown
100 lines
6.5 KiB
Markdown
---
|
||
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: [path/to/project.yml]
|
||
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 (YAML-driven)
|
||
|
||
<!--toc:start-->
|
||
- [Enhance LinkedIn Project Entry (YAML-driven)](#enhance-linkedin-project-entry-yaml-driven)
|
||
- [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 2 — Rewrite the YAML (same schema)](#phase-2-rewrite-the-yaml-same-schema)
|
||
- [Phase 3 — Validate and report gaps](#phase-3-validate-and-report-gaps)
|
||
<!--toc:end-->
|
||
|
||
The argument is a path to a project YAML file:
|
||
|
||
> $ARGUMENTS
|
||
|
||
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 — Parse and ground (silent, fast)
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
---
|
||
|
||
## Phase 1 — Interview (ask, then STOP and wait)
|
||
|
||
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 — Title, role, status**
|
||
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. Solo or team? If team, which of these description bullets did *you personally* own vs. direct?
|
||
3. Is this ongoing (no end date) or did it end? (Drives the Present/end flag.)
|
||
|
||
**Batch B — Stack + the hard problems (confirm, don't re-list)**
|
||
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.)
|
||
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.
|
||
|
||
**Batch C — Quantified outcomes (push hardest here)**
|
||
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.
|
||
7. I need at least one number you can stand behind per bullet, or that bullet stays qualitative. Which can you back?
|
||
|
||
**Hard rule:** no real metric → no invented metric. Flag it in Phase 3 instead.
|
||
|
||
---
|
||
|
||
## Phase 2 — Rewrite the YAML (same schema)
|
||
|
||
Transform each field, preserving the structure:
|
||
|
||
- **`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").
|
||
- **`start`** → keep. Add an `end:` field only if the project ended; otherwise it reads as Present.
|
||
- **`project-url`** → keep (this is the proof-of-work link).
|
||
- **`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.
|
||
- **`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.
|
||
- **`associated-with`** → keep unchanged.
|
||
|
||
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.
|
||
|
||
---
|
||
|
||
## Phase 3 — Validate and report gaps
|
||
|
||
Pass/flag each item (✅ / ⚠️), honestly:
|
||
|
||
- `title` embeds product + role + top 2–3 tech keywords (no generic anti-pattern phrasing)
|
||
- First bullet opens with the primary keyword
|
||
- Each bullet carries a **real, user-confirmed** quantified outcome (or is explicitly flagged as qualitative)
|
||
- `project-url` present and pointing at repo/live/docs
|
||
- `skills` is a consistent closed set of 4–6 canonical names
|
||
- `associated-with` resolves and the date context is coherent
|
||
- Reads naturally to a human — no keyword stuffing
|
||
|
||
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.
|