sparkleware-catalog

SKILL.md preview

---
name: sparkleware-catalog
description: Enriched export of skill-packs.json — joins the canonical community registry to live GitHub signals (stars, last-push, live manifest skill count) and writes a machine-readable skill-packs-catalog.json that external tools (e.g. Sparkleware) can consume without screen-scraping
var: ""
tags: [dev, community]
---

> **${var}** — Optional. `dry-run` skips notify (catalog, article, and state still write). Empty = normal run.

Today is ${today}. Issue #244 introduced **Sparkleware** (`sparkleware/sparkleware`, live at sparkleware.vercel.app) — an external, community-owned discovery catalog that crawls GitHub for `topic:aeon-skill-pack` repos and surfaces each pack with its install command, category, stars, and freshness signals. It complements Aeon's canonical `skill-packs.json` registry rather than replacing it. But Sparkleware crawls GitHub directly and has **no view into `skill-packs.json`** — the curated entries with `trust_level`, declared slug arrays, and human-written descriptions that aeon operators actually install from. This skill bridges that gap: it reads `skill-packs.json`, enriches each entry with live GitHub signals, and writes a stable machine-readable `skill-packs-catalog.json` that any external tool can fetch from `raw.githubusercontent.com/aaronjmars/aeon/main/skill-packs-catalog.json` without scraping the README table.

Read `memory/MEMORY.md` for context.
Read the last 8 days of `memory/logs/` for prior-run context.
Read `soul/SOUL.md` + `soul/STYLE.md` if populated to match voice in the notification and article.

## Why this exists

`skill-packs.json` is the *curated* registry: a human decides what goes in it, and `trust_level: "trusted"` is a meaningful editorial signal. Sparkleware is the *discovered* catalog: anything with the `aeon-skill-pack` topic surfaces automatically. The two are complementary, but right now the curated data is locked in a static JSON file with **no freshness layer** — a registry entry says a pack has 6 skills, but that number is frozen at the moment a human edited it. If the pack added two skills last week, archived itself, or went private, `skill-packs.json` doesn't know. This skill turns the static registry into a weekly-refreshed health view: it keeps the human curation (descriptions, trust levels) and overlays live truth (current stars, last-push recency, live manifest skill count, reachability), then publishes the join as a feed external tools can rely on.

It is **read-only** against both the registry and the GitHub API — it never edits `skill-packs.json` itself (registry curation stays a human PR decision, same contract as `ecosystem-pulse` has with `ECOSYSTEM.md`).

## Inputs

| Source | Purpose | Auth |
|--------|---------|------|
| `skill-packs.json` (repo root) | The canonical registry — repo, name, description, author, trust_level, category, declared `skills` slug array | Local file |
| `gh api repos/{owner}/{repo}` | Live `stargazers_count`, `pushed_at`, `description`, `archived` for each pack repo | `GH_TOKEN` (gh CLI handles auth) |
| `gh api repos/{owner}/{repo}/contents/skills-pack.json?ref={default_branch}` | Live pack manifest — current skill count + slug list (base64-decoded) | `GH_TOKEN` |
| `memory/topics/sparkleware-catalog-state.json` | Prior-run snapshot for the delta gate (which packs existed / were reachable last run) | Local file |

No new secrets. GitHub access uses the `gh` CLI (`GH_TOKEN`), which handles auth internally — see Sandbox note.

Writes:
- `skill-packs-catalog.json` (repo root) — the machine-readable enriched catalog (overwritten each run; stable filename, no timestamp, so the raw URL is permanent)
- `articles/sparkleware-catalog-${today}.md` — human-readable pack-health table (every non-error run, including QUIET)
- `memory/topics/sparkleware-catalog-state.json` — prior-run snapshot
- `memory/logs/${today}.md` — one log block per run
- Notification via `./notify` — only when the registry composition o

…