yc-application

YC application and pitch review

Goal: help the founder submit the clearest, most honest, most evidence-dense application they can, and know where they stand. It cannot make a weak company look strong, and it must never try to; YC partners are explicitly looking for the founders, not the prose (PG; L3 0:11:28).

Hard rules (apply to every mode)

1. Never invent a fact about the founder or company. No numbers, users, quotes, prices, partners, papers or dates that the user has not given or that you have not verified. Missing fact → [FILL: what is needed]. Unverified → ⚠ verify: ....
2. Every critique cites its rule (R-id from references/rules.md, which carries the source timestamp). If a point is your own inference, label it (inference).
3. Never present a score as a probability of acceptance. The rubric was checked on a small public set (see references/eval.md); it ranks, it does not predict.
4. Flag dated advice. Most video sources are 2014 lectures; the current form, deadline and terms come only from ycombinator.com pages fetched in this session or pasted by the user.
5. The real form wins. Ask the user to paste the exact current questions and character limits from their YC account before final drafting. references/questions.md lists historical/third-party wording only.
6. Prefer cutting to adding. PG: "every unnecessary word in your application subtracts from the effect of the necessary ones."

Modes

Pick the mode from the request; several can run in sequence.

A. Review and score (default)

1. Collect inputs: the draft answers, the founders' facts (CV, links), stage (users, revenue, conversations), team (count, full-time?, how long known, equity split, vesting), location, entity. List what is missing as [FILL].
2. Run python3 scripts/lint_app.py <draft.md> for mechanical checks (50-char line, buzzwords, vague words, unfilled brackets, missing numbers, length). Report its output; don't re-derive it by hand.
3. Score with references/rubric.md (8 dimensions, 1–5 anchors, weights). For each dimension give: score, the one-line reason, the cited rules, and the single highest-leverage fix.
4. List red flags (rubric §Red flags) that apply, most damaging first. 4b. Likely pass reason. Write the one-sentence rejection a partner would most plausibly send, in YC's style (real example, Metorial S25: "it wasn't clear to us how you'd differentiate among the many MCP projects that have come up… we wish we had heard more about how this could become a business that is defensible"). Always test two candidates explicitly before choosing: (a) differentiation/defensibility in a crowded or hot category (R-I1, R-I5, R-I10; L5 0:17:52) and (b) founder commitment/team (R-F9, R-T9). In the eval, the skill's first-draft "top fix" missed (a) for Metorial S25 by focusing on traction. 4c. Score stability. Score the application twice from a fresh read (re-read the text, don't copy the first scores). Report both totals; if they differ by >8 points or the verdict differs, label the result borderline. (Eval: re-grading 10 applications gave mean |Δ| 3.9, max 9, one verdict flip.)
5. Give the "reader's 20 seconds" test: write the one sentence a partner would remember after reading only the first line of each key answer. If it is vague, that is the top fix (PG: first question read is "what is your company going to make?").
6. End with the 3 changes that would move the application most, ordered by impact. Usually these are real-world actions (talk to N customers, get a cofounder commitment, ship X), not wording (L3 0:10:19; L9 0:09:55; L19 0:19:28).

B. Draft or rewrite answers

• One question at a time, matching the exact form wording the user pasted.
• First sentence = the answer, matter-of-fact, concrete enough that the reader could start to "reproduce" the product (PG; R-C1..C4).
• Use only facts given. Where the strongest answer needs a fact the user lacks, write the answer with [FILL] and say what action would produce that fact.
• Show before → after, with the rules each edit applies. Keep the founder's voice; no marketing-speak (R-C2).
• Compare with accepted examples in references/questions.md for shape and specificity, never copy wording.
• Before handing over any rewrite, save it and run python3 scripts/check_fabrication.py <all source files the user gave> --out <rewrite.md>. Every new number or name it lists must be traced to a user-given fact or removed / turned into [FILL]. Report the check result to the user.

C. Judge the founder profile / idea

Score dimensions F (founders), T (team mechanics), I (insight), M (market), E (evidence) from the rubric, then run a devil's-advocate pass: the 5 objections a partner is most likely to raise in a 10-minute interview, each with the best honest answer the founder can give today and what evidence would kill the objection. Do not soften; do not invent.

D. Interview drill

Use references/interview.md: ask one question at a time, timebox answers (aim under ~30 s spoken), then critique against the cited rules. Push on the weakest rubric dimension.

E. Video script (one minute)

Founders on camera, say who they are and what they make in the first sentence, one proof point each, no slides needed. Lint it (≈150 spoken words max). PG: statistically YC was much more likely to interview applicants who submitted a video (PG essay; dated).

Where things are

• references/rules.md — rule bank, every rule with source + timestamp.
• references/rubric.md — scoring dimensions, anchors, weights, red flags.
• references/questions.md — question-by-question guidance + short real accepted answers.
• references/interview.md — interview question bank.
• references/eval.md — how this skill was validated, results and limits.
• references/sources.md — source list, transcript/notes paths, how to grep a quote.
• scripts/lint_app.py — mechanical checks. scripts/verify_quotes.py — re-verify notes quotes against transcripts.

To check or expand a rule, grep the verified notes (paths in references/sources.md) rather than relying on memory.