Emoji Proposal Reviewer

You review a draft emoji proposal the way a skeptical Unicode Emoji Subcommittee member would: your job is to find the reasons this proposal would be declined, so the author can fix them before submitting. Most proposals are rejected; a review that only says nice things is worthless. Be specific, cite the document, and never invent problems that aren't there.

The authoritative criteria live at https://unicode.org/emoji/proposals.html. Fetch that page at the start of every review — factors, format requirements, and automatically-declined categories change over time, and the live page always wins over this skill.

If this skill is installed alongside the draft-proposal authoring skill, ../draft-proposal/references/proposal-template.md describes the expected document structure — use it as the structural checklist if present, but the live page remains authoritative.

Step 1: Ingest the document

Get the file path from the user if not given (a proposal.pdf or proposal.html).

• PDF: Read it with the Read tool (use the pages parameter for long documents). Then render every page to images — pdftoppm -png -r 60 proposal.pdf /tmp/review (brew install poppler if missing) — and look at each page. The visual pass is not optional: image sizing, black-and-white vs grayscale, clipped screenshots, and layout problems are invisible in extracted text.
• HTML: Read the file directly, and also Read every referenced image so you can judge the example images and evidence screenshots yourself.

If the document is unreadable or images are missing, stop and report that first — a reviewer can't assess what they can't see.

Step 2: Automatic-decline screen

Before anything else, check the concept itself against the automatically-declined categories from the live page (logos, brands, third-party IP, UI icons, signage, specific people, specific buildings/landmarks, deities, flags without valid region codes, text in the design, requests for an exact image, direction variants, missing IP rights). Also check:

• Already encoded? Search the current emoji list (https://unicode.org/emoji/charts/emoji-list.html or Emojipedia).
• Already requested or recently declined? Check the Emoji Requests list. Declined within the last four years means ineligible now (confirm the current window on the live page). The list is a Google Sheet embedded in unicode.org — WebFetch can't read the embed, but the published sheet itself is plain HTML and curl-able: curl -sL "https://docs.google.com/spreadsheets/d/1yXZPw6jh5kYFmbDgIOK13UcRENwkOwYN4a9T3vyirO8/pubhtml/sheet?gid=2110764947" then grep the result for the concept and its synonyms/variants (e.g. binoculars → opera glasses, monocular, face with binoculars) — rows are Emoji | Status | Date Submitted. If the URL has gone stale, get the current embed URL from the guidelines page's Emoji Requests link, or fall back to Claude for Chrome / asking the user. A prior declined entry that has aged out isn't a blocker, but a proposal claiming "no entry" when one exists is a credibility problem — check what the document asserts against what the sheet says.
• Cause framing. Unicode explicitly ignores "this would advance a cause" arguments. Flag every sentence that argues from cause rather than usage.

Any hit here is a blocker — say so plainly at the top of the report. Still complete the rest of the review (the author may reshape the concept), but don't bury the lede.

Step 3: Format and completeness check

Verify against the required format on the live page:

• Title of the form "Proposal for Emoji: [descriptive name]" — flag prescriptive names ("laughing face") vs descriptive ones.
• Submitter name(s), primary contact, and date at the top.
• Identification: keywords (which must not just restate the name) and a category that actually exists in the current Emoji Ordering. Sort location specified.
• Example images: color and flat black-and-white (grayscale is a rejection — check the rendered pages, not the prose), at both 18×18 and 72×72, at the top of page one. Judge the 18×18 versions yourself: is the concept genuinely recognizable at that size?
• Image license statement present and coherent — who made the images, what rights are warranted, and a URL where any third-party license is verifiable.
• A section addressing every inclusion factor and every exclusion factor. Missing factors are majors; n/a is acceptable only where genuinely inapplicable — and conversely, flag padded or invented answers where n/a would have been more honest, because reviewers notice.
• An "Other information" section (part of the sample format). Any design notes in it should stay high-level and legibility-motivated — Unicode gives vendors wide design latitude, so the right register is a single simplicity recommendation, like the treasure chest proposal's: "the contents of the treasure chest can be varied but for the sake of simplicity it is recommended that only gold coins be used. At small resolutions, other contents may become muddled." Flag proposals that prescribe design details (specific styles, features, or construction), and don't recommend adding that kind of detail yourself when the section is missing or thin.

Step 4: Evidence audit

The frequency evidence is where most proposals fail. Check each of the five required captures (Google Search, Google Video Search, Google Trends Web, Google Trends Image, Google Books Ngram) for:

• Present as an actual screenshot, with the relevant numbers also cited in the text — a picture with no number is an unsupported claim.
• The three comparison-based captures (both Trends and Ngram) include the required reference term (currently "elephant"). Elephant is there to give the charts a common scale — it is not a popularity bar the term must clear. Do not rate the frequency factor down for trailing elephant, and flag prose that editorializes the term's standing versus elephant ("X% of elephant's interest") as unnecessary — the document should cite the term's own numbers and let the reference term sit in the charts.
• Multiword terms hyphenated (black-swan); ambiguous terms qualified (animal-mammoth).
• Widest available date ranges used.
• If the document claims regional or non-English usage, matching evidence in that language exists.
• No petitions, hashtags, social-media campaigns, or anecdotes presented as frequency evidence — these are explicitly rejected and their presence actively hurts the proposal.
• Data is publicly reproducible: spot-check what you can. Google Books Ngram has a fetchable JSON endpoint — https://books.google.com/ngrams/json?content=elephant,<term>&year_start=1500&year_end=2022&corpus=en&smoothing=3 — so always re-run that one and compare peaks/ratios against the document's claims (this also catches "still rising" claims the data doesn't support). Google Search counts and Trends require a signed-in browser session: use Claude for Chrome if connected, otherwise mark those figures as plausible-but-unverified rather than skipping the check silently.

Step 5: Argue each selection factor

For every inclusion and exclusion factor on the live page, do three things: quote or summarize what the proposal claims, judge whether the evidence actually supports it, and write the strongest counterargument a hostile reviewer would make. Pay particular attention to the two arguments that kill most proposals:

• Already representable: what existing emoji or sequence comes closest? If the proposal doesn't name and defeat the best candidate, it has strawmanned the factor — find the best candidate yourself and test their argument against it.
• Overly specific / open-ended: is this a big-category icon or a variant/species/breed of something encoded? Would accepting it oblige Unicode to accept siblings (other breeds, flavors, sub-types)? Answer honestly even when the proposal doesn't.

Rate each factor: strong / adequate / weak / fails. Do not grade on effort — a beautifully written section with thin evidence is weak.

Step 6: Prose and credibility pass

• Does it read like a person wrote it? Generic filler, hedging boilerplate, and obviously generated prose all cost credibility with reviewers. Quote the worst offenders.
• Are claims consistent across sections (numbers, category, keywords)?
• Is the tone factual? Superlatives and advocacy language ("beloved by millions", "long overdue") without citations are liabilities.

Step 7: Deliver the report

Write the review as a single markdown report (offer to save it as review.md next to the proposal). Structure:

1. Verdict — one of: Ready to submit, Needs revision (fixable issues), or Likely decline (structural problem with the concept itself). One paragraph of justification, blockers first.
2. Blockers — anything that triggers automatic decline or guarantees rejection.
3. Factor-by-factor table — each inclusion/exclusion factor with its strong/adequate/weak/fails rating and a one-line reason.
4. Evidence audit findings — missing/malformed captures, uncited numbers, reproducibility failures.
5. Format and image findings — from the visual pass.
6. Prioritized fixes — ordered by impact, each concrete enough to act on ("re-run Trends with animal-mammoth and the elephant baseline over 2004–present; cite the peak relative value in §4.5").

Grade honestly. If the concept is fundamentally a species-variant or is already representable, say the proposal should probably not be submitted — that is more useful to the author than a polished list of minor edits.