GitHub to LinkedIn

Purpose

Turn a repository into a LinkedIn narrative grounded in what the code actually shows. Repositories are evidence: the README states intent, the tree shows architecture, the tests show what the author feared, the commits show how the work really went. This skill reads that evidence and finds the story worth telling, or reports honestly when there is not one yet.

When to use this skill

• The user shares a repo URL or pastes repo content and wants a post
• The user wants to know "is my repo interesting enough to post about"
• The user wants to write about an open-source project they maintain or contributed to
• The user says "turn my repo into a post", "write about this GitHub project", or similar

Required inputs

One of the following, in descending order of usefulness:

1. A repository URL, if the agent can actually fetch and read it
2. Pasted README plus a file tree
3. Pasted README alone
4. The user's description plus key file names

If the agent cannot fetch the repo, it asks for pasted content instead of guessing. Everything used in the narrative must have been actually read.

Optional inputs

• Commit history or commit messages (only if actually provided or fetched)
• Test names or coverage notes
• Deployment setup (CI files, Dockerfiles, IaC)
• The user's role: author, contributor, or neither
• What the user is proudest of (useful signal, still verified against the code)

Workflow

1. Read the evidence. Work through what is available:
   • README: stated purpose, setup complexity, claimed features
   • Tree and file names: architecture signals (modular vs monolith, presence of tests, CI, docs, packaging)
   • Code, if readable: the interesting mechanism, error handling, design choices at module boundaries
   • Commits, if available: how the work went (renames, reverts, message quality) without quoting them out of context
2. Find the post-worthy core. Rank candidates:
   • A non-obvious engineering decision and its rejected alternative
   • A problem the repo solves that the user can describe concretely
   • A technical lesson visible in the code (the test suite's shape, the abstraction boundary)
   • An honest origin story ("scratch my own itch") If nothing ranks, say so. "Your repo isn't ready to be written about, here's what would make it post-worthy" is a valid deliverable.
3. Triage. KNOWN: what the repo and user directly show. INFERRED: interpretations of the code ("storage sits behind an interface, which suggests the author wanted swappable backends" only when the interface exists). UNKNOWN: stars, forks, adoption, external usage, production deployments, community size.
4. Draft per technical-storytelling.md, at 100 to 250 words, leading with the post-worthy core, not with "I open-sourced a new project".
5. Run the quality check (below), including the GitHub-specific fabrication scan.
6. Deliver the post, the audit, and, when relevant, one line of repo-improvement advice ("your README doesn't show the interesting part; lead with it").

Truth and credibility rules

• Full triage per credibility-rules.md before drafting.
• GitHub-specific protected facts: stars, forks, contributors, issues, pull requests, trending status, downloads, dependents. None may be invented, estimated, or rounded. If the user states them, they may be used with the user's context.
• Never claim "production-tested", "battle-tested", or "used at scale" unless the user has stated the production usage.
• Never invent commit activity ("after 200 commits across 6 months") unless the counts are KNOWN.
• If the agent read only the README, the narrative stays at README depth and says nothing about code internals it did not see.
• Contribution claims match the user's actual role: "maintainer", "contributed the Redis store", "fan who liked it" are different and non-interchangeable.

Writing rules

• Default voice per voice-guide.md; 100 to 250 words.
• Lead with the most interesting true thing about the repo, which is rarely its existence.
• Write the stack in one line; write the one interesting mechanism in three or four.
• Include the repo link near the end; the first two lines must earn the click without it.
• Banned: "I'm excited to open-source", "passion project" (unless the user said it), "labor of love", "feature-rich", "enterprise-ready", "production-grade" (unverified).

Output format

[The post, ready to copy]

[What the analysis found]
Evidence used: <README / tree / code / commits / user statements>
Post-worthy core: <the chosen angle, one line>
Runners-up: <other angles, one line each>

[Information audit]
KNOWN: ...
INFERRED: ...
UNKNOWN (not claimed): stars, forks, adoption, ... <list explicitly>

Worked example

Input (summary): the user pastes a README and file tree for go-rlimiter, a token-bucket rate limiter library in Go. README states: zero dependencies beyond the standard library, in-memory store by default, optional Redis via a small interface. Tree shows limiter.go, store.go, redis.go, *_test.go, benchmarks. User says: wrote it because existing libraries pulled dependency trees they didn't want to vendor; tests cover burst boundaries and clock skew; has 40 stars and doesn't want numbers in the post.

Output (the post):

Most Go rate-limiting libraries I tried came with a dependency tree I
didn't want to vendor.

So I wrote go-rlimiter: a token bucket limiter with zero dependencies
outside the standard library.

One design decision carries the library: storage sits behind a small
interface. In-memory by default; Redis if you implement three methods.
The limiter never imports a client.

The tests I care most about cover the boring failure modes: burst
boundaries and clock skew between nodes.

Repo: github.com/<username>/go-rlimiter

Delivery notes: the 40 stars were omitted at the user's request; the interface description is KNOWN (from README and store.go); "tests cover clock skew" is KNOWN from test names; no adoption language appears. Full walkthrough: examples/github-project.md.

Edge cases

• Empty or thin repository (README stub, no tests, two commits). Report that it is not post-worthy yet, with two or three concrete things that would make it so. Do not draft filler.
• Fork or heavily derivative project. Establish the user's actual contribution before drafting; the post credits upstream honestly.
• Work repo that must stay anonymous. Strip identifying details; if the interesting part cannot survive anonymization, decline.
• The agent can fetch the URL. Read it, then cite what was read. Fetching a profile page does not count as reading the code; do not describe internals from vibes.
• Controversial project. The skill writes about the engineering; it does not editorialize on the controversy the user did not ask about.
• Monorepo or huge codebase. Narrow to the module the user actually worked on and say which it is.

When NOT to use this skill

• The project is research: research-to-linkedin.
• The user wants a polished launch announcement with their own framing: project-post-writer may fit better; this skill is evidence-first.
• The user wants a full written case study: portfolio-storyteller.
• The repo is not the user's and they cannot verify claims about it: the skill drafts nothing beyond what is verifiable from the repo itself, and may recommend linking instead of paraphrasing.

Shared references

• ../../references/credibility-rules.md — the fact triage system; GitHub statistics are a protected category
• ../../references/technical-storytelling.md — the story spine
• ../../references/hooks.md — hook patterns, especially The Rejected Option and The Boring Choice

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