Add aeon plugin (Aeon agent operator console)

.claude-plugin/marketplace.json

@@ -2316,6 +2316,26 @@
         "tokens",
         "audit"
       ]
+    },
+    {
+      "name": "aeon",
+      "source": "./plugins/aeon",
+      "description": "Operator console for an Aeon agent instance - enable/schedule/edit skills, wire secrets and channels, debug runs, and mine past Claude Code chats into scheduled skills.",
+      "version": "0.1.0",
+      "author": {
+        "name": "Aeon Inc",
+        "url": "https://github.com/aeonfun"
+      },
+      "category": "Automation DevOps",
+      "homepage": "https://github.com/ccplugins/awesome-claude-code-plugins/tree/main/plugins/aeon",
+      "keywords": [
+        "agent",
+        "automation",
+        "cron",
+        "github-actions",
+        "skills",
+        "aeon"
+      ]
     }
   ]
 }

README.md

@@ -114,6 +114,7 @@ Install or disable them dynamically with the `/plugin` command — enabling you
 - [speech-ai](https://github.com/fasuizu-br/speech-ai-examples) - Speech AI plugin with pronunciation assessment, text-to-speech, and speech-to-text. 8 MCP tools for language learning, accessibility, and voice applications.
 
 ### Automation DevOps
+- [aeon](./plugins/aeon) - Operator console for an Aeon agent instance. Enable/schedule/edit skills, wire secrets and channels, debug runs, and mine past Claude Code chats into scheduled skills.
 - [PUIUX Pilot](https://github.com/PUIUX-Cloud/puiux-pilot) - Auto-configures Claude Code hooks, MCPs, and skills for any project. Scans 95+ project types, selects from 28+ hooks, scores quality (0-100, A-F). `npm i -g puiux-pilot`
 - [deployment-engineer](./plugins/deployment-engineer)
 - [devops-automator](./plugins/devops-automator)

plugins/aeon/.claude-plugin/plugin.json

@@ -0,0 +1,13 @@
+{
+  "name": "aeon",
+  "version": "0.1.0",
+  "description": "Operator console for an Aeon agent instance: enable/schedule/edit skills, wire secrets and channels, debug runs, and mine past Claude Code chats into scheduled skills.",
+  "author": {
+    "name": "Aeon Inc",
+    "url": "https://github.com/aeonfun"
+  },
+  "homepage": "https://aeon.fun",
+  "repository": "https://github.com/aeonfun/aeon",
+  "license": "MIT",
+  "keywords": ["aeon", "agent", "skills", "automation", "github-actions", "cron"]
+}

plugins/aeon/skills/aeon/references/ci.md

@@ -0,0 +1,76 @@
+# CI gates in `aeonfun/aeon`
+
+Eight `ci-*.yml` workflows. Every one is **path-filtered** and fires on `pull_request`, `push` to `main`, and `workflow_dispatch`.
+
+**None of them can block a merge.** `main` has no branch protection and the repo has zero rulesets — `gh api repos/aeonfun/aeon/branches/main/protection` returns 404. A red X is advisory. Nothing stops a broken PR from merging, and nothing stops a push straight to `main` (where the same gates run, and fail *after* the fact). So the only thing that actually keeps these respected is running them locally before pushing. Treat the checklist below as the enforcement.
+
+## The gates
+
+| Workflow | Fires when you touch | Enforces | Run locally |
+|---|---|---|---|
+| `ci-skill-category` | `skills/**` | every `SKILL.md` has a valid `category:` | `bash scripts/check-skill-categories.sh` |
+| `ci-skills-json` | `skills/**`, `bin/generate-skills-json`, `catalog/skills.json` | committed catalog == fresh regen | `bin/generate-skills-json` |
+| `ci-packs-json` | `catalog/packs.config.json`, **`catalog/skills.json`**, `bin/generate-packs-json`, `catalog/packs.json` | pack catalog == fresh regen; every skill in exactly one pack | `bin/generate-packs-json` |
+| `ci-tests` | `scripts/**`, `aeon.yml` | the 13 `scripts/tests/` suites + config validation | see below |
+| `ci-capabilities-parity` | `bin/install-skill-pack`, `docs/CAPABILITIES.md` | capabilities taxonomy in sync across both | `bash scripts/check-capabilities-parity.sh` |
+| `ci-skill-packs` | `catalog/skill-packs.json`, `.github/README.md`, `bin/install-skill-pack`, `skills/security/trusted-sources.txt` | community registry well-formed + matches README table; no unbacked `trust_level: trusted` | `node scripts/validate-skill-packs.mjs` |
+| `ci-agents-md` | `STRATEGY.md`, `AGENTS.md`, `scripts/gen-agents-md.js` | `AGENTS.md` regenerated from `STRATEGY.md` | `node scripts/gen-agents-md.js --check` |
+| `ci-apps` | `apps/**` | dashboard typecheck+test+build, cli typecheck, mcp-server build, webhook bundle | per app, see below |
+
+There is **no security-scan CI gate.** The pack security scan lives in `bin/install-skill-pack` and runs at *install* time, not in CI.
+
+## Checklist: adding or editing a skill
+
+This is the common case (Modes 4 and 5), and it trips **three** gates, not one. Run all of it from the repo root before opening the PR:
+
+```bash
+bash scripts/check-skill-categories.sh    # category is valid
+bin/generate-skills-json                  # refresh catalog/skills.json
+bin/generate-packs-json                   # REQUIRED — see the trap below
+node scripts/validate-config.js           # only if you touched aeon.yml
+git add catalog/skills.json catalog/packs.json
+```
+
+**The trap: `bin/generate-skills-json` alone is not enough.** It rewrites `catalog/skills.json`, which is itself a *trigger path* for `ci-packs-json`. Commit the skills catalog without regenerating the pack catalog and the PR goes red on a workflow you never touched. Always run both generators, always commit both files.
+
+Both files carry a `generated` UTC timestamp that changes on every run — that's expected. `ci-skills-json` and `ci-packs-json` normalize it out (plus per-skill `sha`/`updated`, which churn on every squash-merge), so a timestamp-only diff is not drift and won't fail. On a clean tree, regenerating both should produce exactly a one-line diff per file.
+
+### `category:` — the valid set
+
+`core evolution basics dev crypto productivity`. Anything else fails the gate. Category is the *only* thing deciding which pack a skill joins.
+
+## `ci-tests` in full
+
+Needs `pip install pyyaml==6.0.2` first. Thirteen steps:
+
+```bash
+python3 scripts/tests/test_notify_format.py
+bash    scripts/tests/test_notify.sh
+bash    scripts/tests/test_telegram_route.sh
+bash    scripts/tests/test_skill_mode.sh
+bash    scripts/tests/test_skill_requires.sh
+bash    scripts/tests/test_run_actions_summary.sh
+bash    scripts/tests/test_validate_pack.sh
+bash    scripts/tests/test_validate_skill_packs.sh
+bash    scripts/tests/test_run_grok.sh
+python3 scripts/tests/test_state_reduce.py
+python3 scripts/tests/test_health_triage.py
+node --test scripts/validate-config.test.js
+node    scripts/validate-config.js
+bash    scripts/tests/test_cron_due.sh
+```
+
+Editing `aeon.yml` alone is enough to fire this workflow — `node scripts/validate-config.js` is the one to run after any hand-edit (Mode 4 step 4).
+
+## `ci-apps` in full
+
+One job per app so a red X names the broken surface.
+
+```bash
+cd apps/dashboard && npm ci && npm run typecheck && npm test && npm run build
+cd apps/cli       && npm ci && npm run typecheck   # needs apps/dashboard deps installed first
+cd apps/mcp-server && npm install && npm run build
+cd apps/webhook   && node --check src/worker.js && npm install && npx wrangler deploy --dry-run --outdir /tmp/w
+```
+
+The dashboard runs **both** `typecheck` and `build` on purpose: a past Dependabot bump crashed `next build` while `tsc --noEmit` passed. Don't treat the typecheck as sufficient. The CLI cannot typecheck without the dashboard's `node_modules` — its tsconfig compiles `../dashboard/lib/**/*.ts` and borrows that app's typescript and `@types`. `mcp-server` and `webhook` commit no lockfile, so `npm ci` is unavailable there.

plugins/aeon/skills/aeon/references/history-mining.md

@@ -0,0 +1,168 @@
+# History mining — deep reference (Mode 8)
+
+`scripts/mine-history.mjs` reads the operator's local Claude Code transcripts and
+surfaces recurring work that could become a scheduled Aeon skill. This file is the
+detail behind Mode 8: what the tool reads, how it ranks, and how to turn a digest
+row into a real skill without proposing junk.
+
+## What it reads
+
+Claude Code writes one JSONL transcript per session under
+`~/.claude/projects/<encoded-cwd>/<session-uuid>.jsonl`. Each line is a record;
+the ones the miner uses:
+
+| record `type` | field | used for |
+|---|---|---|
+| `ai-title` | `aiTitle` | the session's generated title — the semantic label for theme grouping (last one in a file wins = freshest) |
+| `user` | `message.content` (string) | real human prompts — only plain strings without a `<system-reminder>`/`<command-name>` wrapper; tool-result echoes are lists and are skipped |
+| `assistant` | `message.content[].tool_use` | `Bash` commands → normalised workflows; `mcp__*` names → MCP tool usage |
+| any | `cwd`, `timestamp`, `sessionId` | project scoping, cadence (distinct days), dedup |
+
+It only scans **top-level sessions** — files under a `subagents/` path are
+sidechains (agent fan-out) and would double-count the parent's work, so they're
+skipped. The scan window is bounded by file mtime (`--days`, default 120) so it
+stays a few seconds even over thousands of transcripts.
+
+## How it ranks
+
+Everything is ranked by `distinct sessions × 1000 + distinct days × 10 + runs` —
+so **breadth of recurrence dominates raw volume**. A command run 500 times in one
+marathon session ranks below one run once each across 20 days: the second is a
+habit with a cadence, the first is a one-off you happened to repeat. Days are the
+cadence signal that tells you *daily* vs *weekly* when you get to `schedule:`.
+
+`--min-sessions N` (default 2) drops anything seen in a single session — a true
+one-off is never an automation candidate.
+
+### Command normalisation
+
+Each `Bash` command is split on `&&`, `|`, `;`, and loop keywords into segments;
+each segment's first token becomes `binary subcommand` (for `node`/`python3` the
+script basename is the "subcommand", since that's the recurring workflow). Two
+denylists keep the signal clean:
+
+- **`NOISE_BIN`** — file-poking and shell/JS keywords (`ls`, `cat`, `grep`,
+  `printf`, `done`, `const`, …). Never a workflow.
+- **`PLUMBING`** — universal git/gh navigation (`git status`, `git log`,
+  `git diff`, `gh auth`, …). Present in nearly every coding session, so it tells
+  you nothing about *what* to automate. Filtered from the command table.
+
+What survives is the distinctive stuff: named scripts, specific CLIs, tight API
+patterns. Note that `gh pr`, `gh api`, `npm run` survive the filter but are still
+near-substrate — high in *every* repo. Treat them as weak on their own; they
+matter only when a **title theme** explains *what* the PR/API work was for.
+
+### Title grouping
+
+Session titles are lowercased, stripped to their content words (stopwords
+removed), truncated to the first six, and grouped. Near-identical titles collapse
+("Synthesize activity logs into timeline cards" ≈ "Synthesizing user activity
+logs…"), and the group is ranked by sessions then days. This is usually the
+**most useful table** — the titles are already semantic, so a high-count group is
+a plain-language description of a thing the operator keeps doing.
+
+## From a digest row to a skill
+
+A row is a candidate only if it clears all four gates:
+
+1. **Recurring** — several sessions across several days. One busy day = not yet.
+2. **Fetch / compute / report-shaped** — it pulls or checks something and reports
+   a result. Read-heavy monitoring, digests, and status checks automate cleanly.
+   Interactive debugging, decision-heavy review, and one-off migrations do not —
+   they need a human in the loop that a cron run doesn't have.
+3. **Unattended-safe** — no reliance on local files, a logged-in desktop app, or
+   the operator answering a question mid-task. If the observed work used a local
+   MCP server or read `~`, that part has to be re-wired as a repo secret /
+   `.mcp.json` or dropped (Mode 4 steps 2–3).
+4. **Not already covered.** Dedup against `./aeon skills ls` *before* proposing.
+   Common overlaps to watch for:
+
+   | Digest signal | Already a skill → do this instead |
+   |---|---|
+   | Heavy `gh pr` / PR review | `pr-review`, `pr-check` → Mode 2 reschedule |
+   | Recurring topic research / "digest X" | `digest`, `article`, `mention-radar` → Mode 5 `--var` |
+   | Repo / commit monitoring | `github-monitor`, `changelog` |
+   | Shipping recap | `shiplog`, `heartbeat` |
+
+   If an existing skill fits, the win is a **reschedule (Mode 2)** or a **`var`
+   change (Mode 5)**, not a new skill. Only genuinely uncovered recurring work
+   earns a new `SKILL.md`.
+
+## Inferring the schedule
+
+Read cadence from the `days` column of the winning row against the window:
+
+- days ≈ window length (hit almost every active day) → **daily** (`0 13 * * *`).
+- days ≈ window / 7 (a weekly rhythm) → **weekly** (`0 13 * * 1`).
+- bursty / irregular → propose `workflow_dispatch` (on-demand) first; let the
+  operator promote it to cron once it proves useful.
+
+Always convert to UTC and confirm the next 3 fire times in their timezone
+(Mode 2 rules), and remember the quoted-`schedule:` gotcha when the entry lands
+(Mode 4 step 4).
+
+## Privacy
+
+Transcripts are the operator's own and can contain anything they've ever pasted
+into Claude Code. The miner only emits **aggregates** — command patterns, grouped
+titles, counts. Keep it that way: never surface a raw prompt body, and never write
+transcript contents into a committed file or a notification. The counts and titles
+carry all the signal needed to decide what to automate.
+
+## Running it
+
+From the instance repo root, on the operator's own machine:
+
+```bash
+# default: last 120 days, markdown digest
+node ${CLAUDE_PLUGIN_ROOT}/skills/aeon/scripts/mine-history.mjs
+
+# a tighter recent window, more rows
+node ${CLAUDE_PLUGIN_ROOT}/skills/aeon/scripts/mine-history.mjs --days 45 --top 20
+
+# scope to one repo/topic (matches the session's cwd)
+node ${CLAUDE_PLUGIN_ROOT}/skills/aeon/scripts/mine-history.mjs --project my-repo
+
+# machine-readable, to post-process
+node ${CLAUDE_PLUGIN_ROOT}/skills/aeon/scripts/mine-history.mjs --json | jq '.titles'
+```
+
+Needs only Node (>=16) and a local `~/.claude/projects` — it exits with a clear
+message anywhere that directory is absent (e.g. a CI checkout), and never writes
+anything. If a busy background app dominates the tables (a tool that itself drives
+Claude Code will pile up near-identical sessions), scope past it with `--project`.
+
+### Flags
+
+| flag | default | effect |
+|---|---|---|
+| `--days N` | 120 | only sessions whose transcript was modified in the last N days |
+| `--top N` | 20 | rows per table |
+| `--project SUBSTR` | — | only sessions whose cwd contains SUBSTR |
+| `--min-sessions N` | 2 | drop candidates seen in fewer than N distinct sessions |
+| `--json` | off | raw JSON instead of the markdown digest |
+
+### Sample output (synthetic)
+
+```
+# Automation candidates — mined from Claude Code history
+
+Scanned 240 sessions (240 files, last 45 days) across 38 active days.
+
+## Recurring command workflows
+| # | pattern      | runs | sessions | days | projects |
+| 1 | `gh pr`      | 610  | 92       | 34   | 40       |
+| 2 | `gh api`     | 240  | 55       | 30   | 28       |
+| 3 | `npm run`    | 180  | 41       | 22   | 12       |
+
+## Recurring task themes
+| # | recurring session title  | sessions | days |
+| 1 | Review open pull requests| 14       | 12   |
+| 2 | Weekly analytics digest  | 6        | 6    |
+| 3 | Audit repos for cleanup  | 4        | 4    |
+```
+
+Read that as: PR review is a near-daily habit (route to `pr-review`, don't
+re-invent it); a weekly analytics digest recurs on a clean 7-day cadence and has
+no covering skill (a real new-skill candidate → daily/weekly `mode: read-only`);
+the repo audit is real but low-cadence (offer `workflow_dispatch` first).