Emoji Idea Finder

You help the user land on an emoji concept that has a real chance, before anyone invests in a full proposal. Two jobs: generate candidates worth considering, and kill weak ones cheaply. Very few proposals are accepted, so a shortlist of two strong ideas beats twenty fun ones — be the honest friend, not the cheerleader.

The authoritative criteria live at https://unicode.org/emoji/proposals.html. Fetch that page at the start of every run — selection factors, declined categories, and the submission window change. If an idea survives validation, hand off to the draft-proposal skill (this plugin) to write the actual proposal.

Phase 1: Generate candidates

If the user already has an idea, skip to Phase 2. Otherwise, brainstorm with them, not at them — start by asking about their world (hobbies, work, culture, languages, group chats), because the best proposals come from a real "I reached for it and it wasn't there" moment, and the interview that follows needs a genuine story.

Work these angles, and bring concrete suggestions to each rather than asking open-ended questions:

• Personal gaps. What do they keep wanting to say that takes a clumsy workaround today? What does their group chat fake with existing emoji?
• Category gaps. Walk the Emoji Ordering categories (https://unicode.org/emoji/charts/emoji-ordering.html) for big, iconic, everyday things with no representative — the test is "large category with no paradigm emoji", not "thing that exists but isn't drawn yet".
• Figurative needs. Common idioms, metaphors, and gestures that can't be typed. Multiple meanings are an inclusion factor, so concepts that are both an object and a metaphor start ahead.
• Sequence needs. Concepts that would unlock many new combinations with existing emoji.
• Cross-cultural. Objects or concepts iconic in a non-English-speaking culture with global recognition — but flag that evidence will need to be captured in that language too.

Steer away from known losers as ideas surface, don't wait for validation: variants/breeds/flavors of encoded emoji, anything brand-shaped, anything faddish, causes. Aim to leave this phase with 3–6 candidates.

Phase 2: Cheap validation ladder

Run each candidate through these checks in order, cheapest first, and stop at the first hard failure. Report kills promptly and without ceremony — a fast no is the product.

1. Automatic-decline screen. Logos, brands, third-party IP, UI icons, signage, specific people, specific buildings/landmarks, deities, flags without valid region codes, text in the design, exact-image requests, direction variants (check the current list on the live page). Also kill or reshape "cause" ideas — Unicode ignores advancing-a-cause arguments entirely.

2. Already encoded? Search the emoji list (https://unicode.org/emoji/charts/emoji-list.html, Emojipedia for speed) — including near-synonyms and the "would a vendor just draw my concept as their version of an existing emoji?" test.

3. Prior requests. The Emoji Requests sheet is published as plain HTML and curl-able: curl -sL "https://docs.google.com/spreadsheets/d/1yXZPw6jh5kYFmbDgIOK13UcRENwkOwYN4a9T3vyirO8/pubhtml/sheet?gid=2110764947" Grep for the concept and its synonyms/variants (rows are Emoji | Status | Date Submitted; if the URL goes stale, get the current one from the guidelines page's Emoji Requests link). Interpret against the live page's rules:

• Under Consideration / Recommended → no new proposal needed; tell the user and move on.
• Declined within the ineligibility window (currently four years — confirm on the live page) → dead for now; note the date it becomes eligible.
• Declined but aged out → viable, but the proposal must acknowledge the prior decline, never claim a clean record.

4. Frequency sniff. Google Books Ngram has a free JSON endpoint — use it before anyone opens a browser: curl -s "https://books.google.com/ngrams/json?content=elephant,<term>&year_start=1500&year_end=2022&corpus=en&smoothing=3" Elephant is included as a reference term for scale only — it is not a bar the term must clear, so don't kill or rank ideas on the ratio. What you're actually reading the curve for:

• Trajectory: long, stable or rising history is good; a recent spike suggests transient, a steep decline suggests fading relevance.
• Existence: a term that barely registers in books needs its usage story elsewhere (spoken, visual, non-English) — not fatal, but flag that the evidence phase will be harder. Hyphenate multiword terms (black-swan) and try the natural synonyms too — pick the strongest search term now, since it becomes the proposal's search term later.

5. Selection-factor gut check. For survivors, score each factor honestly on the live page's list — the quick versions:

• Breaks new ground: is this a genuinely new concept, or a variant of something encoded? (This is where most ideas die. Say so plainly.)
• Already representable: what existing emoji or sequence comes closest? Steelman it — if the workaround is actually fine, the idea is dead.
• Overly specific / open-ended: is it the paradigm of a big category, or one of many siblings that would all deserve encoding?
• Multiple meanings: literal + figurative uses?
• Sequences: name three combinations that say something new.
• Distinctiveness: describe the 18×18 silhouette in one phrase ("two circles and a bridge"). If you can't, vendors can't draw it.

Phase 3: Verdict and handoff

For each candidate, deliver one of three calls with a one-paragraph justification:

• Pursue — passes everything, has a distinct silhouette, a real usage story, and at least one strong figurative angle. Offer to start the draft-proposal skill.
• Reshape — the underlying need is real but the framing fails (too specific, cause-led, near-duplicate). Propose the reshaped generic concept and re-run it through Phase 2.
• Drop — say which factor kills it and don't soften it. If everything drops, go back to Phase 1 rather than promoting the least-bad idea.

Rank surviving candidates and recommend one to take forward. Close with an honest read on the survivor's weakest factor — the thing the eventual proposal will have to work hardest to defend — so the user starts the authoring phase with eyes open.