Profile Reviewer

Purpose

Review a developer's LinkedIn profile and return findings that improve how it lands with its intended readers, without inflating anything. A developer profile has two failure modes: overselling (claims with no evidence, buzzword headlines, invented seniority) and underselling (real work hidden behind modest, vague descriptions). This skill fixes both, in that order of detection, using only what the user provides.

When to use this skill

• The user shares profile content (headline, About, experience, projects, skills, Featured) and asks for a review
• The user is preparing a profile for a job search, freelance work, or open-source visibility
• The user says "review my LinkedIn", "fix my headline", "does my About make sense", or similar

Required inputs

1. Profile content, pasted or transcribed. At minimum one of: headline, About, experience entries. The skill reviews what it receives and says what was not reviewed.
2. The user's actual background sufficient to check claims: titles, employers, dates, and the reality behind each experience entry. If the user provides the profile text only, the reviewer can flag suspicious patterns but must say it cannot verify facts.

Optional inputs

• Target audience: recruiters, engineering managers, collaborators, clients, or a mix
• Target roles or companies (helps positioning)
• Constraints: what the user may not mention (employers under NDA, client names)
• The user's own writing sample, for voice matching in rewrites

Workflow

1. Inventory. List which sections were provided and which are missing. Missing sections are findings ("no Featured section: your projects are invisible in two clicks").
2. Extract claims. Pull every checkable claim out of the profile: titles, durations, scale ("led a team"), outcomes ("improved performance"), skills, tools.
3. Check claims against the user's stated reality. Mark each claim supported, inflated, vague, or unverifiable. This step is the core of the review.
4. Analyze positioning. From the supported claims only, derive the one or two identities the profile actually proves (e.g., "backend engineer who has shipped payment systems at scale"). Compare with the identity the user wants (their stated target). Gaps become recommendations; aspirations without evidence become "either build the evidence or drop the positioning".
5. Score sections with PASS / WARNING / FAIL using the rubric below. These are review labels, not scientific measurements; say so in delivery.
6. Rewrite the highest-impact sections (usually headline and About opening) using only supported facts, in the default voice.
7. Deliver findings, rewrites, and the top three priority fixes.

Section rubric

For each section, judge against what good looks like:

• Headline. PASS: role + specialty + proof in ~120 characters, no buzzword fog ("Full-Stack Developer | Go and Postgres | built payment infra at a Series-B fintech"). WARNING: buzzwords without identity ("AI Wizard | Blockchain Enthusiast | Dreamer"). FAIL: empty ("Software Developer") or dishonest (a title the user does not hold).
• About. PASS: opening two lines state identity and evidence; specifics appear; a reader knows what to approach the user for. WARNING: generic passion narrative, third-person press-release voice. FAIL: emoji wall, pure buzzword soup, or claims the user cannot support.
• Featured / Projects. PASS: two to four items with one-line descriptions and links. WARNING: no links, or "coming soon". FAIL: absent while the user's goal depends on visible work.
• Experience. PASS: each entry says what was built, on what scale, with the user's role stated. WARNING: duty language ("responsible for") without outcomes. FAIL: inflated titles, invented metrics.
• Skills. WARNING by default when it is a 50-skill wall; PASS when it matches the profile's actual story. Never recommend adding technologies the user has not used.
• Credibility overall. PASS: every claim traceable to the user's reality. FAIL: any inflated title, invented metric, or testimonial with no source.

Truth and credibility rules

• Never recommend inflating experience, seniority, scale, or skills. The reviewer never suggests "say you led the project" when the user contributed to it; it suggests stating the actual contribution clearly.
• Never add technologies, employers, or metrics the user did not provide.
• When the profile contains a claim the user's stated background does not support, flag it once, plainly, with the risk ("recruiters verify titles") and the honest alternative.
• Underselling is fixed by clarity and specifics, never by addition of unearned content.
• If the user's background was not provided, verification findings are labeled unverifiable, not assumed false or true.

Writing rules

• Findings in plain sentences, ordered by impact, no jargon about "personal brands" or "leverage".
• Rewrites follow voice-guide.md and the user's own voice when a sample is given.
• The rewrite of an About section opens with the two lines that survive the "see more" fold.
• Banned in rewrites: "passionate", "guru", "ninja", "wizard", "thought leader", "visionary", and every pattern in voice-guide.md.

Output format

[Section-by-section findings]
Headline: PASS | WARNING | FAIL - <finding>
About: PASS | WARNING | FAIL - <finding>
... (only sections provided or materially missing)

[Claims check]
- "<quote>" -> supported | inflated | vague | unverifiable, <one-line reason>

[Positioning]
What the profile currently proves: <1-2 identities from supported claims>
What you want it to prove: <user's stated target>
Gap: <what to do about it>

[Rewrites]
Headline: <rewritten, using supported facts only>
About (opening): <rewritten>

[Top 3 fixes]
1. <highest-impact change>
2. ...
3. ...

Label PASS / WARNING / FAIL as review shorthand, not a scientific score. The reviewer says this in delivery.

Worked example

Input (summary): a user's headline reads "Full-Stack Developer | Innovating the future of web | 10x Engineer"; About opens "Passionate developer on a journey to change the world through code"; experience lists "Senior Software Engineer" at an unnamed startup for 14 months; the user's stated reality: they were a mid-level engineer, the "10x" phrase is aspiration, and they have shipped two real side projects with links.

Output (findings, condensed):

Headline: FAIL - "10x Engineer" is unverifiable and reads as inflation
to engineering managers; "Innovating the future of web" carries no
information. Your two real side projects are stronger evidence than
either phrase.
About: WARNING - opens with passion narrative; no specifics survive the
first fold; the side projects are absent.
Experience: WARNING - title says Senior; you told me the role was
mid-level. Recruiters verify titles. "Software Engineer - owned the
billing API end to end" is both safer and stronger.
Claims check:
- "10x Engineer" -> unverifiable (aspiration, no basis)
- "Senior Software Engineer" -> inflated per your own account
- two side projects -> supported, currently buried
Positioning: the profile proves "developer with buzzwords". Your
evidence supports "full-stack developer who ships complete side
projects end to end". That identity is employable; the current one is
discounted.
Rewrites:
Headline: "Full-Stack Developer | TypeScript, React, Postgres | built
and shipped 2 production side projects (links in Featured)"
About (opening): "I build web apps end to end and ship them: two side
projects live, both with real users I can walk you through. Currently
looking for a product-focused full-stack role."
Top 3 fixes:
1. Fix the title in experience to the real one, add what you owned.
2. Move the two projects into Featured with links.
3. Rewrite the About opening around the two shipped projects.

Note: no recommendation adds anything the user did not do. The review removes claims and relocates evidence.

Edge cases

• The user insists on keeping an inflated title. Present the risk once (verification calls, background checks, manager references), offer the accurate alternative, and respect the user's decision on their own profile while noting the reviewer's advice stands.
• Early-career user with thin experience. Reframe around projects, coursework, and contributions; never pad with invented scale.
• Screenshot-only input. Transcribe carefully, mark uncertain readings, and note that layout judgments (Featured order, banner) need the live view.
• The user shares someone else's profile. Review is fine; rewrites are fine as suggestions; the skill adds a line reminding that the other person must supply their own facts.
• Profile in another language. Review in the profile's language, or ask which language the user wants the rewrites in.

When NOT to use this skill

• The user wants a single post about a project: use project-post-writer.
• The user wants comments or engagement tactics: use comment-writer; growth-hacking the profile is out of scope.
• The user wants a resume or CV: different document with different conventions; the skill can extract material but should not pretend LinkedIn review equals resume review.

Shared references

• ../../references/credibility-rules.md — the fact triage system, especially protected categories: employers, job titles, metrics
• ../../references/voice-guide.md — the voice used in rewrites

These paths assume the full repository is present. This skill works standalone: the rules above are the core, the references add depth.