LinkedInOptimizer - GitLite

KO | EN

gitlite — search

#large-language-models #editor #kubernetes #developer-tools #generative-ai #open-source #golang #ai-agents #automation #anthropic

LinkedInOptimizer

(★ 13)

Claude Cowork Skill für professionelle LinkedIn-Profilanalyse: Gewichtetes Scoring (0–100), Headline/About-Optimierung, Banner-Erstellung (1584×396px), Content-Strategie, Wettbewerbsanalyse, SSI-Aktionsplan und PDF-Report. Evidenzbasiert auf LinkedIn-Algorithmus-Daten 2025/2026.

File Explorer

ZIP Download

- marketplace.json
- plugin.json
- - ci.yml
  - release.yml
- dependabot.yml
- BANNER.md
- COMPETITIVE.md
- ETHICS.md
- PHASE-1-discovery.md
- PHASE-2-scoring.md
- PHASE-3-wettbewerb.md
- PHASE-4-profil.md
- PHASE-5-banner.md
- PHASE-6-content.md
- PHASE-7-ssi.md
- PHASE-8-report.md
- SCORING.md
- SOURCES.md
- TEMPLATES.md
- UNTRUSTED.md
- build_skill_package.py
- check_descriptions.py
- check_hooks.py
- check_links.py
- check_sources.py
- check_versions.py
- create_banner.py
- generate_report.js
- - profile_high.json
  - profile_low.json
  - profile_mid.json
- - profile_high.json
  - profile_low.json
  - profile_mid.json
- run_eval.py
.gitignore
CHANGELOG.md
CLAUDE.md
index.html
LICENSE
README.md
requirements.txt
SECURITY.md
SKILL.md
VERSION

# Use via CDN

jsDelivr

jsDelivr serves any public GitHub repository as a CDN with zero setup. Pick a version and a file to get a ready-to-paste link and snippet.

Version

File

Link

Example

# Project Badges

CI Visit
Claude Skill Visit
License: MIT Visit

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

Ein Skill zur professionellen Analyse und Optimierung von LinkedIn-Profilen. Entwickelt für
Berater, Agenturen und Freelancer, die Kunden strategisch als Thought Leader positionieren und auf
das LinkedIn Top Voice Badge vorbereiten.

Acht Phasen, von der Datenerhebung bis zur Übergabe. Jede Zahl im Skill hat eine Quelle oder ist
als Erfahrungswert gekennzeichnet; was sich nicht belegen ließ, ist entfernt und gegen die Rückkehr
gesperrt.

Für den laufenden Betrieb danach, also Wochensystem, Content-Kalender, Community und
Monetarisierung, gibt es den Schwester-Skill
[linkedin-community-builder](https://github.com/GodModeAI2025/LinkedIn-Orchestrator).

## Was du sagen kannst

> „Analysiere mein LinkedIn-Profil und gib mir einen Score."

> „Optimiere meine Headline."

> „Erstelle mir ein LinkedIn-Banner."

> „Wie stehe ich gegen meine Wettbewerber da?"

> „Bin ich reif für ein Top Voice Badge?"

Der Skill führt durch die Phasen und fragt nach, was er nicht sehen kann.

## Installation

| Weg | Befehl |
|-----|--------|
| Claude Code (CLI, Desktop, IDE) | `/plugin marketplace add GodModeAI2025/LinkedInOptimizer`, dann `/plugin install linkedin-profil-optimierung@linkedin-optimizer` |
| claude.ai (Web) | Skills in der Seitenleiste → **Add from GitHub** → `GodModeAI2025/LinkedInOptimizer` |
| Release-Artefakt | siehe unten |
| Selbst gebaut | `python scripts/build_skill_package.py dist/linkedin-optimizer.skill` |

Der Skill liegt im Wurzelverzeichnis, nicht unter `skills/`. Claude Code lädt eine SKILL.md im
Plugin-Wurzelverzeichnis; `.claude-plugin/plugin.json` sagt es zusätzlich mit `"skills": ["."]`.

Das Release-Artefakt heißt `linkedin-optimizer.skill` und liegt am jeweils letzten Release:

```bash
curl -LO https://github.com/GodModeAI2025/LinkedInOptimizer/releases/latest/download/linkedin-optimizer.skill
```

Die Datei entweder in Claude Chat ziehen oder lokal auspacken:

```bash
unzip linkedin-optimizer.skill -d /path/to/skills/user/linkedin-profil-optimierung/
```

Im Archiv liegen SKILL.md, CHANGELOG.md, `references/` einschließlich der acht Phasendateien und SOURCES.md, `scripts/create_banner.py`, `scripts/generate_report.js`, LICENSE und requirements.txt. Landingpage, Workflows und die Repo-Werkzeuge `check_versions.py`, `check_sources.py` und `build_skill_package.py` sind nicht enthalten.

Aus einem Klon lässt sich dasselbe Archiv selbst bauen, ohne Netz und ohne GitHub:

```bash
python scripts/build_skill_package.py dist/linkedin-optimizer.skill
```

Das Skript setzt feste Zeitstempel und eine feste Reihenfolge und speichert unkomprimiert. Zwei Läufe liefern dieselben Bytes, auch auf verschiedenen Rechnern.

`scripts/create_banner.py` braucht Pillow ab 10.1: `pip install -r requirements.txt`. `scripts/generate_report.js` braucht das npm-Paket `docx`.

## Deliverables

| Deliverable | Beschreibung |
|-------------|-------------|
| Gewichteter Profil-Score | 10-Kategorie-Bewertung (0–100) nach dem Raster in references/SCORING.md |
| Wettbewerbsanalyse | Positionierungsmatrix auf zehn Achsen gegen 3–5 Nischen-Konkurrenten, Erhebungsrahmen in references/COMPETITIVE.md |
| Optimierte Headline | 3 Varianten mit SEO-Score, Zeichenzahl und Begründung |
| Optimierter About-Text | Orwell-inspiriert, strategische Hashtags, starker CTA |
| Banner | 1584×396px mit Safe-Zone-Validierung |
| Content Skill | Personalisierter Posting-Skill mit 10 Hook-Typen |
| Kommentar Skill | 5 Kommentar-Typen, 15–20 Ziel-Accounts |
| SSI-Aktionsplan | Social Selling Index Optimierung über 4 Säulen, aufgeteilt auf Tag 1–30, 31–60 und 61–90, je mit Hypothese und Messweg |
| DOCX-Report | Word-Dokument mit 9 Kapiteln, Scoring-Tabellen und 30/60/90-Tage-Roadmap |

## Verhältnis zum Schwester-Skill

Neben diesem Skill gibt es [LinkedIn-Orchestrator](https://github.com/GodModeAI2025/LinkedIn-Orchestrator) mit dem Skill `linkedin-community-builder`. Die beiden bleiben getrennt, weil sie verschiedene Aufgaben haben.

| | linkedin-profil-optimierung (dieses Repo) | linkedin-community-builder |
|--|--|--|
| Aufgabe | Einmalige Ist-Analyse und Profil-Artefakte | Laufender Betrieb über Wochen und Monate |
| Ergebnis | Score, Headline, About, Banner, Wettbewerbsmatrix, SSI-Plan, DOCX-Report | Wochensystem, Content-Kalender, Community, Analytics, Monetarisierung |
| Zeitform | Bestandsaufnahme mit Übergabe am Ende | Zustandsgesteuert, läuft weiter |
| Werkzeuge | Chrome-Plugin, Banner-Skript, Report-Template | Rein konversationell |

Beide reagieren heute auf dieselben Formulierungen: „Profil optimieren", „Profil verbessern", „Personal Branding", „Content-Strategie", „Top Voice". Das ist kein Schönheitsfehler, sondern führt dazu, dass Claude bei solchen Sätzen zwischen zwei Skills wählen muss. Die Auflösung steht im Abschnitt [Abgrenzung zum Schwester-Skill](SKILL.md#abgrenzung-zum-schwester-skill) in SKILL.md: Ist-Analyse und Artefakte hier, laufender Betrieb dort, bei beidem zuerst hier und danach Übergabe.

Der Orchestrator führt dieselbe Regel inzwischen in der Gegenrichtung, im Abschnitt „Abgrenzung zum Schwester-Skill" seiner `LinkedIn-Orchestrator/skills/linkedin-community-builder/SKILL.md`. Beide Beschreibungen im Frontmatter nennen den jeweils anderen Skill beim Namen und bleiben unter 400 Zeichen; `scripts/check_descriptions.py` prüft Länge, Strichzeichen und das Vorhandensein des Abgrenzungssatzes bei jedem Push. Was das Skript nicht sieht: ob die Abgrenzung inhaltlich stimmt.

## Was dieser Skill nicht tut

Der Skill positioniert Menschen öffentlich, unter ihrem Klarnamen. Deshalb schreibt er keine
Behauptung ins Profil, die der Kunde nicht belegen kann, und er baut keine Reichweite, die nicht
aus dem Interesse echter Leser entsteht. Das gilt auch dann, wenn ein Kunde ausdrücklich etwas
anderes beauftragt.

Abgelehnt wird: erfundene Titel, Rollen, Auszeichnungen oder Kundenzahlen; gekaufte Follower,
Reaktionen und Kommentare; Pods und abgesprochene Kommentar-Runden; Automatisierung von
Kontaktanfragen, Kommentaren oder Nachrichten; Fremdprofile über den Anlass hinaus.

Die Regeln stehen mit ihrer Begründung in [references/ETHICS.md](references/ETHICS.md), der
Abgleich vor der Übergabe in SKILL.md Phase 8.0. Was davon geprüft wird und was nicht, steht in
ETHICS.md unter „Was diese Seite nicht leistet": `tests/run_eval.py` bindet die gesperrten
CTA-Formulierungen an vier Fundstellen und prüft, dass der Abgleich in SKILL.md verankert ist.
Ob eine Angabe im Profil stimmt, ob der Kunde den Text gelesen hat und ob sich jemand im
Gespräch über eine Regel hinwegsetzt, sieht kein Skript.

## Datenbasis

Jede Zahl im Skill hat in [references/SOURCES.md](references/SOURCES.md) entweder eine Zeile mit Quelle, URL, Veröffentlichungs- und Abrufdatum, oder sie steht dort unter „Zurückgezogen“ und ist aus dem Skill entfernt. Stand: 04.09.2026, nächste Prüfung: 04.03.2027.

Belegt:

- Dwell Time ist ein Ranking-Signal im Feed (LinkedIn Engineering Blog, 12.05.2020).
- Das blaue Top-Voices-Badge wird nur auf Einladung vergeben, Nominierungen prüft LinkedIn quartalsweise (LinkedIn Help).
- Das goldene Community-Top-Voice-Badge ist seit dem 08.10.2024 zurückgezogen (LinkedIn Help).
- Der SSI besteht aus vier Säulen (LinkedIn Sales Blog, 03.08.2015). Die Aufteilung in je 25 Punkte bestätigt LinkedIn nicht.

Zurückgezogen, weil nicht belegbar: der genannte Plattformdurchschnitt der Engagement-Rate, die Engagement-Prozentwerte je Postformat, die Wirkungsfaktoren für Kommentieren und Kontaktanfragen, die Angabe zur Sichtbarkeitsdauer eines Beitrags, die branchenspezifische Benchmark-Zeile, die Rahmung des Punkterasters als Branchen-Benchmark und die Selbstbeschreibung des Skills als evidenzbasiert. Die vollständige Liste mit Begründung steht in SOURCES.md.

`scripts/check_sources.py` baut die Sperren gegen diese Aussagen aus der Spalte „Sperrmuster“ derselben Tabelle und läuft in der CI. Es prüft Schreibweisen, keine Aussagen. Ein Muster fängt die Zahl mit Komma und mit Punkt, das Prozentzeichen und das ausgeschriebene Wort, das geschützte Leerzeichen als HTML-Entity und das ASCII-x als Faktorzeichen. Ein frei formulierter Satz, der dieselbe Behauptung ohne die gesperrte Schreibweise aufstellt, fällt nicht auf. Jede Zeile der Tabelle trägt ein Muster; eine Zeile lässt sich über die Tabelle nicht von der Sperre befreien. Für die Behauptung, bei der ein reines Textverbot die richtigen Verneinungen im Skill mit treffen würde, kommt eine zweite Prüfung dazu: Ein Absatz, der „Collaborative Articles“ und ein Badge in einem Zug nennt, muss Q3 zitieren. Das hält einen neu formulierten Satz auf, der die Badge-Behauptung ohne Quelle wieder aufstellt. Wer die falsche Aussage mit der richtigen Quellenangabe hinschreibt, kommt weiterhin durch.

## Scoring

Die zehn Kategorien, ihre Gewichte und die Begründung je Gewicht stehen in [references/SCORING.md](references/SCORING.md#gewichtung). Dort liegt auch das [Engagement-Rate-Bewertungsraster](references/SCORING.md#engagement-rate-bewertungsraster) samt Berechnungsformel und die [Score-Interpretation](references/SCORING.md#score-interpretation), die einen Gesamtscore in einen Zeithorizont bis Top Voice übersetzt.

## Grenzen

- Es gibt kein Vorher-Nachher. Das Rechenbeispiel auf der Landingpage und in `references/SCORING.md` ist ein erfundenes Profil aus `tests/fixtures/`, keine Messung. Ein belastbares Vorher-Nachher braucht zwei datierte Messungen desselben Profils im Abstand von 60 bis 90 Tagen.
- LinkedIn blockiert web_fetch und web_search über robots.txt. Ohne das Chrome-Plugin bleibt die manuelle Eingabe, und die Datenqualität sinkt entsprechend.
- Impressions sind öffentlich nicht sichtbar. `scripts/generate_report.js` schätzt die Engagement-Rate deshalb aus der Follower-Zahl, während das Bewertungsraster in SCORING.md Impressions als Nenner voraussetzt. Der geschätzte Wert liegt systematisch höher, beide sind nicht direkt vergleichbar.
- Der DOCX-Report enthält keine Diagramme. Radar-Chart und Balkendiagramm sind in SCORING.md als Darstellungsform beschrieben, das Report-Template erzeugt sie nicht.
- Der Ausgabepfad in `scripts/generate_report.js` steht fest auf `/mnt/user-data/outputs/`, also auf die Sandbox von claude.ai. Für einen lokalen Lauf muss die letzte Zeile angepasst werden.
- Der SSI lässt sich nur mit Zugang zu linkedin.com/sales/ssi ablesen. Ohne Zugang wird er aus Profil-Signalen geschätzt und ist im Report als geschätzt zu kennzeichnen.
- `scripts/create_banner.py` braucht Pillow ab 10.1. Ältere Versionen wenden die angeforderte Schriftgröße nicht auf den Ersatz-Font an; die Safe-Zone-Messung ist dann nicht belastbar, und `--strict` bricht ab.
- requirements.txt nennt für Pillow nur eine Untergrenze, keinen Pin. Für das npm-Paket `docx` gibt es weiterhin keine package.json, seine Version ist damit offen.

## Fehlerbehebung

| Problem | Ursache |
|---------|---------|
| Der Skill springt nicht an | Nach der Installation eine neue Unterhaltung beginnen. Die Beschreibung wird beim Start gelesen. |
| Es kommt der andere LinkedIn-Skill | Beide reagieren auf ähnliche Sätze. Sag dazu, ob es um die einmalige Analyse oder um den laufenden Betrieb geht. |
| Die Profildaten bleiben leer | LinkedIn hat das Markup geändert oder die Chrome-Sitzung ist nicht angemeldet. Die Selektoren stehen in `references/PHASE-1-discovery.md`. |
| `create_banner.py` bricht ab | Pillow ist älter als 10.1, siehe requirements.txt. |
| `generate_report.js` wirft ENOENT | Der Ausgabepfad ist auf die claude.ai-Sandbox verdrahtet. Letzte Zeile anpassen. |

<details>
<summary><b>Für Entwickler: Struktur, Tests, Konventionen</b></summary>

## Ordnerstruktur

```
LinkedInOptimizer/
├── README.md                   # Diese Übersicht
├── SKILL.md                    # Router: Abgrenzung, Ressourcen, Ablauf, Gates
├── CHANGELOG.md                # Versionsgeschichte
├── CLAUDE.md                   # Regeln für Agenten, Pre-Push-Block, Invarianten
├── SECURITY.md                 # Bedrohungsmodell, Vertrauensgrenzen, bekannte Lücken
├── .claude-plugin/
│   ├── plugin.json             # Plugin-Manifest
│   └── marketplace.json        # Marketplace-Eintrag
├── VERSION                     # Quelle der Versionsnummer, alles andere ist Kopie
├── requirements.txt            # Pillow-Untergrenze für create_banner.py
├── LICENSE                     # MIT-Lizenz
├── index.html                  # Landingpage (GitHub Pages, Quelle ist der Repo-Root)
├── scripts/
│   ├── create_banner.py        # Banner-Generator mit Safe-Zone-Validierung
│   ├── check_versions.py       # Prüft die Versionsangaben gegen VERSION
│   ├── check_sources.py        # Prüft SOURCES.md und sperrt zurückgezogene Aussagen
│   ├── check_descriptions.py   # Länge, Strichzeichen und Abgrenzungssatz im Frontmatter
│   ├── check_hooks.py          # Zehn Hook-Namen in kanonischer Reihenfolge
│   ├── check_links.py          # Verweise im Skill, in der Doku und im Archiv
│   ├── build_skill_package.py  # Baut linkedin-optimizer.skill, reproduzierbar und offline
│   └── generate_report.js      # DOCX-Report-Template (Node.js, npm-Paket docx)
├── references/
│   ├── PHASE-1-discovery.md    # Phase 1: Datenerhebung, Interview, SSI
│   ├── PHASE-2-scoring.md      # Phase 2: Scoring und Gap-Analyse
│   ├── PHASE-3-wettbewerb.md   # Phase 3: Wettbewerbsanalyse
│   ├── PHASE-4-profil.md       # Phase 4: Headline, About, Quick Wins
│   ├── PHASE-5-banner.md       # Phase 5: Banner-Erstellung
│   ├── PHASE-6-content.md      # Phase 6: Content- und Kommentar-Strategie
│   ├── PHASE-7-ssi.md          # Phase 7: SSI-Massnahmenplan
│   ├── PHASE-8-report.md       # Phase 8: Ethik-Abgleich, Report, Uebergabe
│   ├── SCORING.md              # Gewichtete Bewertungsmatrix mit Sub-Kriterien und Bewertungsraster
│   ├── SOURCES.md              # Quellen mit Datum, zurückgezogene Zahlen, Prüfrhythmus
│   ├── ETHICS.md               # Ethische Leitplanken, gesperrte CTA-Formulierungen, Ethik-Abgleich
│   ├── COMPETITIVE.md          # Erhebungsrahmen der Wettbewerbsanalyse: Auswahlregel, zehn Achsen, Ausgabe
│   ├── TEMPLATES.md            # Vorlagen für Headline, About, Content, Kommentare
│   ├── UNTRUSTED.md            # Erhobener Seitentext ist Daten, nie Anweisung
│   └── BANNER.md               # Technische Banner-Anleitung mit Viewport-Matrix
├── tests/
│   ├── fixtures/               # Drei frei erfundene Profile als JSON
│   ├── expected/               # Erwartete Score-Bänder je Fixture
│   └── run_eval.py             # Eval-Runner, prüft Matrix, Namen und Bänder
└── .github/workflows/
    ├── ci.yml                  # Syntax, Banner, Versionen, Trigger, Quellen, Hooks, Eval, Paket
    ├── dependabot.yml          # Hält die Actions monatlich aktuell
    └── release.yml             # Hängt das Artefakt an ein Tag v*
```

## Tests

```bash
python tests/run_eval.py
```

Der Runner liest das Gewichtsmodell aus `references/SCORING.md` und prüft damit drei erfundene
Profil-Fixtures gegen erwartete Score-Bänder. Er stellt außerdem sicher, dass die zehn Kategorien
in SCORING.md, SKILL.md, auf der Landingpage und in `scripts/generate_report.js` wortgleich
heißen, dass die 18 Profil-Elemente aus der Checkliste in SCORING.md in derselben Reihenfolge in
SKILL.md Phase 4.3 und in der Audit-Tabelle des Report-Generators stehen, dass die Zahlen der
Scoring-Engine auf der Landingpage aus `tests/fixtures/profile_mid.json` stammen und dass die
Landingpage den Dialog als Beispiel ausweist und die Fixture dazu nennt.

Seit v2.5.0 kommen drei Bindungen dazu: die vier gesperrten CTA-Formulierungen aus
`references/ETHICS.md` stehen vollständig an allen vier Stellen, die dieselbe Liste führen; die
zehn Achsen der Wettbewerbsmatrix stehen in `references/COMPETITIVE.md` und in SKILL.md Phase 3.1
in derselben Reihenfolge, und die Mindestzahl der Wettbewerber lautet überall gleich; der
Maßnahmenplan läuft an allen vier Stellen über Tag 1–30, 31–60 und 61–90, und die abgelösten
Horizonte dürfen nicht danebenstehen. Alle drei prüfen Schreibweisen und Listen. Was sie nicht
sehen, steht in den beiden Referenzdateien jeweils im letzten Abschnitt.

Die Fixtures sind frei erfunden, nicht anonymisiert. Ein reales Profil zu erheben und danach zu
verfremden wäre genau die Datenverarbeitung, die SECURITY.md einschränkt.

Ein echter Lauf lässt sich gegen dieselben Bänder prüfen:

```bash
python tests/run_eval.py --fixture profile_mid --result lauf.json
```

## Roadmap

Offene Punkte, ohne Termin:

- package.json für `docx`, dazu gepinnte Versionen statt der Untergrenze in requirements.txt.
- Ausgabepfad des Report-Templates konfigurierbar machen, statt ihn auf die claude.ai-Sandbox zu verdrahten.
- Fehlerfälle Rate Limit beziehungsweise LinkedIn-Checkpoint und geänderte DOM-Struktur in der Fehlerbehandlung ergänzen.

</details>

## Version

Die Versionsnummer steht in der Datei `VERSION`. README, SKILL.md, Landingpage und Report-Template führen sie als Kopie; `scripts/check_versions.py` vergleicht sie bei jedem Push gegen `VERSION` und schlägt bei Abweichung fehl. Der Release-Workflow prüft zusätzlich, dass der Tagname zu `VERSION` passt.

Aktuelle Version: v2.6.0. Was sich je Version geändert hat, steht in [CHANGELOG.md](CHANGELOG.md).