| name | idea-forge |
| description | 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. |
| metadata | {"title":"Idea Forge","category":"basics","var":"","tags":["research","ideas","creative","meta"]} |
${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:
- Strip the prefix:
sel="${var#pick:}", then trim whitespace (the remainder may contain colons/spaces — keep them).
- If
sel is empty → ./notify "Which idea should I mark as next to build? Reply with its name or backlog number." and end.
- 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.
- 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.
- 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).
- 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.
- 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).
- End the run — do not run mode dispatch.
Mode dispatch
Parse ${var} once, up front:
- Tokenize on whitespace/colons. If the token
dry-run appears anywhere, set DRY_RUN=1 and strip it.
- If the first remaining token is
generate, validate, or memo, that is the mode; the rest is the theme/constraint.
- If
${var} is empty, mode = generate, no theme.
- 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):
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.
- 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.
STRATEGY.md theses — the north-star + priorities name the wedge the operator occupies and the bets they're already making. Lean on those as the "theses to ride"; don't import a fixed thesis list.
Also, for current state, read the latest product-pulse + bd-radar digests if present.
Steps
0. Bootstrap
mkdir -p memory/topics output/articles
[ -f memory/topics/idea-forge-state.json ] || echo '{"ideas":[]}' > memory/topics/idea-forge-state.json
Load prior idea titles/one-liners into a dedup set (don't re-pitch the same wedge unless materially evolved). Also scan the last 21 days of memory/logs/ for ### idea-forge blocks.
1. Read the zeitgeist (this week)
Derive 4-6 search axes from the capability surface + the STRATEGY.md wedge — the spaces the operator's products occupy, plus the fast-moving adjacent areas they could ride. Run WebSearch (use current month + year) across each axis and pull a 1-line "what's moving" per theme. Don't work from a fixed theme list — let the surface and strategy choose the axes each week. Also fold in: notables from the latest product-pulse, leads from bd-radar (a cluster of similar leads = a demand signal), and anything in MEMORY's active topics. If a source fails, log IDEA_FORGE_SOURCE_MISS and continue. If a theme was passed in ${var}, bias the axes toward it.
2. Collide → generate
Produce 8-12 raw ideas by colliding a zeitgeist signal × a capability-surface primitive. Bias toward the operator's instincts as read from soul/ + STRATEGY.md: contrarian-but-defensible, distribution-aware, refuses its own category, fits a timing window now. No safe/generic SaaS takes. Don't self-censor for "too weird."
3. Score and cut to 3-5
Score each raw idea 1-5 on:
- Timing (T) — is the window open now? (zeitgeist pull, not evergreen)
- Fit (F) — buildable on the existing capability surface (the products + the skill/chain set) in weeks, not a new company
- Edge (E) — would this be hard for the operator's cohort (the teams in the same wedge) to copy? does it have an opinion?
Keep the top 3-5 by T+F+E. Kill anything that's just "X but with agents."
4. Sharpen each survivor
For each kept idea, write:
- One-liner (operator-voice, punchy, states the position first)
- Why now (the specific timing-window signal it rides)
- Smallest shippable cut (the v0 that could go out this week — ideally a skill, a chain, or a small feature/template on an existing product)
- Kill-criterion (the cheap test that would falsify it — a fast falsifier, not a roadmap)
- Fit tag — which product(s) from
memory/products.md it rides, or skill / chain if it's a harness capability
5. Write + state
6. Notify (gated)
Unless DRY_RUN: ./notify the single best idea — one-liner + why-now + the smallest shippable cut, in the operator's voice, with a link to the full digest. One paragraph. This is a deliberate weekly think, so it's worth one push even on a quiet week — but only the #1, never the whole list. Build the digest URL via gh repo view --json url -q .url (not the SSH remote), and send multi-line content with ./notify -f <file>.
6b. Offer a "build next?" follow-up (force-reply)
Unless DRY_RUN, and only when ≥1 idea was appended to the backlog this run: offer the operator a one-tap pick of which fresh idea to build — a separate ./notify after the step-6 push (a digest and a force-reply prompt can't share one Telegram message).
Dedup once per day: scan the last ~2 days of memory/logs/ for FORCE_REPLY_OFFERED: idea-forge::pick; if present, skip. Otherwise:
./notify "Which of this week's ideas should I mark as next to build? Reply with the idea's name." \
--force-reply --placeholder "idea name" \
--context "idea-forge::pick"
Then record FORCE_REPLY_OFFERED: idea-forge::pick in the generate log block (Log section). A pick: reply routes back to this skill and is handled by the "Force-reply interception" section above.
Mode: validate
Turns the backlog from an archive into an active pipeline. Idea backlogs accumulate weekly with no evaluation — without a screening pass there's no way to know which ideas are wide open vs already crowded, which match current market conditions, which are solo-buildable vs team-dependent. If soul/SOUL.md + soul/STYLE.md are populated, use them to ground "operator fit" scoring; otherwise score on solo-buildability and timing only.
Steps
1. Load the idea backlog
Read memory/topics/startup-ideas.md. If it doesn't exist, log IDEA_VALIDATOR_SKIP: no backlog at memory/topics/startup-ideas.md and stop.
Read memory/topics/startup-ideas-screened.md (create if missing — it's the screening database).
From the main ideas table, extract ideas that have NOT yet appeared in startup-ideas-screened.md. If a theme was passed in ${var}, additionally filter by theme/domain match.
Pick up to 8 ideas to screen this run — prioritize oldest unscreened (earliest date first).
If fewer than 2 unscreened ideas remain: send a "backlog current" notification (unless DRY_RUN) and stop.
2. Screen each idea
For each idea (name + one-liner from the table), run:
a) Competition scan
WebSearch: "[idea name] startup ${year}"
WebSearch: "[core problem/domain] tool app platform"
Classify competition density:
open — no direct competitors found, or market clearly nascent
sparse — 1–2 players, no clear winner
crowded — 3+ established players with traction
saturated — category has a dominant incumbent
b) Funding signal
WebSearch: "[domain] startup funding ${year}"
Note: any recent raises in the space? Is VC money flowing in (market heating) or absent (too early or too late)?
c) Timing fit
Score 1–5 based on:
- What's the tailwind right now? (regulatory shift, new infra, behavior change)
- Does recent context from
memory/logs/ match this domain? (market signals, papers, tweets)
- 5 = this could launch today and hit demand; 1 = needs 2+ years of market development
d) Operator fit
Score 1–5. If soul/SOUL.md exists and is populated:
- Does the operator have relevant domain expertise or network (per soul)?
- Is this solo-buildable or requires a team?
- Does it connect to current projects named in MEMORY.md or topic files?
- 5 = operator could validate this in a week with the current stack.
If no soul file exists, score this dimension as 3 by default (neutral) and rely on the other axes — operator fit is unknowable without the soul.
e) Market size
Quick estimate: small (<$1B TAM), medium ($1–10B), large (>$10B). Use WebSearch if unclear.
3. Score and rank
Compute a viability score for each idea:
viability = timing_fit + operator_fit + competition_bonus + size_bonus
competition_bonus: open=4, sparse=3, crowded=1, saturated=0
size_bonus: large=2, medium=1, small=0
Max ~16. Sort descending.
4. Update the screening database
Append to memory/topics/startup-ideas-screened.md (create if missing):
# Startup Ideas — Screening Notes
Each idea screened by idea-forge (validate mode). Sorted by date screened.
| Date Screened | Idea | Competition | Timing | Operator Fit | Market | Viability | Key Finding |
|---------------|------|-------------|--------|--------------|--------|-----------|-------------|
| YYYY-MM-DD | Idea Name | open/sparse/crowded/saturated | 1-5 | 1-5 | small/medium/large | score/16 | one-line finding |
5. Decide whether to notify
Always notify (unless DRY_RUN) — screened ideas are always worth surfacing.
6. Format and send notification
Write to a temp file, then send:
mkdir -p .pending-notify-temp
TEMP=".pending-notify-temp/idea-forge-validate-${today}.md"
./notify -f "$TEMP"
Notification format — match the operator's voice if soul files are populated, otherwise direct and neutral:
idea screener — ${today}