6.5 KiB
description, argument-hint, allowed-tools
| description | argument-hint | allowed-tools | |
|---|---|---|---|
| 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. |
|
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)
The argument is a path to a project YAML file:
$ARGUMENTS
The file follows this schema:
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)
- Read the YAML at
$ARGUMENTS. Capture every field; treatdescriptionas the source-of-truth content to refine, not discard. - Read
associated-with(resolve the relative path) to learn the role, company, and date context this project hangs off of. - Inspect
project-urlif it's a resolvable repo. Pull real signals:README,package.json/go.mod/Cargo.toml,git log --oneline -20, deploy artifacts (jqon anyrun-latest.jsonfor 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
- The current
titleis 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, …)? - Solo or team? If team, which of these description bullets did you personally own vs. direct?
- 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 anend: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:
titleembeds 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-urlpresent and pointing at repo/live/docsskillsis a consistent closed set of 4–6 canonical namesassociated-withresolves 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.