Refresh Metadata

Refresh the awesome-ev-charging listing metadata

The published project listing (## Tools and Resources in README.md, between <!-- BEGIN GENERATED PROJECTS --> / <!-- END GENERATED PROJECTS -->) is generated from repos.enriched.csv by pipeline.py. Over time the upstream GitHub numbers drift — repos gain stars, get archived, or cross the DORMANT_DAYS threshold — so the listing needs a periodic refresh. This skill is that maintenance pass: re-fetch GitHub, re-classify only what changed, and re-render, in the correct order with one clean commit.

This is not add-project. There is no repo to make discoverable, no category to pin, no issue to close. If the goal is to add or remove one specific repo, use add-project instead — it handles the discovery + reconciliation steps this skill deliberately skips.

Read AGENTS.md in the repo root for the authoritative "why" behind the pipeline; this skill is the executable "how" for the refresh case.

Preconditions

• mise trust has been run (mise pins Python 3.11 and auto-activates .venv).
• gh auth token works — the mise tasks wire it in for the GitHub API and the GraphQL-only Stars lists (STARRED_LISTS), which are skipped when unauthenticated. Check with gh auth token >/dev/null && echo OK.

The cache decision (do this first — it's the whole point)

Nearly every GitHub read goes through a filesystem cache in cache_github/ with a 24h TTL (CACHE_TTL in pipeline.py). This is the step a naive re-run gets wrong: if the cache is fresh, ingest reads it and the metadata does not change — you'd just re-derive identical docs. Two reads bypass the cache and hit the API on every run (get_starred_repos_for_user, and the search pagination), so a fresh cache makes the run cheap and the rendered signals stable — it does not guarantee a byte-identical ingest.

So decide based on why you're refreshing:

• You want fresh GitHub numbers (stars, pushed_at, newly-archived repos) — the cache must be older than the data you want, or cleared. Check its age:

  find cache_github -type f -printf '%T@\n' 2>/dev/null | sort -rn | head -1 \
    | awk -v now="$(date +%s)" '{ printf "newest cache file: %.1fh old (TTL 24h)\n", (now-$1)/3600 }'

  If the newest file is < 24h old and you need genuinely fresh numbers, clear the cache before ingesting:

  rm -rf cache_github/

  If it's already > 24h old, the TTL has expired — ingest will re-fetch on its own, no need to clear.

• You only need to re-derive the docs from CSVs you (or a prior run) already produced — e.g. after tweaking render logic — then do not touch the cache and you can skip straight to render (Step 3). Hand-editing classifications.csv is not one of those cases: render reads repos.enriched.csv, not the classification cache, so keep the cache and re-run mise run enrich (incremental, so it's cheap) to carry the edit through, then render.

Don't clear a fresh cache reflexively. Clearing forces ~900 API calls and a longer run; only do it when you actually want newer-than-cache data. When in doubt, tell the user the cache age and let them choose.

Workflow

1. Ingest → repos.csv

Re-collects candidates from all four discovery sources and rebuilds every record (so stars, pushed_at, dormant, etc. reflect current GitHub — or the cache, per the decision above).

mise run ingest