atrium-catalog-watcher

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

Today is ${today}. The `install-from-atrium` script (merged in PR #335, the third skill install path after `add-skill` and `install-skill-pack`) fetches skills from the Atrium onchain marketplace at `https://atriumhermes.tech/.well-known/skills/index.json`. The endpoint is the live source of truth for everything publishable through `./install-from-atrium <name>`, but the operator has no signal when new skills appear in it. A skill that ships on Atrium is discoverable today only by running `./install-from-atrium --list` by hand. By the time `install-from-atrium` is used reactively (after someone mentions a skill), the skill may already have been live for days.

This skill closes that gap. It is a weekly Friday watcher of the Atrium catalog — what was added, what was removed, what was renamed or had its description changed, all reported as a structured digest. Pairs with `sparkleware-catalog` (Tuesday 09:00 — curated `skill-packs.json` registry) as the supply-side equivalent for the *discovered* Atrium marketplace, and with `skill-update-check` (Sunday 19:00 — version drift on already-installed skills) as the **upstream-arrivals** signal that precedes any install decision.

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 a separate skill from sparkleware-catalog and skill-update-check

| Skill | Source | Question answered | Cadence |
|-------|--------|-------------------|---------|
| `sparkleware-catalog` | `skill-packs.json` (curated registry, Aeon repo) | "What's in the curated pack registry and is it healthy?" | Tuesday 09:00 UTC |
| `skill-update-check` | `skills.lock` × upstream SHAs | "Did any of my already-installed skills change upstream?" | Sunday 19:00 UTC |
| **`atrium-catalog-watcher`** | **`atriumhermes.tech/.well-known/skills/index.json` (Atrium marketplace)** | **"What new skills are publishable on Atrium this week?"** | **Friday 12:00 UTC** |

The three signals compose without overlap. `sparkleware-catalog` watches the **curated** registry that ships in the repo; `skill-update-check` watches **installed** skills against their upstream sources; `atrium-catalog-watcher` watches the **public marketplace** for new arrivals before any install decision. A skill that lands in the Atrium catalog and is also added to `skill-packs.json` will appear in both Tuesday and Friday digests — that's expected and not duplication (the two skills answer different questions: "curated and trusted?" vs. "publishable on the chain?").

Building this into `install-from-atrium` itself would have entangled the install path with surveillance: today the script is a thin fetcher (curl → scan → copy), and adding a state file + diff logic to a single-use install command would conflate one-shot install with weekly polling. Keeping them separate keeps each surface structurally simple.

## Inputs

| Source | Purpose | Auth |
|--------|---------|------|
| `https://atriumhermes.tech/.well-known/skills/index.json` | Live Atrium marketplace catalog — array of `{name, description, files, skill_id}` entries | None (public) |
| `memory/topics/atrium-catalog-state.json` | Prior-run snapshot of the catalog, keyed by `skill_id` | Local file |

No new secrets. The Atrium endpoint is public — no auth header, no env-var expansion. `ATRIUM_HOST` (default `https://atriumhermes.tech`) is honored as an override so a self-hosted Atrium can be pointed at without editing the skill, mirroring the existing `install-from-atrium` convention.

Writes:
- `memory/topics/atrium-catalog-state.json` — current parsed catalog (keyed by `skill_id`) + `last_run` timestamp + `last_status`
- `articles/atrium-catalog-watcher-${today}.md` — digest on every non-error run (including QUIET; the article is the durable record even when the notification is suppressed)
- `memory/logs/${today}.md` — one log block per run
- Notification via `./notify` — only when ≥1 added or removed entry since the last run (see step 6)

## Catalog schema

The Atrium endpoint returns a JSON object with one top-level key `skills`, an array of skill objects:

```json
{
  "skills": [
    {
      "name": "string",
      "description": "string",
      "files": ["SKILL.md"],
      "skill_id": "0x<64-hex>"
    }
  ]
}
```

`skill_id` is the **canonical key** for an entry — it is the onchain identifier and is collision-free by design (it is the same id `install-from-atrium 0x...` accepts). A skill whose `name` is renamed but keeps the same `skill_id` is reported as `updated`, not as an add+remove pair. A skill that publishes a new version under a new `skill_id` is treated as a fresh entrant — that matches the operator's mental model (a new id is a new installable artefact).

The endpoint may evolve to include a `cid` or `version` field per skill (the `install-from-atrium` script already reads a `cid` from the per-skill SKILL.md frontmatter for `skills.lock` provenance). The parser tolerates extra fields and ignores anything not in the four documented keys above — additions don't break the diff.

## State schema

`memory/topics/atrium-catalog-state.json`:

```json
{
  "last_run": "2026-06-05",
  "last_status": "ATRIUM_CATALOG_WATCHER_OK",
  "atrium_host": "https://atriumhermes.tech",
  "skills": {
    "0xabc...": {
      "name": "example-skill",
      "description": "string",
      "files": ["SKILL.md"],
      "first_seen": "2026-04-20",
      "last_seen": "2026-06-05"
    }
  }
}
```

`first_seen` is the date this `skill_id` first appeared in any run — never overwritten. `last_seen` is the most recent run where the id was present — overwritten every run that sees it. An entry whose `last_seen` is more than 56 days old is **pruned** from the state file (longer than `ecosystem-entrants`' 28-day window because th