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.
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.
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.
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.
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?
- **`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.
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.
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.
