github-trending

<!-- autoresearch: variation B — sharper output via curation, clustering, "why notable" gate, momentum tags -->

> **${var}** — Source selector plus optional sub-scope:
> - empty or `github` → **GitHub trending**, all languages (default)
> - `github:<lang>` — or a bare language token like `python`, `typescript`, `rust` (backward-compatible with the old GitHub var) → GitHub trending filtered to that language
> - `hf` or `huggingface` → **Hugging Face trending** across models + datasets + spaces
> - `hf:models` / `hf:datasets` / `hf:spaces` (also `huggingface:models`, etc.) → Hugging Face trending scoped to a single resource type

This skill covers two neighbouring layers of where developer/AI attention is moving today: the **repo layer** (GitHub trending) and the **artifact layer** (Hugging Face Hub — the models, datasets, and spaces that ship alongside, and frequently before, the paper). Both branches share the same contract: don't dump the top 10 (the source's own front page already does that) — deliver a **curated** slate of 5–8 picks a busy reader would actually want to click, grouped by category, with a one-line "why notable" and a momentum tag per pick.

## Shared preamble (run for every invocation)

Read `memory/MEMORY.md` for context.
Read the last 3 days of `memory/logs/` to dedupe items you've already featured (the GitHub branch dedupes against the last **2** days, the Hugging Face branch against the last **3** — see each branch's filter step).
Read `soul/SOUL.md` + `soul/STYLE.md` if populated to match voice.

**Parse `${var}` into a source + optional sub-scope** (deterministic):

1. If `${var}` is empty → **GitHub branch**, no language filter.
2. Otherwise trim + lowercase and split on the first `:` into `head` and optional `tail`.
3. `head` ∈ {`hf`, `huggingface`} → **Hugging Face branch**. If `tail` is present it must be one of `models` / `datasets` / `spaces` (that becomes the resource sub-scope); any other `tail` → exit `HF_TRENDING_BAD_VAR` (no notify). No `tail` → pull all three resource types.
4. `head` == `github` → **GitHub branch**. If `tail` is present, it's the language filter.
5. Any other value (no colon, `head` not `hf`/`huggingface`/`github`) → **GitHub branch**, treating the whole `${var}` as the language filter (e.g. `rust`).

Then jump to the matching branch below and run it end to end.

---

## Branch A — GitHub trending (source = `github`)

Don't just dump the top 10 trending repos — GitHub already shows that. Deliver a **curated** slate of 5-8 repos that a busy dev would actually want to click, grouped by category, stripped of noise, with a one-line "why notable" per pick and a momentum tag.

### A1. Fetch candidates

Fetch the daily trending page via **WebFetch** (it renders the HTML for you; `curl` works too — there is no network sandbox):
```
https://github.com/trending?since=daily
```
If a language filter was resolved from `${var}`, append the language segment: `https://github.com/trending/<lang>?since=daily`.

Extract for each of the ~25 returned repos:
- `owner/repo`
- one-line description
- primary language
- stars today (the "X stars today" widget)
- total stars
- URL

### A2. Enrich with velocity metadata (supplementary)

For the 10-15 repos that survive the filter in step A3, try to enrich with **stars-per-day since creation** using `gh api` (handles auth internally, so no token touches the command line):
```bash
gh api "repos/OWNER/REPO" --jq '{created_at, stargazers_count, pushed_at}'
```
Compute `velocity = stargazers_count / max(days_since_created, 1)`.

If `gh api` fails for a repo, skip enrichment for that one — it's not required, just informative.

> Read-only note: this skill runs `read-only`, so `gh api` (and any repo mutation) may be stripped from your toolset. If `gh api` is unavailable, skip enrichment entirely and rely on the "stars today" widget; velocity-dependent tags degrade gracefully (see A5).

### A3. Filter noise (required)

**Drop** any repo matching these patterns — they're low-signal for a dev audience:
- **Meta-lists**: repo names containing `awesome-`, `awesome_`, `-list`, `free-`, `public-apis`, `interview-`, `cheatsheet`, `resources`
- **Bare tutorials / learn-X**: names starting with `learn-`, `build-your-own-`, `30-days-of-`, `X-in-Y`, `hello-world-*`
- **Non-code bundles**: dotfiles, config dumps, blog-source repos (check description for "my personal blog", "my dotfiles")
- **Low-activity**: stars today < 50 AND not new this week (created > 14 days ago)
- **Already featured**: repo appeared in `memory/logs/YYYY-MM-DD.md` in the last 2 days

If a repo *barely* fails a filter but is genuinely technically interesting (novel algorithm, new runtime, new framework), you may keep it — note it as a judgment call.

### A4. Require a "why notable" for each survivor

For every repo that survives filtering, write **one line** (≤ 18 words) explaining *why a dev should care today*. No paraphrasing the description.

Good: *"Replaces Electron with native webview bindings — ships a 3MB hello-world instead of 120MB."*
Bad: *"A new framework for building desktop apps."* (that's just the description)

If you can't write a concrete "why notable" line, **drop the repo**. The filter is the feature.

### A5. Tag momentum

Tag each surviving repo with one of:
- **DEBUT** — created within the last 14 days (first-time trending)
- **ACCELERATING** — velocity > 50 stars/day AND total stars > 500 AND older than 14 days
- **RETURNING** — older repo (> 90 days) trending again; note this means a release, a viral post, or a HN moment
- **HOLDOVER** — appeared in yesterday's logs (use sparingly; prefer to drop)

### A6. Cluster into categories

Buckets are **heuristic and author-inferred** — classify by the repo's primary utility, not by author self-description. Cap total buckets at **5** (merge adjacent ones if you hit 6+; e.g. fold Data into Infra).

Group survivors into these buckets (omit empty ones):
- **AI/ML** (models, inference, agents, trai