Linkedin description based on Commits

linkedin-work-history-skill.txt

---
name: linkedin-description
description: Generate a LinkedIn work history description from git commit history. Extracts all commits by a given author, analyzes contribution types, third-party integrations, tech stack, and produces a polished summary. Use when the user says "linkedin description", "/linkedin-description", "summarize my work", "work history", "describe my contributions", or wants to generate a professional summary of their git contributions for a resume or LinkedIn profile.
---

# LinkedIn Description Generator

Analyze a git repository's commit history for a specific author and produce a comprehensive, LinkedIn-ready work summary.

## Workflow

### 1. Identify the author

Ask the user for the author email, or detect it from git config:

```bash
git config user.email
```

If the user provides an email, use that. Otherwise confirm the detected email before proceeding.

### 2. Gather commit data

Run these in parallel to understand scope:

```bash
# Total commits
git log --author="<EMAIL>" --oneline | wc -l

# Date range
git log --author="<EMAIL>" --format="%ai" | tail -1
git log --author="<EMAIL>" --format="%ai" | head -1

# Commits per year
git log --author="<EMAIL>" --format="%ad" --date=format:"%Y" | sort | uniq -c | sort -rn

# Total lines changed
git log --author="<EMAIL>" --shortstat --format="" | awk '{ins+=$4; del+=$6} END {print "Insertions:", ins, "Deletions:", del}'
```

### 3. Extract all commit messages

```bash
git log --author="<EMAIL>" --format="%ad | %s" --date=short
```

Read the full output — every commit message matters for the analysis.

### 4. Analyze and categorize

From the commit messages, identify and organize:

- **Contribution types** — Group commits into logical categories (e.g., integrations, bug fixes, infrastructure upgrades, frontend work, performance optimization, DevOps, etc.). Name each category descriptively and list specific work under each.
- **Third-party services & products** — Every external company, API, or product mentioned in commits. Organize by category (logistics, payments, CRM, communication, monitoring, etc.) in a table.
- **Technology stack** — Languages, frameworks, databases, infrastructure, CI/CD, and tools evident from the commits.
- **Key achievements** — Major migrations, new systems built from scratch, architectural changes.

### 5. Generate the output file

Write a markdown file (default: `<author-name>.md` in the repo root) containing these sections in order:

1. **Header** — Author name, period, total commits, lines added/removed, repo description
2. **Role Summary** — A single LinkedIn-ready paragraph (3-5 sentences) describing the role at a high level
3. **Types of Contributions** — Numbered categories with detailed bullet points under each. Be specific — name the actual services, features, and systems worked on.
4. **Third-Party Services & Products** — Table with Category and Services columns
5. **Technology Stack** — Organized by layer (backend, frontend, infrastructure, etc.)
6. **Suggested LinkedIn Description** — **MUST be under 2,000 characters** (this is a hard LinkedIn platform limit). Include a character count. Pack the most impactful information into this space: lead with scope and key achievements, name specific technologies and integrations, and quantify where possible. Use line breaks and bold headers to maximize readability within the character budget.
7. **Footer** — Note that it was generated from git history analysis

### 6. Key principles

- **Be specific, not generic.** Don't say "worked on integrations" — say "built and maintained DoorDash, OnFleet, and TwinJet delivery logistics integrations including API clients, webhook processing, and driver tracking."
- **Quantify where possible.** Number of integrations, commits, years, providers, etc.
- **Identify the narrative.** Look for multi-commit arcs that tell a story (e.g., "built Salesforce sync from scratch over 2 years" rather than listing individual commits).
- **Distinguish building vs. maintaining.** If someone created an integration from scratch (API client, factories, webhook handler), call that out differently from bug fixes on existing integrations.
- **Read commit prefixes.** Prefixes like `PRD-`, `BUG-`, `INT-`, `DEV-`, `HOTFIX` reveal whether work was feature development, bug fixing, or incident response. Use this to characterize the role accurately.
- **Infer the product domain.** Use commit messages to understand what the company/product does and frame the summary in business terms, not just technical terms.
- **Keep LinkedIn descriptions professional but impactful.** Lead with the most impressive scope (e.g., "7+ third-party providers") and highlight breadth (full-stack, infrastructure, integrations).
- **Respect the 2,000 character limit.** LinkedIn truncates descriptions beyond 2,000 characters. The suggested description MUST fit within this limit. Always print the character count next to it so the user can verify.

### 7. Output location

Save the file to the repository root as `<author-first-name>.md` (e.g., `patrick.md`). If the user specifies a different path, use that instead. Tell the user where the file was saved.