Github skill

When the user wants to use GitHub for SEO, parasite SEO, GEO, open source marketing, README optimization, or curated Awesome lists.

by kostja94·MIT license·★ 1,006 Stars on the repo·GitHub ↗

Use now

Files of Github

kostja94/main1 file shown
SKILL.md
Show the full text327 lines

Platforms: GitHub

Guides GitHub for parasite SEO, GEO (AI citation), and curated list creation. GitHub is a Tier 2 Technical Authority platform—high domain authority, fast indexing, very high AI citation probability. Use for repos, README, GitHub Pages, gists, and Awesome-style navigation lists.

When invoking: On first use, if helpful, open with 1–2 sentences on what this skill covers and why it matters, then provide the main output. On subsequent use or when the user asks to skip, go directly to the main output.

Why GitHub for SEO

Factor Effect
Domain authority High DA; repos, gists, Pages rank well
Fast indexing Search engines crawl GitHub frequently
AI citation ChatGPT, Perplexity cite GitHub for technical queries; Tier 2 in GEO framework
Technical expertise Strong expertise signals; structured docs become AI reference material
Cross-platform Share across Dev.to, Stack Overflow, forums; amplifies visibility

Use Cases

Use case Format Purpose
Parasite SEO Repos, README, Pages, gists Leverage GitHub authority for rankings and backlinks
GEO Documentation, tutorials, curated lists AI tools cite GitHub for technical answers
Curated / navigation lists Awesome-style repos Topic-specific resource directories; backlinks, discovery

Surfaces: profile vs repository

Surface What it is Optimization focus
Profile README Public repo with the same name as the username; root README.md renders on the profile Personal brand, flagship links, social proof
Pinned Up to 6 repos or gists on the profile Showcase top projects; align with entity signals (entity-seo)
Per-repo README Root README.md on each repo’s Code tab Product landing; install, proof, CTAs

Changing a normal repo README does not change the profile banner unless that content is the profile README repo or linked from it.

Profile README (username/username)

Not the same as a product repo README. Optimize for identity + navigation in ~15–40 lines of rendered content unless the user explicitly wants a long-form CV. Official setup: Managing your profile README.

Principle Do Avoid
Length Short, scannable sections; omit ToC unless the file is genuinely long Applying “500–1,500 words typical for product repos” here
Headings ### blocks (e.g. What I do · Open source · Find me) for fast eyeballing Many nested ## + long narrative without breaks
Links Each primary URL once in a Find me / Connect line (or badges or a slim table—not all three repeating the same destinations) Duplicate site/LinkedIn/email in badges, tables, and prose
Repos block Bold repo name + ≤2 short lines + at most one copy-paste command (e.g. npx skills add …) — same scan pattern popular profiles use for “flagship OSS” without cloning the repo’s full README Full feature matrices, changelog, or install docs pasted into the profile file
Layout Optional centered header (<div align="center">) for name + tagline + badges only; body stays left-aligned markdown for readability Center-wrapping the entire README
Optional widgets Compact Shields (flat style); optional github-readme-stats / star-history — third-party, treat as conversion/social proof, not core SEO Wall of for-the-badge badges when the same CTAs are repeated in text

Minimal outline (typical profile):

  1. Title + answer-first tagline (+ slim badge row).
  2. ### What I do — identity, proof link(s), without repeating the same URLs again later.
  3. ### Open source — bold repo links + pitches + optional one code fence.
  4. ### Find me — single line of deduped links (site · bio · cases · social · email).
  5. ### Activity (optional) — small github-readme-stats + star-history; alt text on <img>.

Reference pattern (high-signal, low-noise): scan-first profiles such as alchaincyf — short ### blocks, bold product/repo names, one “find me” cluster.

Entity hub pattern: When the person has a canonical site, lead with it in the opening line and mirror the same URL in Pinned / profile About (if used) so site ↔ GitHub OSS stay aligned for entity-seo.

Profile README checklist (short)
  • H1 + one answer-first tagline (keywords: role, stack, domain)
  • Canonical outbound links (site, social, email) deduplicated
  • Pinned repos (≤6) match the story told in the README
  • Optional: Activity section — group stats / star-history under one heading instead of scattering widgets
  • Last updated footnote for freshness (GEO signal)

Repository home: layout map

Area Typical contents SEO / ops note
Main column File list; rendered root README below First screen and H2/H3 carry most narrative
About sidebar Description, Website, Topics, releases shortcut, license, languages Keep Description and README first paragraph consistent; Website should match the primary outbound CTA
Other tabs Issues, PRs, Actions, etc. Engagement and freshness signals

Website field: Maintained via repo Settings / About edit; prefer one canonical docs or product URL aligned with README links.

In-site discovery (high level)

Entry Role Caveat
Trending Time-windowed visibility Formula is not public; never promise ranking
Explore Collections, themes, programs Useful for patterns and seasonal campaigns
Topics Topic pages tied to repository topics Aligns with Topics metadata (see Topics section below)
Search Query across repos and users README + About + topics drive match quality

UI and URLs evolve; verify on github.com.

flowchart LR
  discovery[Discovery or referral]
  home[Repository home]
  readme[README and About]
  outbound[Site or docs]

  discovery --> home
  home --> readme
  readme --> outbound

Repository Name, About & README (SEO/GEO Priority)

Ranking weight (GitHub + Google): Repository name & About ≈ highest; Topics ≈ high; README ≈ high.

Repository Name
Practice Guideline
Descriptive Hint at what the project does
Keyword-rich Include primary keywords (markdown-editor not my-project)
Hyphens Separate words (react-component-library)
Concise Shorter = memorable, shareable
About Section (Description)
Limit Guideline
350 chars Hard limit; GitHub enforces
~128 chars Optimal for brevity; often displayed fully
Content Primary keyword + natural variations; what it does, who it's for; link to website or docs if space

Example: "A fast, lightweight markdown editor for React with live preview, syntax highlighting, and export to PDF. Built with TypeScript."

Topics
Limit Guideline
6–20 topics Max 20; 6–10 recommended
~50 chars each Per topic
Format Lowercase, hyphens, numbers only
Mix Technology (react, python), purpose (cli, library), category (seo, ai-tools), community (hacktoberfest)

Underutilized but highly effective for discoverability and GEO.

README Structure & Components

Targets repository (project) READMEs unless noted. Profile README overrides: shorter, fewer sections—see Profile README (username/username) above.

Section Purpose SEO/GEO
Title + tagline H1 + 1–2 sentence summary; keywords in first paragraph Critical; first 100 words weighted
Table of contents Links to H2/H3; for long repo READMEs (often >500 words). Usually skip on profile README Navigation; crawlability
Installation / Quick start Prerequisites; exact commands; copy-paste ready Use-case clarity
Usage examples Code blocks; common scenarios Citable; extractable
Screenshots / GIFs Demo, output; alt text required Engagement; accessibility
Badges Build, version, license Trust signals
Contributing Link to CONTRIBUTING.md Community signal
License Link to LICENSE Completeness

Word count: No hard limit; 500–1,500 words typical for product / library repos. Lead with value; expand later. Profile README: prefer dense brevity—long-form belongs on the canonical site or in pinned repos’ own READMEs.

README GEO / AI Citation
Practice Guideline
Answer-first Direct answer in first 1–2 sentences (40–60 words); profile README may compress to one punchy tagline under H1 if outbound links carry the rest
Short paragraphs 2–3 sentences max; extractable clarity
Question-style headings H2/H3 as questions where relevant (repository READMEs); on profile README, optional — clarity of sections matters more than question phrasing
Data inclusion Stats, numbers; cited content ~40% more likely to include data
Freshness Update regularly; ~76% of cited content updated within 30 days

Entity signals: Clear project name, author, maintainer; consistent identity. See entity-seo.

README Checklist — repository (default)
  • Project title with keywords
  • Concise description in first paragraph
  • H2/H3 structure; alt text for images
  • Installation + usage examples
  • Screenshots or demo
  • Badges; Contributing; License
  • Internal links to related docs/repos
  • 6–20 topics on repo

(For profile username/username, use the shorter Profile README checklist under Surfaces—not every row above applies.)

Parasite SEO on GitHub

Key Surfaces
Surface Use
README Landing page for repo; keyword-optimized summary, headings, links
GitHub Pages Static site; blog, FAQ, docs; additional ranking opportunities
Gists Micro-content; long-tail keywords; link to repos or external resources
Wiki Keyword-rich documentation
Issues Q&A, discussions; indexable
GitHub Pages vs README
Surface Role
README First impression; Stars/forks; short pitch and deep links
Pages Multi-page static site: long docs, blog, changelog

Default URL patterns: A user or organization site often uses a username.github.io repository and serves at https://username.github.io. A project site is published from a given repo and typically appears at https://username.github.io/repository/ (path may vary with settings). See About GitHub Pages.

Limits: Build size, bandwidth, and build-frequency caps change over time—cite GitHub Pages limits when users need numbers, not hard-coded figures from this skill.

Optimization
Element Practice
Repository title Primary keywords; descriptive; hyphens
About 350 chars max; keyword-rich; primary keyword + natural variations
Description Secondary keywords; link to website or resources
README Keyword-optimized summary first; headings, bullet points; screenshots; links to docs, tutorials
Topics / tags 6–20 relevant topics; 50 chars each
GitHub Pages Mobile-friendly; metadata; blog/FAQ for extra keywords
Gists for Micro-Content
  • Target specific long-tail keywords
  • Link back to larger repos or external resources
  • Share code snippets, small utilities
Community Engagement
  • Respond to issues and PRs; builds trust
  • Contribute to popular projects; backlinks, visibility
  • Keep repos updated; outdated = lower credibility

GEO on GitHub

Factor Practice
README clarity Clear, citable paragraphs; direct answers
Documentation Structured; AI tools parse well
Entity signals Clear project, author identity; see entity-seo
Consistency Active maintenance; engagement (stars, forks, watchers)

Repository archetypes

Archetype Intent First-screen emphasis
Product / library Installable software, SDK, CLI, service Install, quickstart, proof (CI, license), support path
Curated / resource Awesome-style lists, indexes Scope, curation bar, contribution rules
Personal profile hub Public username/username README on the profile Identity + canonical links + pinned flagship repos; no duplication of full product READMEs

Match metrics to type: curated lists optimize for trust and backlinks; product repos optimize for adoption and issue quality.

Curated / Navigation Lists (Awesome-Style)

Awesome lists = Curated, topic-specific resource lists on GitHub. Function like navigation directories; high traffic, backlinks, discovery. sindresorhus/awesome (441K+ stars) is the master list; 6,500+ curated lists exist across topics.

Examples by Category
Category Examples
Master list sindresorhus/awesome — hub of all awesome lists
SEO / Marketing awesome-seo, awesome-ai-seo, bmpi-dev/awesome-seo
AI / ML awesome-ai-tools, AITreasureBox, awesome-ai
Dev tools awesome-tools, awesome-cli, awesome-nodejs
Languages awesome-python, awesome-javascript, awesome-go
Frontend / Backend awesome-react, awesome-vue, awesome-django
Other awesome-security, awesome-gaming, awesome-databases
When to Create
  • You have a niche with many quality resources to curate
  • Existing lists lack coverage of your topic
  • You want a backlink asset and topical authority
List Structure (sindresorhus/awesome guidelines)
Element Practice
Title Clear, focused (e.g., "Awesome SEO," "Awesome AI Tools")
Description Succinct; scope clear
Sections Categorized (e.g., Tutorials, Tools, Articles)
Items Curated, not collected; only include what you recommend
Item format - [Name](URL) - Brief description of why it's awesome
License CC0 or similar
Contributing contributing.md for PR process
Getting Listed vs. Creating
Action Use
Submit to existing list PR to awesome-* repos; follow list format; contact maintainer
Create new list When no list exists for your niche; follow awesome guidelines
Link between lists Link to other awesome lists that cover subjects better
Discovery
  • sindresorhus/awesome — Master list of awesome lists
  • AwesomeSearch — Search across awesome lists
  • more-awesome — Directory of awesome lists

Common Mistakes

Mistake Avoid
Ignoring engagement Not responding to issues/PRs reduces trust
Irregular updates Outdated repos signal inactivity
Incomplete docs Lack of clear descriptions frustrates users
Generic titles Missing keywords reduces discoverability
Thin awesome lists Low-quality or uncurated items hurt credibility
Profile README = product README Pasting install/Contributing/screenshot-heavy templates on username/username — use the profile checklist
Link sprawl on profile Same homepage/social/email repeated in badges, tables, and long copy — consolidate

Output Format

  • Use case (parasite SEO / GEO / curated list)
  • Surface scope (profile vs specific repository; README vs Pages)
  • Repository name, About, Topics (if optimizing metadata)
  • Surface (README, Pages, gist, awesome repo)
  • README structure (sections, word count, GEO practices if applicable) — if profile README, cite short outline + deduped links + optional widgets per Profile README section above
  • Optimization (keywords, structure, links)
  • Ready-to-use copy or structure where applicable
  • parasite-seo: Parasite SEO strategy; GitHub as Tier 2 technical platform
  • generative-engine-optimization: GEO strategy; GitHub for AI citation
  • open-source-strategy: Open source commercialization; GitHub as primary distribution
  • directory-submission: Directory and curated list submission; awesome lists as curated lists
  • link-building: GitHub as link acquisition; repos, gists, awesome lists
  • entity-seo: Entity signals (project, author); Organization, Person
1---
2name: github
3description: When the user wants to use GitHub for SEO, parasite SEO, GEO, open source marketing, README optimization, or curated Awesome lists. Also use when the user mentions "GitHub," "GitHub SEO," "GitHub parasite SEO," "GitHub GEO," "awesome list," "GitHub README," "profile README," "pinned repositories," "Trending," "Explore," "repository name," "About section," "GitHub description," "GitHub topics," "Website field," "GitHub Pages," "github.io," "user site," "project site," "GitHub gist," "curated list," or "navigation list." Not for Medium or other non-GitHub platforms—use parasite-seo or medium-posts. For OSS business model, use open-source-strategy.
4metadata:
5 version: 1.5.0
6---
7 
8# Platforms: GitHub
9 
10Guides GitHub for parasite SEO, GEO (AI citation), and curated list creation. GitHub is a Tier 2 Technical Authority platform—high domain authority, fast indexing, very high AI citation probability. Use for repos, README, GitHub Pages, gists, and Awesome-style navigation lists.
11 
12**When invoking**: On **first use**, if helpful, open with 1–2 sentences on what this skill covers and why it matters, then provide the main output. On **subsequent use** or when the user asks to skip, go directly to the main output.
13 
14## Why GitHub for SEO
15 
16| Factor | Effect |
17|--------|--------|
18| **Domain authority** | High DA; repos, gists, Pages rank well |
19| **Fast indexing** | Search engines crawl GitHub frequently |
20| **AI citation** | ChatGPT, Perplexity cite GitHub for technical queries; Tier 2 in GEO framework |
21| **Technical expertise** | Strong expertise signals; structured docs become AI reference material |
22| **Cross-platform** | Share across Dev.to, Stack Overflow, forums; amplifies visibility |
23 
24## Use Cases
25 
26| Use case | Format | Purpose |
27|----------|--------|---------|
28| **Parasite SEO** | Repos, README, Pages, gists | Leverage GitHub authority for rankings and backlinks |
29| **GEO** | Documentation, tutorials, curated lists | AI tools cite GitHub for technical answers |
30| **Curated / navigation lists** | Awesome-style repos | Topic-specific resource directories; backlinks, discovery |
31 
32## Surfaces: profile vs repository
33 
34| Surface | What it is | Optimization focus |
35|---------|------------|---------------------|
36| **Profile README** | Public repo **with the same name as the username**; root `README.md` renders on the profile | Personal brand, flagship links, social proof |
37| **Pinned** | Up to **6** repos or gists on the profile | Showcase top projects; align with entity signals (**entity-seo**) |
38| **Per-repo README** | Root `README.md` on each repo’s **Code** tab | Product landing; install, proof, CTAs |
39 
40Changing a normal repo README does **not** change the profile banner unless that content is the **profile README** repo or linked from it.
41 
42### Profile README (`username/username`)
43 
44**Not the same as a product repo README.** Optimize for **identity + navigation** in ~15–40 lines of rendered content unless the user explicitly wants a long-form CV. Official setup: [Managing your profile README](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/managing-your-profile-readme).
45 
46| Principle | Do | Avoid |
47|-----------|-----|--------|
48| **Length** | Short, scannable sections; **omit ToC** unless the file is genuinely long | Applying “500–1,500 words typical for product repos” here |
49| **Headings** | `###` blocks (e.g. *What I do · Open source · Find me*) for fast eyeballing | Many nested `##` + long narrative without breaks |
50| **Links** | Each primary URL **once** in a **Find me / Connect** line (or badges **or** a slim table—not all three repeating the same destinations) | Duplicate site/LinkedIn/email in badges, tables, and prose |
51| **Repos block** | **Bold repo name** + **≤2 short lines** + at most **one** copy-paste command (e.g. `npx skills add …`) — same scan pattern popular profiles use for “flagship OSS” without cloning the repo’s full README | Full feature matrices, changelog, or install docs pasted into the profile file |
52| **Layout** | Optional **centered** header (`<div align="center">`) for **name + tagline + badges only**; body stays left-aligned markdown for readability | Center-wrapping the entire README |
53| **Optional widgets** | Compact Shields (flat style); optional [github-readme-stats](https://github.com/anuraghazra/github-readme-stats) / [star-history](https://star-history.com) — **third-party**, treat as **conversion/social proof**, not core SEO | Wall of `for-the-badge` badges when the same CTAs are repeated in text |
54 
55**Minimal outline (typical profile):**
56 
571. Title + answer-first tagline (+ slim badge row).
582. `### What I do` — identity, proof link(s), **without** repeating the same URLs again later.
593. `### Open source` — bold repo links + pitches + optional one code fence.
604. `### Find me` — single line of deduped links (site · bio · cases · social · email).
615. `### Activity` (optional) — small **github-readme-stats** + **star-history**; **alt text** on `<img>`.
62 
63Reference pattern (high-signal, low-noise): scan-first profiles such as [alchaincyf](https://github.com/alchaincyf) — short `###` blocks, bold product/repo names, one “find me” cluster.
64 
65**Entity hub pattern:** When the person has a canonical site, lead with it in the **opening line** and mirror the same URL in **Pinned** / **profile About** (if used) so **site ↔ GitHub OSS** stay aligned for **entity-seo**.
66 
67### Profile README checklist (short)
68 
69- [ ] H1 + **one** answer-first tagline (keywords: role, stack, domain)
70- [ ] Canonical **outbound** links (site, social, email) **deduplicated**
71- [ ] **Pinned** repos (≤6) match the story told in the README
72- [ ] Optional: **Activity** section — group stats / star-history under one heading instead of scattering widgets
73- [ ] **Last updated** footnote for freshness (GEO signal)
74 
75## Repository home: layout map
76 
77| Area | Typical contents | SEO / ops note |
78|------|------------------|----------------|
79| **Main column** | File list; rendered **root README** below | First screen and H2/H3 carry most narrative |
80| **About sidebar** | **Description**, **Website**, **Topics**, releases shortcut, license, languages | Keep Description and README first paragraph consistent; **Website** should match the primary outbound CTA |
81| **Other tabs** | Issues, PRs, Actions, etc. | Engagement and freshness signals |
82 
83**Website field**: Maintained via repo **Settings** / **About** edit; prefer one canonical docs or product URL aligned with README links.
84 
85## In-site discovery (high level)
86 
87| Entry | Role | Caveat |
88|-------|------|--------|
89| **Trending** | Time-windowed visibility | Formula is **not** public; never promise ranking |
90| **Explore** | Collections, themes, programs | Useful for patterns and seasonal campaigns |
91| **Topics** | Topic pages tied to repository topics | Aligns with Topics metadata (see Topics section below) |
92| **Search** | Query across repos and users | README + About + topics drive match quality |
93 
94UI and URLs evolve; verify on [github.com](https://github.com/).
95 
96```mermaid
97flowchart LR
98 discovery[Discovery or referral]
99 home[Repository home]
100 readme[README and About]
101 outbound[Site or docs]
102 
103 discovery --> home
104 home --> readme
105 readme --> outbound
106```
107 
108## Repository Name, About & README (SEO/GEO Priority)
109 
110**Ranking weight** (GitHub + Google): Repository name & About ≈ highest; Topics ≈ high; README ≈ high.
111 
112### Repository Name
113 
114| Practice | Guideline |
115|----------|-----------|
116| **Descriptive** | Hint at what the project does |
117| **Keyword-rich** | Include primary keywords (`markdown-editor` not `my-project`) |
118| **Hyphens** | Separate words (`react-component-library`) |
119| **Concise** | Shorter = memorable, shareable |
120 
121### About Section (Description)
122 
123| Limit | Guideline |
124|-------|-----------|
125| **350 chars** | Hard limit; GitHub enforces |
126| **~128 chars** | Optimal for brevity; often displayed fully |
127| **Content** | Primary keyword + natural variations; what it does, who it's for; link to website or docs if space |
128 
129**Example**: "A fast, lightweight markdown editor for React with live preview, syntax highlighting, and export to PDF. Built with TypeScript."
130 
131### Topics
132 
133| Limit | Guideline |
134|-------|-----------|
135| **6–20 topics** | Max 20; 6–10 recommended |
136| **~50 chars** each | Per topic |
137| **Format** | Lowercase, hyphens, numbers only |
138| **Mix** | Technology (react, python), purpose (cli, library), category (seo, ai-tools), community (hacktoberfest) |
139 
140**Underutilized** but highly effective for discoverability and GEO.
141 
142### README Structure & Components
143 
144Targets **repository (project) READMEs** unless noted. **Profile README** overrides: shorter, fewer sections—see **Profile README (`username/username`)** above.
145 
146| Section | Purpose | SEO/GEO |
147|---------|---------|---------|
148| **Title + tagline** | H1 + 1–2 sentence summary; keywords in first paragraph | Critical; first 100 words weighted |
149| **Table of contents** | Links to H2/H3; **for long repo READMEs** (often >500 words). **Usually skip on profile README** | Navigation; crawlability |
150| **Installation / Quick start** | Prerequisites; exact commands; copy-paste ready | Use-case clarity |
151| **Usage examples** | Code blocks; common scenarios | Citable; extractable |
152| **Screenshots / GIFs** | Demo, output; alt text required | Engagement; accessibility |
153| **Badges** | Build, version, license | Trust signals |
154| **Contributing** | Link to CONTRIBUTING.md | Community signal |
155| **License** | Link to LICENSE | Completeness |
156 
157**Word count**: No hard limit; **500–1,500 words** typical for **product / library** repos. Lead with value; expand later. **Profile README**: prefer **dense brevity**—long-form belongs on the canonical site or in pinned repos’ own READMEs.
158 
159### README GEO / AI Citation
160 
161| Practice | Guideline |
162|----------|-----------|
163| **Answer-first** | Direct answer in first 1–2 sentences (40–60 words); **profile README** may compress to **one punchy tagline under H1** if outbound links carry the rest |
164| **Short paragraphs** | 2–3 sentences max; extractable clarity |
165| **Question-style headings** | H2/H3 as questions where relevant (**repository READMEs**); on **profile README**, optional — clarity of **sections** matters more than question phrasing |
166| **Data inclusion** | Stats, numbers; cited content ~40% more likely to include data |
167| **Freshness** | Update regularly; ~76% of cited content updated within 30 days |
168 
169**Entity signals**: Clear project name, author, maintainer; consistent identity. See **entity-seo**.
170 
171### README Checklist — **repository (default)**
172 
173- [ ] Project title with keywords
174- [ ] Concise description in first paragraph
175- [ ] H2/H3 structure; alt text for images
176- [ ] Installation + usage examples
177- [ ] Screenshots or demo
178- [ ] Badges; Contributing; License
179- [ ] Internal links to related docs/repos
180- [ ] 6–20 topics on repo
181 
182*(For **profile** `username/username`, use the shorter **Profile README checklist** under Surfaces—not every row above applies.)*
183 
184## Parasite SEO on GitHub
185 
186### Key Surfaces
187 
188| Surface | Use |
189|---------|-----|
190| **README** | Landing page for repo; keyword-optimized summary, headings, links |
191| **GitHub Pages** | Static site; blog, FAQ, docs; additional ranking opportunities |
192| **Gists** | Micro-content; long-tail keywords; link to repos or external resources |
193| **Wiki** | Keyword-rich documentation |
194| **Issues** | Q&A, discussions; indexable |
195 
196### GitHub Pages vs README
197 
198| Surface | Role |
199|---------|------|
200| **README** | First impression; Stars/forks; short pitch and deep links |
201| **Pages** | Multi-page **static** site: long docs, blog, changelog |
202 
203**Default URL patterns**: A **user or organization site** often uses a `username.github.io` repository and serves at `https://username.github.io`. A **project site** is published from a given repo and typically appears at `https://username.github.io/repository/` (path may vary with settings). See [About GitHub Pages](https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages).
204 
205**Limits**: Build size, bandwidth, and build-frequency caps change over time—cite [GitHub Pages limits](https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits) when users need numbers, not hard-coded figures from this skill.
206 
207### Optimization
208 
209| Element | Practice |
210|---------|----------|
211| **Repository title** | Primary keywords; descriptive; hyphens |
212| **About** | 350 chars max; keyword-rich; primary keyword + natural variations |
213| **Description** | Secondary keywords; link to website or resources |
214| **README** | Keyword-optimized summary first; headings, bullet points; screenshots; links to docs, tutorials |
215| **Topics / tags** | 6–20 relevant topics; 50 chars each |
216| **GitHub Pages** | Mobile-friendly; metadata; blog/FAQ for extra keywords |
217 
218### Gists for Micro-Content
219 
220- Target specific long-tail keywords
221- Link back to larger repos or external resources
222- Share code snippets, small utilities
223 
224### Community Engagement
225 
226- Respond to issues and PRs; builds trust
227- Contribute to popular projects; backlinks, visibility
228- Keep repos updated; outdated = lower credibility
229 
230## GEO on GitHub
231 
232| Factor | Practice |
233|--------|----------|
234| **README clarity** | Clear, citable paragraphs; direct answers |
235| **Documentation** | Structured; AI tools parse well |
236| **Entity signals** | Clear project, author identity; see **entity-seo** |
237| **Consistency** | Active maintenance; engagement (stars, forks, watchers) |
238 
239## Repository archetypes
240 
241| Archetype | Intent | First-screen emphasis |
242|-----------|--------|------------------------|
243| **Product / library** | Installable software, SDK, CLI, service | Install, quickstart, proof (CI, license), support path |
244| **Curated / resource** | Awesome-style lists, indexes | Scope, curation bar, contribution rules |
245| **Personal profile hub** | Public **`username/username`** README on the profile | Identity + canonical links + **pinned** flagship repos; **no** duplication of full product READMEs |
246 
247Match metrics to type: curated lists optimize for trust and backlinks; product repos optimize for adoption and issue quality.
248 
249## Curated / Navigation Lists (Awesome-Style)
250 
251**Awesome lists** = Curated, topic-specific resource lists on GitHub. Function like navigation directories; high traffic, backlinks, discovery. sindresorhus/awesome (441K+ stars) is the master list; 6,500+ curated lists exist across topics.
252 
253### Examples by Category
254 
255| Category | Examples |
256|----------|----------|
257| **Master list** | sindresorhus/awesome — hub of all awesome lists |
258| **SEO / Marketing** | awesome-seo, awesome-ai-seo, bmpi-dev/awesome-seo |
259| **AI / ML** | awesome-ai-tools, AITreasureBox, awesome-ai |
260| **Dev tools** | awesome-tools, awesome-cli, awesome-nodejs |
261| **Languages** | awesome-python, awesome-javascript, awesome-go |
262| **Frontend / Backend** | awesome-react, awesome-vue, awesome-django |
263| **Other** | awesome-security, awesome-gaming, awesome-databases |
264 
265### When to Create
266 
267- You have a niche with many quality resources to curate
268- Existing lists lack coverage of your topic
269- You want a backlink asset and topical authority
270 
271### List Structure (sindresorhus/awesome guidelines)
272 
273| Element | Practice |
274|---------|----------|
275| **Title** | Clear, focused (e.g., "Awesome SEO," "Awesome AI Tools") |
276| **Description** | Succinct; scope clear |
277| **Sections** | Categorized (e.g., Tutorials, Tools, Articles) |
278| **Items** | Curated, not collected; only include what you recommend |
279| **Item format** | `- [Name](URL) - Brief description of why it's awesome` |
280| **License** | CC0 or similar |
281| **Contributing** | contributing.md for PR process |
282 
283### Getting Listed vs. Creating
284 
285| Action | Use |
286|--------|-----|
287| **Submit to existing list** | PR to awesome-* repos; follow list format; contact maintainer |
288| **Create new list** | When no list exists for your niche; follow awesome guidelines |
289| **Link between lists** | Link to other awesome lists that cover subjects better |
290 
291### Discovery
292 
293- **sindresorhus/awesome** — Master list of awesome lists
294- **AwesomeSearch** — Search across awesome lists
295- **more-awesome** — Directory of awesome lists
296 
297## Common Mistakes
298 
299| Mistake | Avoid |
300|---------|-------|
301| **Ignoring engagement** | Not responding to issues/PRs reduces trust |
302| **Irregular updates** | Outdated repos signal inactivity |
303| **Incomplete docs** | Lack of clear descriptions frustrates users |
304| **Generic titles** | Missing keywords reduces discoverability |
305| **Thin awesome lists** | Low-quality or uncurated items hurt credibility |
306| **Profile README = product README** | Pasting install/Contributing/screenshot-heavy templates on `username/username` — use the **profile** checklist |
307| **Link sprawl on profile** | Same homepage/social/email repeated in badges, tables, and long copy — consolidate |
308 
309## Output Format
310 
311- **Use case** (parasite SEO / GEO / curated list)
312- **Surface scope** (profile vs specific repository; README vs Pages)
313- **Repository name, About, Topics** (if optimizing metadata)
314- **Surface** (README, Pages, gist, awesome repo)
315- **README structure** (sections, word count, GEO practices if applicable) — **if profile README**, cite **short** outline + deduped links + optional widgets per **Profile README** section above
316- **Optimization** (keywords, structure, links)
317- **Ready-to-use** copy or structure where applicable
318 
319## Related Skills
320 
321- **parasite-seo**: Parasite SEO strategy; GitHub as Tier 2 technical platform
322- **generative-engine-optimization**: GEO strategy; GitHub for AI citation
323- **open-source-strategy**: Open source commercialization; GitHub as primary distribution
324- **directory-submission**: Directory and curated list submission; awesome lists as curated lists
325- **link-building**: GitHub as link acquisition; repos, gists, awesome lists
326- **entity-seo**: Entity signals (project, author); Organization, Person
327 

Discussion

Alternatives

Agentic Browsing ReadinessAudit and fix agent readiness: the Lighthouse Agentic Browsing fraction, accessibility tree for agents, robots.txt and Content-Signal for AI agents, WAF treatment of agent traffic, llms.txt, Markdown delivery, ai-catalog.json, /.well-known discovery files, and WebMCP tools. Exclude AI citability and brand signals (seo-geo) and commerce protocol depth (seo-ecommerce).Marketing · MITBacklink Profile AnalysisBacklink profile analysis: referring domains, anchor text distribution, toxic link detection, competitor gap analysis. Works with free APIs (Moz, Bing Webmaster, Common Crawl) and DataForSEO extension. Use when user says backlinks, link profile, referring domains, anchor text, toxic links, link gap, link building, disavow, or backlink audit.Marketing · MIT/setup-cmsConnect a CMS to notfair SEO tools. Guides users through configuring WordPress, Strapi, Contentful, or Ghost — tests the connection, and writes credentials to .env.local. Once set up, seo-analysis automatically cross- references CMS content against Google Search Console data. Use whenever the user says "connect my CMS", "set up WordPress", "configure Strapi", "add Contentful", "connect Ghost", or "CMS setup". Also trigger if the user asks why no CMS data appears in a seo-analysis report. · MITBacklink checkBacklink profile for any domain — referring domains, authority, anchors, new/lost links, and a side-by-side vs a competitor. Use when asked "check my backlinks", "backlink profile of X", "who links to them", or "link gap vs competitor".Marketing · MIT