idea-forge
Three-mode idea engine - generate collides the week's zeitgeist with what you can ship into scored wedges; validate viability-screens the idea backlog; memo writes evidence-backed startup memos.
git clone --depth 1 https://github.com/aeonfun/aeon /tmp/idea-forge && cp -r /tmp/idea-forge/skills/idea-forge ~/.claude/skills/idea-forgeSKILL.md
> **${var}** — Selector `mode [theme/constraint]`. First token picks the mode: `generate` (default) collides the zeitgeist with the capability surface into ranked wedges; `validate` screens the existing backlog for viability; `memo` writes 2 rigorous evidence-backed startup memos. Anything after the mode is a theme/constraint bias. A bare theme with no mode keyword (e.g. `payments`, `crypto`) = `generate` biased to that theme. `dry-run` anywhere skips the notify. Examples: `` (empty → generate, open-ended) · `simulation` (generate, themed) · `validate crypto` (screen crypto ideas) · `memo solo founder` (memos under a constraint) · `generate payments dry-run` (generate, no notify). A `pick:<id|name>` value (from the "build next?" force-reply — e.g. `pick:Onchain reputation`) is intercepted **before** mode dispatch: it marks that idea as chosen-to-build in the shared backlog and ends — see "Force-reply interception" below.
Today is ${today}. **Read `soul/SOUL.md` + `soul/STYLE.md` + `STRATEGY.md` first and read them closely** — this skill thinks *as the operator*, in their worldview, not about them. If `soul/` is the empty template, ground purely on `STRATEGY.md` + the capability surface and write in a clear, direct tone. Then read `memory/MEMORY.md` for current goals and active topics. Each mode below names its own `memory/logs/` scan window for dedup — honor it.
## Force-reply interception — `pick:<idea>` (run FIRST, before mode dispatch)
Before tokenizing `${var}` for the mode, check it. If `${var}` **starts with `pick:`**, this run is the operator answering the "which idea to build next?" force-reply — do **not** run generate/validate/memo. Handle it and end. This is behaviorally identical to idea-pipeline's step 0 (same backlog, same marking convention), so a `pick` reply works whichever skill it routes to:
1. Strip the prefix: `sel="${var#pick:}"`, then trim whitespace (the remainder may contain colons/spaces — keep them).
2. If `sel` is empty → `./notify "Which idea should I mark as next to build? Reply with its name or backlog number."` and end.
3. Read the shared backlog `memory/topics/startup-ideas.md`. If missing or no idea rows → `./notify "No idea backlog yet — nothing to mark. Run generate first to fill it."` and end.
4. Resolve `sel` to exactly one row in the table (`| date | name | one-liner | fit | T+F+E |`):
- **By name (preferred):** case-insensitive exact match on the `name` cell; else fuzzy — most significant-word overlap, or `sel` a substring of the name (or vice-versa). Require one clear best match.
- **By number:** a bare integer N with no name match → the Nth data row (1-based, in file order).
- No match / ambiguous tie → `./notify "Couldn't find an idea matching \"<sel>\". Reply with the exact name or backlog number. Candidates: <name1>, <name2>, <name3>."` and end.
5. **Mark it chosen-to-build** — the shared marking convention, identical to idea-pipeline: append ` ✓ selected ${today}` to the end of that row's `name` cell, keeping the table pipes intact. If already marked, leave it (idempotent).
6. Confirm with a short `./notify` (keep it clean — no `test`/`trace`/`ping`/`debug` substrings): `./notify "Marked \"<idea name>\" as next to build — flagged in the backlog. Run /feature or /deploy-prototype on it when you're ready."` Do not auto-dispatch any skill — marking chosen is the safe action.
7. Log under a `### idea-forge` heading in `memory/logs/${today}.md`: a `- Mode: pick` line, then `- IDEA_FORGE_PICK: marked "<idea name>" as chosen-to-build (from a pick: reply)`.
8. **End the run** — do not run mode dispatch.
## Mode dispatch
Parse `${var}` once, up front:
1. Tokenize on whitespace/colons. If the token `dry-run` appears anywhere, set `DRY_RUN=1` and strip it.
2. If the first remaining token is `generate`, `validate`, or `memo`, that is the **mode**; the rest is the **theme/constraint**.
3. If `${var}` is empty, mode = `generate`, no theme.
4. Otherwise (a bare theme like `crypto`/`payments`/`simulation`), mode = `generate` and the whole string is the theme.
Then run exactly one branch:
- **`generate`** → weekly zeitgeist × capability-surface wedge engine (writes `output/articles/` digest + state + appends the shared backlog).
- **`validate`** → viability screen + scoring of `memory/topics/startup-ideas.md`.
- **`memo`** → 2 evidence-backed startup memos (pain-cited, tarpit-filtered, full schema).
`DRY_RUN=1` skips the notify step in whichever branch runs.
---
## Mode: generate
### Why generate exists
The unit of competition is increasingly the **timing window**, not the product or the company — figure out the zeitgeist first, then ultra-accelerate. Ideas are the moat, but they decay: inspiration is perishable. `generate` is the weekly forced-function that does the collision deliberately instead of hoping it happens in the shower — take this week's zeitgeist, slam it against the operator's real capability surface, and hand back a few sharp, defensible, *shippable-now* wedges — not a brainstorm dump.
### The capability surface (what you can actually build on)
Ground every idea in real primitives this operator already has — don't invent infra. **Derive the surface fresh each run** from three sources (never a hardcoded product list):
1. **`memory/products.md` `surface:` lines** — one line per `## <Product>` block describing what it is and the primitives it exposes. These are the load-bearing capabilities; also pull `terms:` for the products' own framing. If `memory/products.md` is missing or still the unconfigured template, log `IDEA_FORGE_NO_PRODUCTS_CONFIG` and fall back to `memory/watched-repos.md` (the repos themselves) + `STRATEGY.md` (the wedge) — keep going.
2. **The installed skills directory** — `ls skills/` and skim a sample of `description:` lines. The skill/chain set is itself a capability surface: what this instance can already automate or ship as a skill or a chain this week.
3. **`STRATEGY.md` theses** — the north-star + prSet up and run an Aeon agent instance — get started from scratch, pick which skills to turn on or install more from packs, reschedule or change what runs, edit what an existing skill does, fix a skill that isn't firing, set the STRATEGY.md north star and soul/ voice, turn a coding-agent chat into a scheduled Aeon skill, and mine past coding-agent conversations for recurring work worth automating as a skill. Use when the user mentions Aeon, aeon.yml, an Aeon skill / instance / routine / pack, asks to schedule, enable, edit, or debug an agent that runs on a cron, or asks what of their repeated/manual work Aeon could take over.
Mention/keyword sweep on social platforms for [REPLACE: KEYWORDS] — trends, sentiment, top posts
5 concrete real-life actions, leverage-scored against open loops with specificity and anti-fluff gates
Static config-correctness linter for this instance - catches the silent-failure class (unquoted schedules, duplicate keys, unconfigured skills, mode typos, broken requires/MCP refs) that no run-based health skill can see. Notifies only on problems.
Pull framework updates from the upstream Aeon repo into this instance - 3-way merges canon's new commits into a PR, never clobbering operator config.
Write a publication-ready article in one of three angles - a trending long-form piece, a watched-repo thesis, or a project-through-a-lens essay. Optional Replicate hero image with --visual.
Automatically merge open PRs that have passing CI, no blocking reviews, and no conflicts
Two-mode aeon.yml workflow builder - analyze inspects URLs and emits a tiered, signal-verified skill-enablement plan plus an aeon.yml diff; enable flips slugs to enabled:true and opens a PR.