Claude Skills for a Y Combinator Application

Build a reusable Claude skill that checks application answers against your real company facts. Keep founder feedback, approved claims, and application decisions available for the next revision.

Updated 6 min read

Use Claude Skills for a Y Combinator application by saving a repeatable review procedure: compare each answer with approved company facts, flag unsupported claims, then suggest clearer wording. A skill is a reusable set of instructions Claude can load when relevant; it cannot supply missing evidence or predict an acceptance decision.

A shared record such as fenbs can hold the approved facts, founder feedback, and decisions that each revision should use. Keep the review procedure reusable while updating the company evidence separately, so an old prompt does not quietly become the source of a new claim.

How do you set up an application review skill?

  1. Copy the exact question and any answer constraint from your current YC application. Review one answer at a time before checking the application as a whole.
  2. Prepare a dated company fact sheet. Include what the product does, what founders have built, what users actually do, and which claims remain unverified.
  3. Write instructions that check evidence before editing style. Require Claude to distinguish supported statements, missing evidence, and conflicting facts.
  4. Package those instructions as a custom skill, enable it, and test it on deliberately flawed answers before using it on your own draft.
  5. Have a founder review every proposed change. Save approved wording and unresolved questions before moving to the next answer.

Anthropic describes skills as reusable instructions with optional supporting resources in its Agent Skills overview (opens in a new tab). For setup, follow the skill creation guide; the separate guide to skill files covers their structure.

Which company facts should Claude check?

Give each fact a source, an effective date, and a person responsible for checking it. Founder approval means someone checked the underlying evidence, not merely liked the wording. A past application is useful history, but its numbers and product description need checking again.

A compact evidence sheet for application review
Fact categoryWhat to provideWhat to flag
ProductWho uses it, what it does today, and what is still planned.A planned feature described as already available.
UsageThe metric definition, reporting period, and dated source.Signups described as active users or free trials described as paying customers.
RevenueThe accounting basis, period, and verified source.Bookings, recurring revenue, and cash collected treated as interchangeable.
FoundersSpecific work each founder personally did and evidence they can explain.A team achievement attributed entirely to one founder.
Customer learningWhat was observed and what is still a hypothesis.One interview presented as proof of broad demand.

Use short source labels such as PRODUCT-A or USAGE-B so every review points back to something a founder can inspect. If two sources disagree, resolve the discrepancy before drafting around it. Keep this evidence in fenbs context notes, with the agreed definitions recorded in Decisions and rules, so later sessions can read the same starting point.

What should the reusable skill say?

Start with one narrow skill for checking written answers. Anthropic’s custom skill instructions (opens in a new tab) explain the required name and description and recommend focused workflows with examples. The description below tells Claude both the task and when to use it.

Example SKILL.md for reviewing one answer
---
name: yc-answer-review
description: Review a founder's YC application answer against supplied company evidence. Use when checking or revising a YC written answer.
---

Inputs: exact question, current answer constraint, draft, dated
approved facts with source labels, and unresolved founder questions.

1. If an input is missing, ask for it before rewriting.
2. Extract factual claims from the draft. Mark each as supported,
   unsupported, or conflicting, with its supplied source label.
3. Never invent metrics, customers, achievements, or market evidence.
   Keep current results separate from plans and hypotheses.
4. Flag vague claims, unanswered parts, and inconsistent definitions.
5. Suggest a concise revision using supported facts only. Preserve
   the founder's meaning and any qualification needed for accuracy.
6. Check the supplied answer constraint. Report any remaining issue.
7. Return: claim check, proposed answer, and questions for the founder.
   If a missing fact blocks an answer, ask instead of filling the gap.

Do not score acceptance odds, approve claims, or submit anything.

Keep changing company numbers outside the skill. Supply the current fact sheet with each review, and explicitly ask Claude to use this skill. The instructions guide a check; they do not prove that Claude checked correctly. Read the source labels and the rewritten answer yourself.

How do you improve an answer without inflating it?

YC’s application advice (opens in a new tab) emphasizes clear, concise, matter-of-fact descriptions and specific founder achievements. Use those principles to remove vague language. Do not treat them as permission to add a more impressive business than the evidence describes.

For a hypothetical startup, suppose the approved facts say its software turns contractor voice notes into draft estimates and three contractors are testing it without paying. A draft saying “Our platform dominates contractor quoting with three customers” contains both vague positioning and an unsupported customer claim.

A grounded revision could say: “We turn contractors’ voice notes into draft estimates. Three contractors are testing the product for free.” That is a wording example, not an answer to copy into an unknown question. The founder still needs to confirm the facts and explain any limitation the actual question asks about.

Ask for the factual differences between the original and revision. If the only reason for a stronger claim is that it sounds persuasive, reject it. Save that feedback with the prompt in fenbs Skills and prompts, so the next review has a concrete example of an unacceptable edit.

How can you tell whether the skill works?

Test for useful refusals as well as good edits. A review that produces polished prose from incomplete evidence has failed the main job. Use fictional inputs first, then compare the results with what you expected.

  • Missing evidence: omit the source for a growth claim. Expect a request for evidence, not an invented growth rate.
  • Conflicting periods: provide a monthly number and an older quarterly number. Expect a conflict or clarification question.
  • Inflation: describe unpaid testers as paying customers. Expect the distinction to survive the rewrite.
  • Accurate answer: provide a clear draft with complete evidence. Expect minimal edits rather than unnecessary embellishment.
  • Answer constraint: supply the actual limit from the form. Check the result yourself after pasting it into the form.

If a test fails, tighten that instruction and rerun the same case. Save the failure and expected behavior alongside the prompt. A successful test supports using the procedure; it does not guarantee that every later answer will be correct.

How do you keep founder feedback consistent?

Separate feedback about wording from changes to facts. “Explain the buyer sooner” is editing feedback. “Use the new reporting period” requires an updated source and a check across affected answers. Neither becomes an approved claim because an assistant repeats it.

Record who approved a change and what remains unresolved. If cofounders need the same procedure, use the guide to sharing skills in Claude for that setup. Keep the application’s changing evidence and decisions in the shared work record.

How fenbs helps

Keep the review prompt and its evidence together

Save your application review instructions in fenbs Skills and prompts, with approved company facts in context notes and founder choices in Decisions and rules. Before another revision, ask your connected assistant to read that record and the saved progress. It can continue from the last review instead of treating an older chat as the final answer.

Create a free account

Free for one person · No credit card · Works with Claude, ChatGPT, Cursor and more

How to do this with fenbs

  1. Create a free account, then add a project for the application. fenbs is free for one person, no credit card; use a team kanban board with appropriate member roles when cofounders need access.
  2. Add dated company facts as AI context notes. Record the founder’s chosen metric definitions and application rules in Decisions and rules, keeping open questions separate.
  3. Save the reusable review instructions in Skills and prompts. Install the custom skill in Claude separately; saving prompt text in fenbs does not install it there.
  4. Connect Claude and ask it to read the project context before reviewing an answer. Give it the current question, constraint, draft, and relevant approved evidence.
  5. Create tasks for evidence gaps, record founder feedback on the relevant task, and save progress before stopping. Include which answer needs review next and what is waiting on a founder.

For one answer in one sitting, a document and a checklist may be enough. fenbs fits repeated reviews and handoffs; it does not independently verify company facts or submit your YC application. Founders remain responsible for the evidence, wording, and submission.

What should you check before submitting?

Read the answers together for inconsistent descriptions, periods, and definitions. Verify every number against its dated source, remove review comments, and confirm that each answer responds to the current question. Check YC’s application page (opens in a new tab) for current instructions and its FAQ (opens in a new tab) for application process questions.

Keep the useful review procedure after submission. The AI prompts hub covers reusable instructions, while Claude skills for project management covers ongoing work. Your next application review should start with refreshed evidence, not a more polished copy of stale facts.

Questions people ask.

Is this an official Y Combinator skill?

No. This is an example procedure founders can adapt for reviewing their own answers. It does not imply endorsement by Y Combinator or access to its evaluation process.

Can Claude estimate my chances of getting accepted?

Do not treat an AI acceptance score as evidence. Use the skill to identify unsupported claims, unclear explanations, and missing answers that a founder can actually check.

Do I need a separate skill for every application question?

Start with one fact-checking procedure and supply the exact question each time. Create a separate skill only when the review procedure changes enough to need different instructions or tests.

Does saving the prompt also save the latest company facts?

Only if you save those facts separately and keep them current. A reusable prompt describes how to review an answer; it should ask for dated evidence rather than carry old numbers into every revision.

More in Prompts and skills for AI work

All Prompts and skills for AI work articles

Start with one thing.

Free for one person · No credit card · Works with Claude, ChatGPT, Cursor and more

There is nothing to set up first. Write one line and you’ve started.