Auto Workflow

<!-- autoresearch: variation B — sharper output (priority tiers + data-verification gates + delta-against-existing + exit taxonomy) + slug-enable execution branch (validate → commit → PR) -->

${var} — selects the mode:

• Analyze (default): a URL to analyze (GitHub repo, X account, blog, project site, API docs, etc.). Multiple URLs comma-separated. Prefix a URL with force: to re-analyze one already in the ledger. Produces a tiered recommendation article + an aeon.yml diff — it does not mutate aeon.yml.
• Enable: enable:slug1,slug2,… — flip those skills' enabled: false → true in aeon.yml, validate each against skills/, then commit + open a PR. enable:dry-run:slug1,slug2 validates and reports without editing, committing, or opening a PR.

Example values: https://example.com/blog · @vitalikbuterin, github.com/foundry-rs/foundry · force:https://mirror.xyz/somedao · enable:rss-digest,github-monitor · enable:dry-run:price-alert

Overview

One skill, two ends of the same loop: analyze decides what to enable for a new watch target; enable actually flips the switch. Dispatch enable: with the slugs the analyze run put in its MUST tier and you close the loop — recommendation to merged PR — without a second skill.

Analyze mode verifies every recommendation is backed by an observed signal on the URL, tiers output into MUST (2–3 max) / SHOULD / NICE with a one-line concrete "why", emits a delta against the current aeon.yml rather than a full config dump, stays silent when existing config already covers the URL, and anchors skill names in skills.json (authoritative), not a stale mapping table. It writes an article + updates a ledger; it never edits aeon.yml.

Enable mode does the mechanical part analyze deliberately leaves to the operator: a slug-scoped enabled: false → true substitution in aeon.yml, gated by directory presence / current-disabled-state / chain-conflict checks, committed on a fresh branch and shipped as a PR with per-skill rationale. Explicit opt-in only — the operator names the slugs; nothing flips on main until they click merge.

Shared preamble (run for both modes)

1. Read memory/MEMORY.md for high-level context and skim the last ~3 days of memory/logs/ — drop anything already reported so you don't re-emit the same signal.
2. Parse ${var} to pick the branch:
   • ${var} is empty → Analyze branch, empty-input path → exit AUTO_WORKFLOW_EMPTY, notify auto-workflow: set var= to one or more URLs (comma-separated), or enable:slug1,slug2 to flip skills on.
   • ${var} starts with enable: (case-insensitive) → Enable branch. Strip the enable: prefix; the remainder is the slug list (which may itself begin with dry-run:). Go to Mode B.
   • Otherwise → Analyze branch. Go to Mode A.

Mode A — Analyze: generate recommendations + aeon.yml diff (default)

A0. Parse input and load context

If the (post-preamble) input is empty → exit AUTO_WORKFLOW_EMPTY, notify as above.

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.

A1. 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.

A2. 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):

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

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.

A3. 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 complements a MUST for this URL, and ≤1h of operator attention/week.
• NICE — tangentially relevant, likely noise unless operator has prior interest signal in MEMORY.md.

For each tiered recommendation, write a single-sentence why that names at least one concrete signal from the URL:

• ✅ GOOD: rss-digest — MUST. Feed at /feed.xml, 12 posts in last 30d, cadence active.
• ✅ GOOD: fetch-tweets — MUST. Handle @example, profile links 3 active product threads.
• ❌ BAD: rss-digest — MUST. Blogs usually have feeds. (generic, no URL signal)
• ❌ BAD: token-alert — SHOULD. Crypto project, might want price alerts. (no contract verified)

Banned justifications: "typically", "often", "you might want", "could be useful", "in case". If you catch one of those, rewrite or drop the recommendation.

Dormant URLs (update_cadence = dormant): demote all candidates by one tier. If MUST → SHOULD. If SHOULD → NICE. If NICE → drop.

A4. Compare against current aeon.yml (delta, not dump)

For each tiered recommendation, compute the delta:

Skills with action NO_CHANGE drop out of the output. If EVERY tiered recommendation is NO_CHANGE → exit AUTO_WORKFLOW_NO_CHANGE:

• Log: ### auto-workflow\n- Mode: analyze\n- Input: ${var}\n- Exit: NO_CHANGE — existing config covers ${N_OK}/${N_TOTAL} URLs\n- Ledger updated
• Notify nothing (silence on no-op preserves signal-to-noise)
• Still update the ledger

Recommendations with action ENABLE are the exact slugs the operator can hand back to Enable mode — surface them as a copy-paste enable: dispatch (see A6).

A5. Emit secret/config gaps

For each MUST/SHOULD skill:

• Read skills/{slug}/SKILL.md (skip if missing — flag CATALOG_DRIFT in footer).
• Grep the skill body for \$[A-Z][A-Z0-9_]{2,} to enumerate env-var references.
• Compare against workflow secrets referenced in .github/workflows/*.yml (grep secrets\.[A-Z_]+).
• If an env var is referenced in the skill but never passed through workflows → tag the recommendation MISSING_SECRET: <NAME>.

Never read or echo secret values. Enumerate names only.

A6. Write article and notify

Output shape (keep it tight — no tables for empty categories):

# Auto-Workflow: ${input_summary}
*${today} · ${exit_mode}*

**Verdict:** ${one_line}
<!-- examples:
"2 new enables, 1 var update. Missing VERCEL_TOKEN blocks deploy-prototype recommendation."
"1 new enable. All else already active."
-->

## URLs

| URL | Category | Cadence | Key signals |
|-----|----------|---------|-------------|
| ... | blog-or-news | active | feed=/rss.xml, 12 posts/30d |

## MUST (apply now)

- **rss-digest** — `ENABLE`, var: `"https://example.com/feed"`, schedule: `"0 7 * * *"`. Feed at /feed.xml, 12 posts in 30d. Secrets: OK.
- **fetch-tweets** — `SET_VAR`, var append: `"@example"`, schedule unchanged. Handle active, 3 product threads last week. Secrets: MISSING_SECRET: X_API_BEARER.

## SHOULD (consider this week)

- **github-monitor** — ...

## NICE (only if interested)

- **paper-pick** — ...

## aeon.yml diff

\`\`\`yaml
# enable
rss-digest: { enabled: true, schedule: "0 7 * * *" }

# update var (existing: "")
fetch-tweets: { enabled: true, var: "@example" }
\`\`\`

## Apply the enables

Flip the `ENABLE` recommendations in one dispatch:

\`\`\`
enable:${comma_separated_ENABLE_slugs}
\`\`\`

(or `enable:dry-run:${...}` to preview the PR without committing)

## feeds.yml additions

\`\`\`yaml
feeds:
  - name: Example
    url: https://example.com/feed
\`\`\`

## New skill proposals

(none unless ≥2 URLs share a gap no installed skill fills — see constraints)

## Source status

- fetch: ${N_OK}/${N_TOTAL} (failed: ${list with reasons})
- classification: ${N_CLASSIFIED} / ${UNCLASSIFIED count}
- verification: ${verified_count} passed, ${unverified_count} dropped (${sample reasons})
- catalog drift: ${list of referenced slugs missing on disk, or "none"}
- missing secrets: ${sorted unique list, or "none"}
- ledger: ${dedup_skipped} URLs already analyzed in last 14d (use `force:URL` to re-run)

## Exit mode
${AUTO_WORKFLOW_OK | AUTO_WORKFLOW_NO_CHANGE | AUTO_WORKFLOW_EMPTY | AUTO_WORKFLOW_FETCH_FAILED | AUTO_WORKFLOW_UNCLASSIFIED | AUTO_WORKFLOW_ERROR}

Append to memory/topics/auto-workflow-analyzed.md:

## ${today}
- ${normalized_url} — ${category} — ${N_must} MUST / ${N_should} SHOULD — output/articles/auto-workflow-${today}.md

Log to memory/logs/${today}.md (see the shared Log section — analyze discriminator).

Notify via ./notify — but only if exit_mode ∈ {OK, FETCH_FAILED_PARTIAL, ERROR, UNCLASSIFIED}. Skip on NO_CHANGE.

Template:

*Auto-Workflow — ${today}*
${exit_mode}

${verdict_one_line}

MUST (${N}):
- skill-a → ${action} (why)
- skill-b → ${action} (why)

${missing_secrets_line_if_any}

Apply: enable:${comma_separated_ENABLE_slugs}
Full: output/articles/auto-workflow-${today}.md

Mode B — Enable: flip skills enabled by slug (validate → commit → PR)

Today is ${today}. Skills can sit at enabled: false for days while the operator is occupied elsewhere. The human review of "is this skill ready to run" is not what blocks activation — the typing is. This branch makes the typing one dispatch.

Flipping enabled: false → true in aeon.yml is mechanical:

• The text-edit is a single regex-safe substitution per skill
• Validation is straightforward: skill directory exists, current state is enabled: false, slug doesn't appear under chains: (which would conflict with a top-level entry)
• The risk is low: the worst case is a noisy skill, fixed by a one-line revert PR

Explicit opt-in is the safety bar. No scheduled run, no automatic discovery. The operator names the slugs (or copies them from an analyze run's enable: line). The branch validates them and writes a PR — nothing flips on main until the operator clicks merge.

The input to this branch is the post-enable: remainder of ${var} (call it ENABLE_INPUT).

B1. Parse the slug list

• ENABLE_INPUT empty → log SKILL_ENABLER_NO_INPUT and exit. Do not flip anything on empty input. Send no notification — silence is correct when there's nothing to do. (This preserves the "never flip on empty" safety bar: enable: with no slugs is a silent no-op.)
• ENABLE_INPUT starts with dry-run: → MODE=dry-run. Strip the prefix; the remainder is the slug list. In dry-run: parse + validate + report, but do not edit aeon.yml, commit, or open a PR.
• Otherwise → MODE=execute. Treat ENABLE_INPUT as the slug list.

Split the slug list on comma. Trim whitespace from each entry. Drop empty entries (handles trailing commas). Lowercase each slug. Deduplicate, preserving first-seen order.

Validate slug format: each must match ^[a-z0-9][a-z0-9-]{0,63}$. Slugs that fail this check are tagged BAD_SLUG_FORMAT in step B3 — they don't poison the run, but they don't get enabled either.

If after parsing the input list is empty (e.g. it was just commas/whitespace), log SKILL_ENABLER_NO_INPUT and exit silently.

B2. Read source state

Required reads — all in the current working directory (this fork's repo root):

• aeon.yml — the file to patch. Read once at start; rewrite once at end.
• skills/ directory — ls skills/ gives the set of skills present in this fork. A slug must have a skills/${slug}/ directory or it's MISSING_DIRECTORY.
• skills.json (optional) — used for the per-skill rationale ("registered skill: <description>"). Missing skills.json is a warning, not a failure; rationale falls back to the SKILL.md frontmatter description field, then to the slug itself if both are absent.

If aeon.yml is missing or unreadable → log SKILL_ENABLER_NO_CONFIG and exit with notification (operator can't proceed without it).

B3. Validate each slug

For each parsed slug, walk these gates in order. The first failing gate is the slug's verdict; do not check subsequent gates for that slug.

For each slug record one of:

• ELIGIBLE — passed every gate
• one of the failure tags above