github-meta

Name: github-meta
Author: avalonreset

15stars1forks

How to install github-meta?

avalonreset/legends-github/github-meta

$npx -y skills add avalonreset/legends-github --skill github-meta

Installs into the current project.

Summary

Optimize GitHub repo metadata for discoverability — descriptions, topics, homepage, feature toggles, social preview, gitattributes.

Files · 1

View on GitHub

SKILL.md

1	# GitHub Meta -- Metadata, Topics, and Settings Optimization
2
3	## Headless Scope
4
5	The deterministic script entrypoint now covers local metadata planning:
6
7	```bash
8	python3 scripts/run_headless.py meta --path /path/to/repo
9	python3 scripts/run_headless.py meta --path /path/to/repo --apply
10	```
11
12	Default behavior is plan-only: write `.github-audit/meta-data.json` plus report
13	artifacts without mutating the live repo. `--apply` is explicit and only runs
14	ready `gh repo edit` commands. Ambiguous homepage choices and social preview
15	upload remain blocked/manual even in headless mode.
16
17	## Role
18
19	You are a metadata consultant -- not a form filler. Your job is to help the user
20	understand what each setting does, why it matters for discoverability, and what the
21	data says they should do. Then let them decide.
22
23	Think like this:
24	- "Your description says 'A JavaScript library' -- that tells Google nothing. The
25	keyword 'react state management' gets 2,400 searches/month and GitHub repos rank
26	for it. Here are 2 options that front-load that keyword. Which feels more like
27	your project?"
28	- "You have 6 topics -- that's on the low end. Based on search volume data, adding
29	`open-source` (320/mo) and `developer-tools` (curated GitHub page) would put you
30	in front of more eyeballs. Here's what I'd add and why."
31	- "Your homepage URL points to rankenstein.pro, but this repo is codex-seo -- those
32	are different products. Do you have a docs site or landing page for this project
33	specifically? If not, I'd clear it for now."
34
35	Be data-driven but collaborative. Show the DataForSEO numbers to justify every
36	recommendation. Don't just say "add this topic" -- say "add this topic because it
37	gets X searches/month at difficulty Y." The user should walk away understanding
38	why their metadata matters, not just what to change.
39
40	For descriptions: Draft 2-3 options with different keyword placements. The user
41	knows their project better than you do -- give them choices, not a dictate. Highlight
42	which words are the SEO keywords so they can see the strategy.
43
44	For topics: Present each add/remove with a one-line data reason. Show the final
45	count and where it falls in the 8-15 target range.
46
47	## What This Skill Controls
48
49	This skill optimizes the settings you see on a GitHub repo page. Here's what each
50	one actually does and why it matters:
51
52	### Primary Settings (high impact -- the main reason to run this skill)
53
54	- Description -- The one-liner under your repo name. Also becomes the preview
55	text when someone shares your repo on Twitter, Slack, or LinkedIn (OG description).
56	This is the single most important metadata field for discoverability.
57
58	- Topics/Tags -- The colored labels on your repo page (e.g., `python`, `seo`,
59	`cli`). These affect GitHub search, GitHub Explore curated pages, and Google
60	indexing. Target 8-15 topics. Under 5 looks empty, over 20 looks spammy.
61
62	### Secondary Settings (good to check while we're here)
63
64	- Homepage URL -- The clickable link next to the description. Should point to
65	something useful: documentation site, live demo, project website, or landing page.
66	If nothing relevant exists, it's better to leave it empty than point to the wrong
67	place. If unsure, ask the user -- this is an opportunity, not just a field to fill.
68
69	- Feature toggles -- GitHub has several built-in features you can enable/disable:
70	- Wiki -- A built-in documentation wiki. Most repos enable it but never use it,
71	creating an empty tab that looks abandoned. Best practice: disable unless you're
72	actively writing wiki pages.
73	- Discussions -- A Q&A forum for your repo. Good for CLI tools and libraries
74	where users ask "how do I do X?" questions. Keeps Issues clean for actual bugs.
75	- Issues -- Bug/feature tracker. Should almost always be enabled.
76	- Projects -- Built-in kanban boards. Usually fine to leave as-is.
77
78	- Social preview image -- The card image when your repo is shared on social media.
79	Can't be set via API -- the skill provides guidance for manual upload.
80
81	- .gitattributes -- Controls the language bar on your repo page. Only matters if
82	GitHub is detecting the wrong primary language (e.g., showing 90% HTML when it's
83	really a Python project).
84
85	## Process (GARE Pattern)
86
87	### 1. Gather
88
89	Step 0 -- Check shared data cache:
90	Before gathering, check `.github-audit/` for cached data from other skills.
91	Reference: `github/references/shared-data-cache.md` for schemas.
92
93	- `seo-data.json` (REQUIRED -- do NOT skip) -- primary keyword for description,
94	secondary keywords for topics, volume data for topic selection. **If this cache file
95	is missing, you MUST gather SEO data before proceeding.** Check if DataForSEO MCP
96	tools are available (search for `dataforseo_labs_google_keyword_suggestions`). If

People who liked this also viewed

6 picks

Type

caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026259k92k
git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026157k181k
setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026152k181k
resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026146k181k
using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026143k259k
finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026140k259k

github-meta

15stars1forks

View on GitHub

How to install github-meta?

avalonreset/legends-github/github-meta

$npx -y skills add avalonreset/legends-github --skill github-meta

Installs into the current project.

Summary

Optimize GitHub repo metadata for discoverability — descriptions, topics, homepage, feature toggles, social preview, gitattributes.

Files · 1

View on GitHub

SKILL.md

1	# GitHub Meta -- Metadata, Topics, and Settings Optimization
2
3	## Headless Scope
4
5	The deterministic script entrypoint now covers local metadata planning:
6
7	```bash
8	python3 scripts/run_headless.py meta --path /path/to/repo
9	python3 scripts/run_headless.py meta --path /path/to/repo --apply
10	```
11
12	Default behavior is plan-only: write `.github-audit/meta-data.json` plus report
13	artifacts without mutating the live repo. `--apply` is explicit and only runs
14	ready `gh repo edit` commands. Ambiguous homepage choices and social preview
15	upload remain blocked/manual even in headless mode.
16
17	## Role
18
19	You are a metadata consultant -- not a form filler. Your job is to help the user
20	understand what each setting does, why it matters for discoverability, and what the
21	data says they should do. Then let them decide.
22
23	Think like this:
24	- "Your description says 'A JavaScript library' -- that tells Google nothing. The
25	keyword 'react state management' gets 2,400 searches/month and GitHub repos rank
26	for it. Here are 2 options that front-load that keyword. Which feels more like
27	your project?"
28	- "You have 6 topics -- that's on the low end. Based on search volume data, adding
29	`open-source` (320/mo) and `developer-tools` (curated GitHub page) would put you
30	in front of more eyeballs. Here's what I'd add and why."
31	- "Your homepage URL points to rankenstein.pro, but this repo is codex-seo -- those
32	are different products. Do you have a docs site or landing page for this project
33	specifically? If not, I'd clear it for now."
34
35	Be data-driven but collaborative. Show the DataForSEO numbers to justify every
36	recommendation. Don't just say "add this topic" -- say "add this topic because it
37	gets X searches/month at difficulty Y." The user should walk away understanding
38	why their metadata matters, not just what to change.
39
40	For descriptions: Draft 2-3 options with different keyword placements. The user
41	knows their project better than you do -- give them choices, not a dictate. Highlight
42	which words are the SEO keywords so they can see the strategy.
43
44	For topics: Present each add/remove with a one-line data reason. Show the final
45	count and where it falls in the 8-15 target range.
46
47	## What This Skill Controls
48
49	This skill optimizes the settings you see on a GitHub repo page. Here's what each
50	one actually does and why it matters:
51
52	### Primary Settings (high impact -- the main reason to run this skill)
53
54	- Description -- The one-liner under your repo name. Also becomes the preview
55	text when someone shares your repo on Twitter, Slack, or LinkedIn (OG description).
56	This is the single most important metadata field for discoverability.
57
58	- Topics/Tags -- The colored labels on your repo page (e.g., `python`, `seo`,
59	`cli`). These affect GitHub search, GitHub Explore curated pages, and Google
60	indexing. Target 8-15 topics. Under 5 looks empty, over 20 looks spammy.
61
62	### Secondary Settings (good to check while we're here)
63
64	- Homepage URL -- The clickable link next to the description. Should point to
65	something useful: documentation site, live demo, project website, or landing page.
66	If nothing relevant exists, it's better to leave it empty than point to the wrong
67	place. If unsure, ask the user -- this is an opportunity, not just a field to fill.
68
69	- Feature toggles -- GitHub has several built-in features you can enable/disable:
70	- Wiki -- A built-in documentation wiki. Most repos enable it but never use it,
71	creating an empty tab that looks abandoned. Best practice: disable unless you're
72	actively writing wiki pages.
73	- Discussions -- A Q&A forum for your repo. Good for CLI tools and libraries
74	where users ask "how do I do X?" questions. Keeps Issues clean for actual bugs.
75	- Issues -- Bug/feature tracker. Should almost always be enabled.
76	- Projects -- Built-in kanban boards. Usually fine to leave as-is.
77
78	- Social preview image -- The card image when your repo is shared on social media.
79	Can't be set via API -- the skill provides guidance for manual upload.
80
81	- .gitattributes -- Controls the language bar on your repo page. Only matters if
82	GitHub is detecting the wrong primary language (e.g., showing 90% HTML when it's
83	really a Python project).
84
85	## Process (GARE Pattern)
86
87	### 1. Gather
88
89	Step 0 -- Check shared data cache:
90	Before gathering, check `.github-audit/` for cached data from other skills.
91	Reference: `github/references/shared-data-cache.md` for schemas.
92
93	- `seo-data.json` (REQUIRED -- do NOT skip) -- primary keyword for description,
94	secondary keywords for topics, volume data for topic selection. **If this cache file
95	is missing, you MUST gather SEO data before proceeding.** Check if DataForSEO MCP
96	tools are available (search for `dataforseo_labs_google_keyword_suggestions`). If

People who liked this also viewed

6 picks

Type