GitHub Launch Kit

GitHub SEO and GEO in one pass: an Agent Skill that writes your repo's README, llms.txt, topics, and About description, and draws its animated SVG visuals

Runs in Claude Code, Codex, Cursor, and Zed on the open Agent Skills standard. No dependencies and no build step. Written for how people skim and for how AI answer engines pick what to cite.

Point your coding agent at a repo and say Build the GitHub.

---

GitHub Launch Kit is an Agent Skill that writes the part of a repository that isn't code: the README, the llms.txt, the GitHub topics, the About description, and the README's animated SVG visuals. You point your coding agent at a repo and say Build the GitHub. It reads the actual files, then runs five research lanes in parallel: how AI answer engines choose what to cite, how people scan a page, what people search for, who the real competitors are, and what evidence actually exists. It drafts every artifact in one house voice, then turns adversarial critics on its own draft and fixes what they find. It's built around a hard rule against inventing a statistic or a testimonial, and it makes the copy say what your project is not. It's built on the open Agent Skills standard, so it loads natively in Claude Code, Codex, Cursor, and Zed. It writes content only. It doesn't touch your source code and it doesn't push anything to GitHub.

🧩 What it builds

Artifact	What it is	Where it goes
README.md	The full page, hero to license, in one house voice	Repo root
llms.txt	A machine-readable summary and link map for AI systems	Repo root
Topics	Up to 20 lowercase tags, blended niche and high-volume	Repo settings
About	One line, roughly 120 to 160 characters, keywords first	Repo settings
SVG visuals	An animated banner and section graphics, like the ones on this page, in one metaphor with the copy	assets/ plus img tags in the README

CONTRIBUTING.md and release notes are optional extras. Ask for a subset and you get only that subset.

🎯 The problem

• Generated READMEs read generated. One pass, a feature list the model invented, an em dash every third sentence.
• Invented evidence gets noticed. A single made-up statistic or testimonial, once spotted, discredits the whole page.
• The boundary goes unstated. Vague overclaiming creates a disappointed user, which is exactly what a plain "it is not X" would have prevented.
• The README isn't the whole surface. Topics get indexed on GitHub's topic pages, llms.txt is built for AI systems to read, and the About line is what shows in search results. All three are usually an afterthought.

📄 What it produced for this repo

This page is the sample. The skill was run against its own repository. The About line and the topics below are its literal artifacts, and the README you're reading is the rest of that run.

About description

Agent Skill for GitHub SEO and GEO: writes your README, llms.txt, topics, and About line. Claude Code, Codex, Cursor, Zed. No rank promises.

Topics

github-seo ai-seo ai-coding-agents answer-engine-optimization generative-engine-optimization llms-txt readme-generator claude-code-skills documentation-generator openai-codex coding-agents cursor claude-skills agent-skills

The research lanes verify their sources at runtime and drop what they can't support. Three sets of claims were cut from this page for exactly that reason.

See what the research lanes returned and what got cut

Kept, because every figure was opened and confirmed at the source:

• Repository count: 630 million total projects and 395 million public repositories on GitHub (Octoverse, 2025)
• README content: 97% of files cover "what", 88.5% cover "how", and 25.7% cover "why" (Prana et al., 2019)
• AI search: 54.1% of developers put searching for answers top of the tasks now done mostly by AI (Stack Overflow, 2025)
• Package hallucination: 21.7% of packages referenced by open-source code-generating models don't exist (Spracklen et al., 2025)

Cut, because the source didn't hold up:

• Reading time: the claim that 39% of READMEs take under 10 seconds to read. The figure couldn't be confirmed in the paper it was attributed to, and its sample size collided suspiciously with a different study. Dropped.
• Citation uplift: per-feature percentages from a 2026 preprint. Two independent fetches of the same paper disagreed on the numbers. Dropped.
• Four statistics that existed only as characterizations inside another paper's literature review, never opened at their own source. Dropped.

⚡ Install

It's a folder of Markdown, so installing it means cloning it where your agent looks for skills.

# Claude Code
git clone https://github.com/NeuraCerebra-AI/github-launch-kit.git \
  ~/.claude/skills/github-launch-kit

# Codex, Cursor, or Zed
git clone https://github.com/NeuraCerebra-AI/github-launch-kit.git \
  ~/.agents/skills/github-launch-kit

Agent	Skills directory	Reference
Claude Code	~/.claude/skills/	docs
Codex	~/.agents/skills/	docs
Cursor	~/.agents/skills/ or ~/.cursor/skills/	docs
Zed	~/.agents/skills/	docs

GitHub Copilot and Gemini CLI implement the same standard, so check their docs for the directory they read. For a single project rather than every project, use that repo's own .claude/skills/ or .agents/skills/ instead.

For Cowork and claude.ai, enable the skill on your claude.ai account instead, from Customize in the Desktop app sidebar or from the skills settings on claude.ai. Those sessions load the skills enabled for your account at session start and don't read a skills directory on your machine (Claude Code docs).

Then open the repo you want to launch and type:

Build the GitHub

🔧 How it works

Phase 0 confirms with you which repository and which artifacts. Phases 1 through 6 are what runs after that.

The diagram shows phases 1 through 6 in order: read the repo, run five research lanes at the same time, merge them into one positioning brief, draft every artifact from that brief, send the draft to adversarial critics, and return to drafting until a critic pass comes back clean, at which point it delivers.

The five lanes are generative-engine optimization, attention science, keywords and topics, competitors, and citations. Each returns structured findings, and the brief settles any disagreement between them before a word gets drafted. The critics are separate agents told to falsify the draft rather than praise it, one per dimension: honesty, findability, structure, voice, and links. It stops when a full critic pass returns nothing material and a literal character search for the em dash returns zero.

Once the copy is clean, a visuals stage draws the animated SVG set. The banner and diagrams on this page are its output: built from the settled copy, in the document's one metaphor, and reviewed by a sixth critic that extends the em-dash search into the .svg files before anything is delivered.

Reference files load only when the phase that needs them starts, so a run that ends after Phase 1 never reads the other four.

🔎 What it does for SEO and GEO

Two kinds of reader find a repo now: search engines and the people using them, and generative engines like ChatGPT, Claude, Perplexity, and Google AI Overviews. The skill writes for both by default, and none of the moves below is a setting you configure. Worth saying up front: published research backs the generative-engine half. The search-engine half is ordinary content hygiene, and neither half is a ranking guarantee.

What it does	Why
Front-loads the real search terms in the first line and in image alt text	That's the text a crawler, an answer engine, and a skimming human all read first
Cites real sources, adds real statistics, adds real quotations	The GEO study's own conclusion: "including citations, quotations, and statistics can significantly boost source visibility"
Refuses to keyword stuff	Stuffing scored below the no-optimization baseline on the position and word-count metrics that study leads with
Reuses one canonical definition across the README and llms.txt	Any indexer or model then extracts the same facts wherever it reads
Phrases FAQ questions as the literal query someone types	Matches how the question actually arrives, from a person or from an AI
Weights topics toward specific niche tags	GitHub topic pages sort by stars, so a new repo is invisible on the big ones
Writes a keyword-first About line	That's the line GitHub shows in its own search results

The evidence, and its limits. On the study's own benchmark: "The best methods improve upon baseline by 41% and 28% on Position-Adjusted Word Count and Subjective Impression respectively." Keyword stuffing came in below doing nothing at all: "While widely used for Search Engine Optimization, we find such methods offer little to no improvement on generative engine's response." The authors then ran the same methods against Perplexity.ai, a deployed engine, where quotations gave "a 22% improvement over the baseline" and keyword stuffing "performs 19% worse than the baseline" (Aggarwal et al., "GEO: Generative Engine Optimization", KDD 2024).

Back on their own benchmark, the authors ran one more condition worth knowing about if your project is new. They optimized every competing source at once, incumbents included, and the gains still landed at the bottom of the ranking: "lower-ranked websites, which typically struggle for visibility, benefit significantly more from GEO". Citing sources raised a fifth-ranked source's visibility by 115.1% while the top-ranked source's fell by 30.3%. Their reading is that generative engines work from the content itself, so "the number of backlinks and domain presence, which are challenging for small creators to achieve", count for less (Aggarwal et al., KDD 2024).

Treat that last figure as one condition in one experiment, not a forecast for your repo. And the honest limit is the authors' own: "owing to the black-box nature of search engine algorithms, we didn't evaluate how GEO methods affect search engine rankings." This changes how your content reads to answer engines and to humans. It isn't a Google ranking service, it doesn't touch backlinks or domain authority, and every number above measures visibility inside a generated answer rather than a position on a results page.

⚖️ How it's different

Short version: if you want a README on a throwaway project in a hurry, readme.so is faster and free, and if you need generation inside a build pipeline, or on a local or offline model, readme-ai does that and this doesn't. What this does that they don't is produce the whole public surface from one researched pass, then attack it.

Verified against each project's own documentation in August 2026. Rows where this skill loses are included, because a table that only wins gets fact-checked in the comments.

	GitHub Launch Kit	readme-ai	readme.so / Best-README-Template	awesome-copilot create-readme	Asking Claude directly
Reads your actual repo	Yes	Yes	No	"Review the entire project and workspace", method unspecified	Only what you paste
Runs live web research	Yes	No	No	No	No
Writes llms.txt	Yes	No	No	No	No
Writes topics and About	Yes	No	No	No	No
Critiques its own draft	Yes	No	No	No	No
Requires a stated "what it is not"	Yes	No	No	No	No
Every statistic carries a live link	Yes	Not documented	You write them	Not documented	Not by default
Runs headless in CI	No	Yes	No	No	No
Runs outside Claude	Yes, in any Agent Skills host	Yes, any LLM provider including offline	Not applicable	Copilot only	Yes
Works on GitLab or Bitbucket	Topics and About are GitHub-only	Yes	Not applicable	No	Partly
Cost	Included in your agent's existing access	Your own API tokens	Free	Included in Copilot	Included in your agent's existing access

Dedicated llms.txt generators aren't in the table because they solve a different problem. The ones worth knowing about, Firecrawl's generator and Mintlify, build the file by crawling a live website rather than by reading a repository, so they suit a docs site and not a repo that has no site yet.

📊 Why this matters

Most READMEs answer what and how, then skip why. Across 393 randomly sampled repositories and 4,226 hand-annotated README sections, 97% of files explained what the project is and 88.5% explained how to use it, but only 25.7% explained why it exists (Prana et al., Empirical Software Engineering, 2019). Purpose is usually what makes a stranger care, and with 630 million total projects and 395 million public repositories on GitHub (GitHub Octoverse, 2025), there are a lot of strangers to lose.

A growing share of those readers isn't human. In Stack Overflow's 2025 survey, developers put searching for answers at the top of the tasks now done mostly by AI, at 54.1%, against 16.9% for writing code (Stack Overflow Developer Survey, 2025). That's why this skill writes an llms.txt next to the README, and why it follows the answer-engine research covered in the section above rather than SEO folklore.

Human readers skim rather than read. "79 percent of our test users always scanned any new page they came across; only 16 percent read word-by-word" (Nielsen, Nielsen Norman Group, 1997). That finding is why the first two words of every bullet on this page are bold.

Confident, plausible, nonexistent detail is the failure mode worth designing against. Across 576,000 generated code samples from 16 models, 21.7% of the packages that open-source code-generating models referenced did not exist, and at least 5.2% for commercial models (Spracklen et al., USENIX Security, 2025). Writing a README isn't the same task as generating code, so that number doesn't measure README accuracy. It measures how readily a model produces specifics that sound right and aren't, which is what the critique pass exists to catch.

🚧 What it doesn't do

• No code. It writes content about your repository. It never edits, refactors, or generates source code.
• No pushing. It hands back files and copy-paste blocks. You decide what lands, and it asks before writing anything into your repo.
• No promises about rank. The research it follows is correlational. It makes a page more findable and more credible, not guaranteed to rank.
• No guesswork. It works with what's in your repo and what it can verify online. A thin repo gets an honest, thin README.

It's also not a documentation site generator, not a badge designer, and not a substitute for actually having something worth launching.

❓ FAQ

What Claude skill writes my README? GitHub Launch Kit writes your README, and in the same run it writes your llms.txt, your GitHub topics, and your About description, and draws your README's animated SVG visuals. Install it into ~/.claude/skills/, open the repository, and say Build the GitHub. It works the same way in Codex, Cursor, and Zed, covered in the next question.

Does it work with Codex, Cursor, or Zed? It works with Codex, Cursor, and Zed natively. Agent Skills is an open standard that all of them implement, and this skill's frontmatter is just the two fields the spec requires, name and description, with no vendor-specific fields and no bundled code, so those tools pick it up with the same automatic discovery and on-demand file loading Claude Code gives it. Drop the folder in the directory from the table above. In an agent with no Skills support, the instructions still work if you point it at SKILL.md by hand; what you lose is the automatic triggering, not the method.

How do I make my GitHub repo discoverable? A GitHub repo becomes discoverable through four things search engines and AI answer engines read: a README that says why the project exists, an llms.txt written for AI systems, up to 20 GitHub topics weighted toward ones a new repo can actually rank on, and a keyword-first About description. GitHub Launch Kit produces all four from one research pass.

Does this actually help my SEO? It helps the half of SEO that lives in your content: the terms in your first line, your alt text, your headings, your topics, and an About line GitHub can index. It doesn't touch the things that dominate classic search rank, which are backlinks and domain authority, and the GEO research it follows says plainly that it never evaluated search-engine rankings at all. The honest framing is that it makes a repo legible and quotable to both readers and answer engines, not that it buys you a position.

How is this different from just asking an agent to write a README? GitHub Launch Kit differs from asking an agent directly in four ways. Asking directly gets you one pass over whatever you pasted into the chat. This reads the repository itself, runs five research lanes that verify sources online, drafts from a single positioning brief so the README, llms.txt, topics, About line, and SVG visuals agree with each other, then runs separate critic agents whose job is to break the draft before you ever see it.

Does it cost extra or need an API key? It costs no extra subscription and needs no API key, because it's a Markdown skill with no dependencies and no service behind it, running inside whatever agent subscription you already have, on whatever model that session is already using. A full run does use noticeably more of that access than a single reply, since it launches five research lanes and then a critique loop, so expect several minutes rather than seconds.

Does it work with GitLab or Bitbucket? It works with GitLab and Bitbucket partly. The README and llms.txt work on any host. GitHub topics and the About description are GitHub-specific fields, so on GitLab and Bitbucket those two artifacts have nowhere to go.

What is llms.txt and do I actually need one? You probably want an llms.txt, and it's cheap to be wrong about, because it's one file. llms.txt is a plain-text file at a project root that gives AI systems a clean summary and a link map, proposed by Jeremy Howard in September 2024 on the reasoning that "site authors know best, and can provide a list of content that an LLM should use" (Answer.AI, 2024). Be realistic about the payoff today: server-log analysis across 137,000 domains found 97% of published llms.txt files received zero requests in May 2026 (Ahrefs data, reported by PPC Land, 2026).

How many GitHub topics can a repo have? A GitHub repo can have 20 topics. GitHub's documentation says to "add no more than 20 topics" and to "use lowercase letters, numbers, and hyphens" with "50 characters or less" (GitHub Docs). Topic pages sort by stars by default, which is why this skill weights the set toward specific niche topics a new repo can actually be found on.

Does it send my private code anywhere? Your private code is read inside your own agent session, whether that's Claude Code, Codex, Cursor, or Zed, the same way any file you open there is, and that agent's own data handling applies. The research lanes do search the public web, and by design they search on your project's category, problem space, and competitor names rather than on your source code. If a private repo's subject matter is itself sensitive, say so up front and the research lanes can be narrowed or skipped.

Will it change my code or push to my repo? It changes no code and pushes nothing. It produces content and hands it back, and it confirms with you before writing a single file into your repository.

Can I run it in CI? It doesn't run in CI. It's an interactive agent workflow rather than a headless command, so if you need README regeneration on every push, use a CLI tool built for that.

⭐ Try it

If it saves you an hour on your next launch, a star helps other people find it. Issues and corrections are welcome, especially if you catch a claim on this page that doesn't hold up.

📚 Docs and license

File	What's in it
SKILL.md	The entry point: the phases, the trigger conditions, and the critical rules
references/house-voice.md	The house voice, the honesty rules, and the no-em-dash procedure
references/research-wave.md	The repo-analysis checklist and the five research lanes
references/readme-and-llms.md	The README blueprint and the llms.txt format
references/github-metadata.md	Choosing topics and writing the About line
references/critique-and-verify.md	The adversarial critique loop and its exit condition
references/svg-visuals.md	The animated SVG visuals stage: the metaphor rule, the GitHub constraints, and the anti-patterns
CONTRIBUTING.md	How to propose a change
CHANGELOG.md	What shipped when

Released under the MIT License.