idea-pipeline

Files (1)

• SKILL.md

SKILL.md (first lines)

> **${var}** — Optional theme filter (e.g. "crypto", "AI agents", "consumer"). If empty, scans all ideas. A `pick:<id|name>` value (from the "build next?" force-reply — e.g. `pick:2` or `pick:Onchain reputation`) instead marks that idea as chosen-to-build in the backlog and ends, skipping the audit — see step 0. `offer:<owner/repo or issue-url>` directly offers a confirmed owned target through the same Telegram reply boundary, also ending before the audit.

Today is ${today}. Read `memory/MEMORY.md` before starting. If `soul/SOUL.md` + `soul/STYLE.md` exist and are populated, read them to ground "operator fit" scoring; otherwise score on the idea's general buildability and timing alone.

## Why this skill exists

`idea-forge validate` evaluates ideas. Nothing tracks execution. Backlogs of dozens of ideas accumulate — some validated, most unscreened — with zero visibility into which ones have been acted on vs which are rotting. This skill gives that view: pipeline size, execution rate, and the 3 ideas closest to being buildable right now.

## Steps

### 0. Force-reply interception — `pick:<idea>` / `offer:<target>` (run FIRST, before anything else)

If `${var}` starts with `offer:`, strip and trim the remainder. Accept only `owner/repo` or `https://github.com/owner/repo/issues/N`, normalize it to `owner/repo`, and require `gh api "repos/$repo" --jq '.permissions.push // false'` to return `true`. Invalid, inaccessible, or API-failed targets get a plain rejection notification and end without a force reply. For a confirmed target, execute this exact command with Bash. Describing or printing the command is not delivery:

```bash
./notify "Which owned repository or issue should Aeon Engineer use? Reply with ${target}." \
  --force-reply --placeholder "${target}" \
  --context "dev-loop::ship"
```

After the command exits zero, require at least one non-empty JSON payload under `${AEON_PENDING_DIR}/notify-queue/` **and** that payload's `.reply_markup.force_reply == true`. A queued payload alone isn't enough — `notify.sh` queues one even when the inbound Messages workflow is disabled, but in that case sends the prompt as plain text (`reply_markup:null`) with no reply routing, so the operator's answer would never come back to this skill. If the command fails, the payload is absent, or `force_reply` isn't `true`, end with `FORCE_REPLY_MISSING: dev-loop::ship target=<target>` and do not claim the prompt was offered. Only after both checks pass, log `FORCE_REPLY_OFFERED: dev-loop::ship target=<target>` under `### idea-pipeline`, then end. This is an explicit operator-invoked producer path and still does not dispatch the chain until the operator replies.

Otherwise, if `${var}` starts with `pick:`, this run is the operator answering the "which idea to build next?" force-reply — do **not** run the normal audit. Handle it and end:

1. Strip the prefix: `sel="${var#pick:}"`, then trim surrounding whitespace. The remainder may contain colons/spaces — keep them.
2. If `sel` is empty, send a plain re-ask (no force-reply) and end: `./notify "Which idea should I mark as next to build? Reply with its name or backlog number."`
3. Read the shared backlog `memory/topics/startup-ideas.md`. If it's missing or has no idea rows, `./notify "No idea backlog yet — nothing to mark. Run idea-forge generate to fill it first."` and end.
4. Resolve `sel` to exactly one idea row in the table (columns `| date | name | one-liner | fit | T+F+E |`):
   - **By name (preferred):** case-insensitive exact match on the `name` cell; else fuzzy — the row whose name shares the most significant words with `sel`, or where `sel` is a substring of the name (or vice-versa). Require one clear best match.
   - **By number:** if `sel` is a bare integer N and no name matches, take the Nth data row (1-based, in file order).
   - If nothing matches, or two rows tie with no clear winner, send a plain re-ask listing 3–5 candidate names and end: `./notify "Couldn't find an idea matching \"<sel>\". Reply with the exact name or backlog number. Candidates: <name1>, <name2>, <name3>."`
5. **Mark it chosen-to-build** — the shared marking convention (identical in idea-forge): append ` ✓ selected ${today}` to the end of that row's `name` cell, keeping the table pipes intact. If the cell already carries a `✓ selected` marker, leave it (idempotent) — it's already queued.
6. **Do not try to infer a GitHub target from the row.** The backlog's row schema (columns `| date | name | one-liner | fit | T+F+E |`) never carries a repo or issue reference, so a per-row target lookup here would never match a real row. `offer:` (step 0) is the only path from a marked idea to a dev-loop dispatch — explicit and push-permission-gated on purpose.
7. 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, or reply with: offer:<owner/repo> to have Aeon Engineer start on it directly."` Do not auto-dispatch any skill — marking chosen is the safe action.
8. Log to `memory/logs/${today}.md` under a `### idea-pipeline` heading: `- IDEA_PIPELINE_PICK: marked "<idea name>" as chosen-to-build (from a pick: reply)`.
9. **End the run.** Do not proceed to step 1 or run the audit.

### 1. Load the idea backlog

Read `memory/topics/startup-ideas.md`. If it doesn't exist, log `IDEA_PIPELINE_SKIP: no backlog at memory/topics/startup-ideas.md` and stop — there's nothing to audit.

Parse the ideas table: extract name, one-liner, category/vertical, and date added for each idea. Total = N_total.

### 2. Load screening results

Read `memory/topics/startup-ideas-screened.md` (create if missing — empty table header only).

Extract ideas that have been screened. N_screened = count of rows.

From screened ideas, note those with `viability >= 9` (high-potential). These are the priority pipeline.

### 3. Check execution — what's been built

**Scan skills directory:**
```bash
ls skills/
```
Collect the list of skill directory names. These are "executed ideas" in the agent space.

**Scan cross-repo PRs by the operator and their bot accounts.** Read `memory/topics/git-identities.md` if present (operator-defined list of GitHub usernames to scan). Fall back to the workflow's `GITHUB_ACTOR` if no list is configured.

```bash
gh pr list --author ${USERNAME} --state merged --limit 30 --json title,url,mergedAt
```

**Scan deployed prototypes:** read `memory/topics/prototypes.md` (or `memory/topics/vercel.md`) if either exists. Treat any project flagged as a prototype/MVP as a shipped idea.

**Scan recent builds:** read the last 14 days of `memory/logs/` and collect any `BUILD_SKILL_OK`, `CREATE_SKILL_OK`, or `DEPLOY_PROTOTYPE_OK` entries.

### 4. Cross-reference: idea vs execution

For each idea in the full backlog:
- Check if any skill name or PR title contains keywords from the idea name/one-liner (fuzzy keyword match — at least 2 significant words overlap, or the core concept is clearly represented)
- Classify as: `executed` (clear match found) or `unexecuted`

N_executed = count of ideas with a clear match.
N_gap = N_total − N_executed.

### 5. Load narrative context

Read `memory/topics/market-context.md` if present for current narrative keywords (tokens trending, tech themes, regulatory signals).

Read recent logs for any narrative signals (last 3 days).

Compile a list of 8–12 active narrative keywords (e.g. "agent payments", "RWA", "prediction markets", "privacy coins"). If no market-context source exists, derive keywords from recent `digest`, `narrative-tracker`, or `github-trending` outputs.

### 5b. Load builder-ecosystem signal

Read `memory/topics/ecosystem.md` if it exists (written by the retired `builder-map` skill, so usually absent; skip this step when it is). This is the second-stream feed — "who's adopting the watched stack" becomes idea fodder.

Extract two things:

- **Underserved categories** — Builder Categories with 0 or 1 known builders in the ecosystem map. Example: "social-sim" with no entries = an opening for a sim-prototype.
- **Adjacent verticals** — non-obvious verticals with active builders. Verticals that already crossed over tell you which directions the stack travels well.

Compile:
- `underserved_categories` — list of 2–5 categories with thin builder coverage
- `adjacent_verticals` — list of 2–4 non-obvious verticals with active builders

If `memory/topics/ecosystem.md` doesn't exist yet, skip this step and log `idea_pipeline: ecosystem_feed=unavailable` in step 10. Do not block the run.

### 6. Score unexecuted ideas for "build this week"

For each UNEXECUTED idea, compute a priority score:

```
priority = narrative_fit + operator_fit_estimated + recency_bonus + ecosystem_gap_bonus

narrative_fit:          0–4 (count of active narrative keywords that appear in idea name/one-liner/category; cap at 4)
operator_fit_estimated: 0–2 — read `soul/SOUL.md` if present; +2 if the idea matches the operator's stated themes, +1 if it's solo-buildable AND adjacent to current work, 0 otherwise. If no soul file, score 0 here and let other factors decide.
recency_bonus:          2 if added in last 14 days; 1 if last 30 days; 0 otherwise
ecosystem_gap_bonus:    3 if idea's category matches an `underserved_category` from step 5b; 2 if it matches an `adjacent_vertical`; 0 otherwise
```

Tie-break preference when scores match: ideas that fill an underserved-category gap > ideas that hit a hot narrative. The ecosystem signal is structural (where the stack is going); narratives rotate.

If `${var}` is set, additionally filter to ideas whose category/text matches `${var}`.

Sort descending. Pick top 3. For each pick, in step 7's `Why now:` line, name the ecosystem signal explicitly if `ecosystem_gap_bonus > 0` (e.g. "no builders on the stack in this category yet" or "adjacent-vertical adoption arc").

From aeonfun/aeon, MIT.

More from aeonfun/aeon