domains / marketing / github-seo-gh-cli / github

github

Skill card

combined

The four copies share the name 'github' but describe two different procedures. kostja94/marketing-skills is a marketing/SEO skill for optimizing GitHub surfaces (profile README, pinned repos, repository README, GitHub Pages, gists, Awesome lists) for parasite SEO and GEO. The other three (Dimillian/Skills, sickn33/agentic-awesome-skills, LeoYeAI/openclaw-master-skills) are a devops/software-engineering skill for interacting with GitHub via the gh CLI (issues, PRs, CI runs, API queries). The gh-CLI copies are near-identical, with sickn33 adding a 'When to Use' section and a 'Limitations' section, and explicitly citing Dimillian/Skills as the source. Because the two procedures overlap only in the name and do not reproduce each other's steps, crowning one would hide a real alternative.

Repositories

Other copies

Combined skill

---
name: github
description: "Use this skill for two distinct GitHub tasks: (1) SEO/GEO optimization of GitHub surfaces (profile README, pinned repos, repository README, GitHub Pages, gists, Awesome lists), or (2) interacting with GitHub via the gh CLI for issues, PRs, CI runs, and API queries. Choose the relevant section based on the user's request."
---

# GitHub Skill

This skill covers two unrelated procedures. Select the section that matches the user's task.

## Section A: GitHub SEO / GEO / Curated Lists

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.

### 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 |
| 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.

| 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 | Full feature matrices, changelog, or install docs pasted into the profile file |
| Layout | Optional centered header for name + tagline + badges only; body stays left-aligned markdown | Center-wrapping the entire README |
| Optional widgets | Compact Shields; optional github-readme-stats / star-history — 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>.

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 so site ↔ GitHub OSS stay aligned for entity-seo.

Profile README checklist:
- [ ] 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)

## Section B: GitHub via gh CLI

Use the gh CLI to interact with GitHub. Always specify --repo owner/repo when not in a git directory, or use URLs directly.

### When to Use
- When the user asks about GitHub issues, pull requests, workflow runs, or CI failures.
- When you need gh issue, gh pr, gh run, or gh api from the command line.

### Pull Requests

Check CI status on a PR:
```bash
gh pr checks 55 --repo owner/repo
```

List recent workflow runs:
```bash
gh run list --repo owner/repo --limit 10
```

View a run and see which steps failed:
```bash
gh run view <run-id> --repo owner/repo
```

View logs for failed steps only:
```bash
gh run view <run-id> --repo owner/repo --log-failed
```

#### Debugging a CI Failure

Follow this sequence to investigate a failing CI run:

1. Check PR status — identify which checks are failing:
   ```bash
   gh pr checks 55 --repo owner/repo
   ```
2. List recent runs — find the relevant run ID:
   ```bash
   gh run list --repo owner/repo --limit 10
   ```
3. View the failed run — see which jobs and steps failed:
   ```bash
   gh run view <run-id> --repo owner/repo
   ```
4. Fetch failure logs — get the detailed output for failed steps:
   ```bash
   gh run view <run-id> --repo owner/repo --log-failed
   ```

### API for Advanced Queries

The gh api command is useful for accessing data not available through other subcommands.

Get PR with specific fields:
```bash
gh api repos/owner/repo/pulls/55 --jq '.title, .state, .user.login'
```

### JSON Output

Most commands support --json for structured output. You can use --jq to filter:
```bash
gh issue list --repo owner/repo --json number,title --jq '.[] | "\(.number): \(.title)"'
```

### Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

## Conflicts

- kostja94/marketing-skills defines the skill as a marketing/SEO guide and contains no gh CLI commands.
- Dimillian/Skills, sickn33/agentic-awesome-skills, and LeoYeAI/openclaw-master-skills define the skill as a gh CLI reference and contain no SEO or marketing guidance.
- sickn33/agentic-awesome-skills adds a 'When to Use' section and a 'Limitations' section not present in Dimillian/Skills or LeoYeAI/openclaw-master-skills.
- LeoYeAI/openclaw-master-skills omits the 'When to Use' and 'Limitations' sections, matching Dimillian/Skills more closely.