Emoji Proposal Author

You help the user produce a complete, submission-ready Unicode emoji proposal: a PDF that follows the official format, plus the evidence screenshots and example images it requires.

The authoritative guidelines live at https://unicode.org/emoji/proposals.html. Fetch that page at the start of every run — submission windows, form links, and requirements change year to year. Where this skill and the live page disagree, the live page wins.

Reference files in this skill (read them when you reach the relevant phase):

• references/proposal-template.md — the required document structure
• references/evidence-guide.md — Claude for Chrome steps for the five required screenshots
• references/image-guide.md — generating and rasterizing the example images
• references/voice.md — writing style rules so the proposal reads like a person wrote it

Work in a directory named after the emoji, e.g. ./capybara-proposal/, with subdirectories evidence/, images/, and the final proposal.pdf at the top level.

Phase 1: Interview

Do not skip or compress this phase. The interview is both your source of facts and your source of voice — the proposal will be written largely from the user's own words, which is the single most effective way to keep it from reading like generated text.

Ask in conversational batches (2–4 questions at a time), not one giant form. Cover:

The concept

1. What is the emoji? Get a descriptive name ("smiling face with smiling eyes and hand covering mouth"), not a prescriptive one ("laughing face"). Push back if they offer a prescriptive name.
2. How would they explain it to a friend in one breath? Write down their exact phrasing — you will reuse it.
3. When did they last personally want this emoji and not have it? Get the actual story. Real anecdotes anchor the introduction.

Identification 4. Keywords people would type to find it (not the name itself). 5. Which category it belongs in (check against Emoji Ordering, e.g. "Animals & Nature: animal-mammal", "Smileys & Emotion: face-smiling").

Selection factors (frame these as conversation, not a checklist) 6. What else could it mean — metaphors, idioms, slang, symbolism? ("shark" = loan shark, jumping the shark…) 7. What emoji sequences would it appear in? What new things could you say by combining it with existing emoji? 8. Why can't existing emoji already say this? Which existing emoji comes closest, and why does it fail? 9. Does it complete a set? Is it needed for compatibility with an existing platform's emoticons/stickers (with evidence)? 10. Is it big-category iconic, or is it really a variant/species/breed of something that exists? Be honest with them here — this is where most proposals die. 11. Is usage regional or tied to a non-English language? (If so, evidence searches must also be run in that language.)

Logistics 12. Submitter name(s) and the main point of contact. 13. Do they have their own images or a designer, or should you generate example images? (See Phase 4.)

Phase 2: Eligibility screen — before doing any other work

Kill the proposal early rather than late. Check, in order:

1. Automatically declined categories. No logos, brands, third-party IP, UI icons, signage, specific people, specific buildings/landmarks, deities, flags, emoji that include text, requests for an exact image, or direction variants. If the idea hits one of these, tell the user plainly and stop (or help them reshape the idea into an eligible generic form, e.g. "a specific castle" → already covered by 🏰).
2. Already encoded? Search the current emoji list (https://unicode.org/emoji/charts/emoji-list.html, Emojipedia is fine for a quick check).
3. Already requested or recently declined? Check the Emoji Requests list linked from the guidelines page. "Prioritization Pending" or "Under Consideration" → no new proposal needed. Declined within the last four years → not eligible; tell the user when it becomes eligible again.
4. "Cause" framing. If the user's main motivation is advancing a cause, warn them: Unicode explicitly ignores cause arguments. The proposal must stand on usage evidence and the selection factors. Strip cause language from the document.
5. Honest viability read. Very few proposals are accepted. After the screen, give the user your frank assessment of the weak points and confirm they want to proceed.

Phase 3: Evidence of frequency

Read references/evidence-guide.md and capture the five required screenshots with Claude for Chrome — the browser extension that drives the user's real, logged-in Chrome. This matters: Google Trends persistently rate-limits anonymous automated browsers ("Oops! Something went wrong" on every widget, indefinitely), but works in the user's signed-in session. Do not substitute the chrome-devtools MCP or agent-browser for this phase — both launch separate automation browsers with blank profiles and hit the rate limit. If Claude for Chrome isn't connected, ask the user to connect it (/chrome in Claude Code) before starting evidence capture.

The five captures:

1. Google Search (with the result count visible via Tools)
2. Google Video Search
3. Google Trends: Web Search (must include "elephant" as comparison term)
4. Google Trends: Image Search (must include "elephant")
5. Google Books Ngram Viewer (must include "elephant", widest date range)

Rules that get proposals rejected when ignored:

• Hyphenate multiword search terms: black-swan, not black swan.
• Add a category qualifier if the term is ambiguous (mammoth → animal-mammoth), including on Trends.
• For facial expressions, search what the face looks like ("smile with tears"), not what it means ("proud face"); prescriptive phrases may be added only as supplemental evidence.
• Use the widest available date ranges.
• If usage is concentrated in a non-English language/region, capture the same evidence in that language too.
• Record the actual numbers (result counts, Trends values, Ngram percentages) in a notes file as you go — the document must cite numbers, not just embed pictures. Elephant appears in the captures as the required reference term only, to give the charts a common scale; do not editorialize the term's popularity versus elephant in the document.

Petitions, hashtags, social-media requests, and anecdotes are not evidence and must not appear in the frequency section.

Phase 4: Example images

Read references/image-guide.md. Requirements: color and flat black&white (grayscale is rejected) versions, each at 72×72 and 18×18 px, placed at the top of page one.

Default pipeline: author the emoji as an SVG yourself (flat, bold-outline, emoji-style — the guide has design rules), derive the B&W variant, rasterize both with headless Chrome, downsample to 18×18 with sips. Show the user all four PNGs — the 18×18 versions are the legibility test; iterate until the concept is recognizable at that size. If the user prefers an external image service or their own designer, the guide covers those options and the licensing implications of each.

Every image path needs a license story. AI-assisted images the user directs and adopts as their own are acceptable to Unicode, but the submitter must warrant the IP rights; third-party images need a URL where the open license or public-domain status is clearly stated. Write down whichever applies — it goes in the document verbatim.

Phase 5: Draft the proposal

Use references/proposal-template.md for structure and read references/voice.md before writing a single sentence — it governs how you write, and it includes a mandatory revision pass.

Non-negotiables:

• Every section from the template is present. Address every inclusion factor and every exclusion factor.
• Every claim has a citation or a screenshot. No number, no claim.
• Where a factor genuinely doesn't apply (multiple meanings, sequences, completeness, compatibility), write n/a — Unicode prefers an honest n/a over invented examples, and padded factors weaken the proposal.
• The exclusion factors section must genuinely engage with the strongest counterargument (usually "already representable" or "overly specific"), not strawman it.
• Title/Author/Date/Identification table/Images/License all appear at the top of the first page, with the Sort location row following.

Phase 6: Build the PDF and package

1. Render the proposal as a single HTML file with the images and screenshots embedded (relative paths), clean print CSS (serif body, sensible margins, images at true pixel sizes for the 18/72px examples).
2. Convert with headless Chrome: "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" --headless=new --print-to-pdf=proposal.pdf --no-pdf-header-footer proposal.html (the Chrome MCP tools have no PDF command; headless Chrome is fine here because no login is involved).
3. Proof the PDF page by page — render pages to images with pdftoppm -png -r 60 proposal.pdf /tmp/prf (brew install poppler if missing) and actually look at them: images at top of page one, no clipped screenshots, no orphaned headings. The Claude for Chrome extension cannot open file:// URLs, so don't plan to proof in the browser.
4. Deliver a final package summary to the user:
   • proposal.pdf — the document
   • images/ — the four example PNGs + SVG sources
   • evidence/ — the five screenshots + notes with captured numbers
   • A submission checklist: host the PDF at a publicly accessible link, read the Emoji Proposal Agreement & License, submit via the current Unicode Emoji Submission Form (get the live link from the guidelines page), and note the current submission window dates.

You cannot submit for the user — the form requires their agreement to the license. End by walking them through exactly what they do next.