← ClaudeAtlas

repo-topic-taggerlisted

Audit and apply GitHub topic tags for discoverability — proposes tags from code signals, deduplicates against current tags, applies via gh api after explicit approval. Sub-skill of repo-seo-curator.
jamestexas/agents · ★ 2 · AI & Automation · score 61
Install: claude install-skill jamestexas/agents
<!-- Author: jamestexas — drafted by claude-opus-4-7 (2026-05-16) --> # /repo-topic-tagger — GitHub Topic Curation Apply a curated, discoverability-optimized set of GitHub topics to one or more repositories. ## Arguments `$ARGUMENTS` - **`<owner/repo>`** — one or more target repos (e.g. `agentic-research/mache`). If omitted, defaults to the repo containing the current working directory. - **`--dry-run`** *(default)* — propose changes but do not apply. Always the default. The user must explicitly pass `--apply` to write. - **`--apply`** — after presenting the proposal, prompt for approval and call `gh api` to write the new topic set. - **`--max=N`** — cap proposed tag count at N (default 12; GitHub allows 20 max). ## What this solves Many of the user's public repos ship with **zero topics**. This kills discoverability: - They never surface in GitHub's topic browser (`github.com/topics/<x>`) - They never appear in "related repositories" cards - LLM-based repo discovery tools weight topic metadata heavily - Human searchers filtering by topic on GitHub never see them Topics are cheap to set, never break anything, and compound over time as GitHub's index picks them up. ## Reference: a good topic set `agentic-research/cloister` is the canonical good example: ``` capnproto, cloudflare-workers, durable-objects, gateway, hypervisor, mcp, model-context-protocol, rust, typescript, workerd ``` Why it works: - **Language(s):** `rust`, `typescript` - **Framework / runtime:**