agentleFS
kiku-jwkiku-jw/codex-skills/github-seo/SKILL.md

github-seo

Skill0 starsChanged 4 months agoMITView on GitHub

Audit and improve a public GitHub repository's discoverability and any linked canonical site without confusing repository presentation with website SEO. Use for repository SEO, GitHub discoverability, topics/homepage/README optimization, GitHub Pages SEO, AEO, or agent-friendly public documentation.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not use when: the repository is private, the task is ordinary product development, or the user only wants generic marketing copy.

    line 17
  2. Very specific:

    If implementation is authorized, apply only the highest-value reversible slice, preserve URLs/Pages/releases/CI, and read back the changed …

    line 35
  3. Distinctive:

    No keyword stuffing, fake comparisons, bulk AI content, doorway pages, invented social proof, speculative schema, or decorative asset churn.

    line 51
  4. Distinctive:

    No new credentials, paid APIs, MCP servers, hooks, background services, or dependencies are installed without a separate explicit decision.

    line 53

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

GitHub SEO

Metadata

  • Trigger when: the user wants better discoverability for a public repository, its GitHub Pages deployment, or its canonical product site.
  • Do not use when: the repository is private, the task is ordinary product development, or the user only wants generic marketing copy.

Skill Purpose

Choose the correct discoverability surface before changing anything, then make the smallest evidence-backed improvement that helps people or search systems understand a real maintained project.

Instructions

  1. Ground the audit in live state. Read the repository metadata, README, manifests, releases, current screenshots, and linked homepage. Classify the target with references/surface-model.md before recommending changes.
  2. Audit only the applicable surface. Use references/audit-gates.md for GitHub metadata and README checks, Pages or canonical-site checks, language, evidence, and anti-spam rules. Separate observed facts from hypotheses and give every recommendation a verification or failure check.
  3. If implementation is authorized, apply only the highest-value reversible slice, preserve URLs/Pages/releases/CI, and read back the changed metadata, rendered README, deployed page, and relevant checks. Otherwise return the ranked plan without mutating anything.

Non-Negotiable Acceptance Criteria

  • The output names exactly one surface: repo-only, pages-product, canonical-site, or support-surface.
  • GitHub metadata and README quality are not represented as confirmed Google ranking factors.
  • Claims, metrics, screenshots, examples, schema, and product status are supported by current repository or live-product evidence.
  • English is canonical for public descriptions, README prose, and durable technical documentation. Localized product content, fixtures, quotations, and user-facing examples may remain in their real language.
  • No keyword stuffing, fake comparisons, bulk AI content, doorway pages, invented social proof, speculative schema, or decorative asset churn.
  • No new credentials, paid APIs, MCP servers, hooks, background services, or dependencies are installed without a separate explicit decision.
  • Redirects, organization metadata repositories, compatibility layers, unproven prototypes, and parked surfaces default to skip or wait-for-proof.

Output

Return:

  • Surface: one surface classification with evidence.
  • Verdict: keep, metadata-only, asset-only, readme-rewrite, site-baseline, wait-for-proof, or skip.
  • Findings: observed facts separated from hypotheses.
  • Action: the smallest useful change, its dependency, and why it is first.
  • Verification: exact read-back, test, crawl, or deployment check.
  • Failure check: what would show that the recommendation did not help.

Optional handoffs after the audit:

  • $readme-generator — build a truthful README when structure is the problem.
  • $beautify-github-readme — redesign only when repo-native visual proof exists.
  • $ai-writing-detox — remove generic AI copy after the facts are settled.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.