Auto-Workflow Builder

<!-- autoresearch: variation B — sharper output (priority tiers + data-verification gates + delta-against-existing + exit taxonomy) -->
> **${var}** — URL to analyze (GitHub repo, X account, blog, project site, API docs, etc.). Multiple URLs comma-separated. Prefix with `force:` to re-analyze a URL already in the ledger.

## Overview

The operator runs this on-demand to decide *what to enable* for a new watch target. Original produces a wall of tables with no priority and recommends skills that may not actually have data to work with. This version:

1. Verifies every recommendation is backed by an *observed* signal on the URL.
2. Tiers output into **MUST** (2–3 max), **SHOULD**, **NICE** with a one-line concrete "why".
3. Emits a *delta* against current `aeon.yml` rather than a full config dump.
4. Stays silent (no notification, no article) when existing config already covers the URL.
5. Anchors skill names in `skills.json` (authoritative), not a stale mapping table.

---

## Steps

### 0. Parse input and load context

If `${var}` is empty → exit `AUTO_WORKFLOW_EMPTY`, notify `auto-workflow: set var= to one or more URLs (comma-separated)`.

Parse `${var}`:
- Split on `,`, trim each entry
- Detect `force:` prefix on any entry → sets `force=true` for that URL (skip ledger dedup)
- Normalize each URL:
  - Add `https://` if scheme missing
  - `twitter.com/` → `x.com/`
  - `@handle` → `https://x.com/handle`
  - Strip trailing `/`, fragment, and tracking params (`utm_*`, `ref`, `src`, `s`, `t`)
  - Strip trailing `.git` on github URLs
- Reject `javascript:`, `data:`, local file URLs → exit `AUTO_WORKFLOW_ERROR` with the bad URL

Read context:
- `memory/MEMORY.md` — operator interests
- `aeon.yml` — CURRENT skill enablement, `var`, `schedule`, `model` per skill (this is the comparison baseline)
- `skills.json` — authoritative installed-skill list
- `memory/topics/auto-workflow-analyzed.md` (if exists) — for ledger dedup

**Ledger dedup:** If a URL is in the ledger with `analyzed_at` within the last 14 days and `force` is not set for it, skip it with `already_analyzed` reason. If ALL inputs are dedup-skipped → exit `AUTO_WORKFLOW_NO_CHANGE`, notify nothing, log a one-line skip entry.

---

### 1. Fetch and classify

For each remaining URL, `WebFetch` with prompt: "Return page title, meta description, all <link rel='alternate'>, og:* meta tags, social handle links (x.com, github.com, t.me, discord), detected RSS/Atom feed URLs, and any token contract addresses (0x… or Solana base58 near the words 'token'/'contract'/'mint'). Report the most recent date on the page. Report the tech stack (Jekyll/Hugo/Next.js/WordPress etc)."

If fetch fails or returns <300 chars of meaningful content, try fallbacks: `/robots.txt`, `/sitemap.xml`, `gh api` for github URLs. If all fail → mark this URL `FETCH_FAILED` with reason and continue to next URL.

Classify into ONE primary category: `github-repo` / `github-org` / `x-account` / `blog-or-news` / `crypto-project` / `api-or-docs` / `research` / `product` / `community` / `personal-site` / `other`.

Extract **concrete signals** (the "why" anchors for later recommendations):
- `feed_urls`: list of RSS/Atom URLs discovered
- `x_handles`: list of X handles linked from page
- `github_repos`: list of owner/repo from page links
- `token_contracts`: list of (chain, address, symbol) tuples
- `last_update`: most recent date found (ISO)
- `update_cadence`: estimate — `active` (<7d old), `steady` (<30d), `quiet` (<90d), `dormant` (≥90d)
- `tech`: stack hint if any

If classification confidence is low (sparse signals, no category clearly matches), mark `UNCLASSIFIED` for this URL and skip to next.

---

### 2. Match signals to installed skills

For each URL, generate candidate skills by intersecting:
- URL `category` and extracted signals
- Skills present in `skills.json`

Use this hint table — but **only emit skills whose slug exists in `skills.json`** (drop any slug not found):

| Category | Hint skills | Requires signal |
|----------|-------------|----------------|
| github-repo | github-monitor, github-issues, github-releases, pr-review, push-recap, repo-pulse, repo-article, code-health | `owner/repo` resolves via `gh api` |
| github-org | github-monitor, repo-pulse, repo-scanner | `owner` resolves as Organization or User with ≥5 repos |
| x-account | fetch-tweets, tweet-roundup, list-digest, refresh-x | `x_handle` extracted |
| blog-or-news | rss-digest, digest, article | ≥1 `feed_url` OR dated articles |
| crypto-project | token-alert, token-movers, onchain-monitor, defi-monitor, treasury-info | `token_contract` OR `token_symbol` |
| api-or-docs | deep-research | product is genuinely new + operator interest match |
| research | paper-pick, paper-digest, research-brief | arXiv-like URL or lab site |
| community | reddit-digest, telegram-digest, farcaster-digest, channel-recap | corresponding channel URL on page |
| product | deep-research, search-skill | operator interest match |
| personal-site | rss-digest, fetch-tweets | needs feed OR handle |

For each candidate, verify: **does this URL actually have the data the skill needs?**

| Skill need | Verification |
|------------|-------------|
| RSS feed URL | at least one valid `feed_url` in signals |
| X handle | `x_handle` extracted (not just a generic x.com link) |
| GitHub owner/repo | `gh api` returns 200 |
| Token contract | contract verified on DexScreener/CoinGecko (WebFetch fallback) |
| Topic string | operator's `MEMORY.md` mentions the topic or category |

**If verification fails, do not recommend the skill.** Record the skipped candidate as `unverified: <reason>` in the source-status footer — never carry to the output table.

---

### 3. Tier and justify

Rank each verified candidate into exactly one tier:

- **MUST** — skill produces the *primary* value for this URL type AND the URL is active or steady (`update_cadence` ≠ dormant). Cap at **3 per URL**, **5 total across batch**.
- **SHOULD** — skill meaningfully