agentleFS
calebnewtonusccalebnewtonusc/apply-kit/.claude/skills/application-writing/SKILL.md

application-writing

Skill0 starsChanged 35 days agoMITView on GitHub

How to write application answers that survive a real reader, for any kind of application. Use whenever drafting, revising, or evaluating an answer for a club, job, fellowship, graduate program, grant, or accelerator.

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every applicant claims initiative, leadership, and curiosity.

    line 57
  2. Very specific:

    Never invent the number: If it is not known, write [NEED: how many] and ask.

    line 70
  3. Distinctive:

    Why us and not the six others like you?: If you are applying to several orgs in one lane, every one of them knows it.

    line 92
  4. Distinctive:

    Write five applications without watching for this and all five have the same shape: here is what I built, here is what I cannot do yet, …

    line 105
  5. Distinctive:

    Within one application: never tell the same story twice.

    line 152
  6. Very specific:

    If the form mandates headings, use theirs, in their order.

    line 161

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Writing applications

Who reads this

Load application-types first and read the file in reference/ for this application's type. Who the reader is changes what the answer has to do, and it is the one thing about application writing that is not universal.

The short version of each:

TypeThe readerHow long they spend
student-orgA peer who will be your teammate60 to 90 seconds
jobA filter, then a hiring managerUnder a minute, then longer
fellowshipA committee scoring published criteriaLong, several readers
grad-schoolFaculty reading for fit with a labLong
grantA program officer with a checklistLong, structured
acceleratorA partner looking for a reason to take a callFast

What holds across all six: they are not looking for the best applicant. They are looking for a reason to move you forward so they can stop deciding about you. Give them one early.

And by the time they reach you they have read the same answer many times: passionate about the intersection of business and technology, drawn to your commitment to excellence, eager to learn from a community of driven individuals. Every one of those was written by a real person with a real life. The writing just did not contain any of it.

Openings

The first sentence decides whether the rest gets read or skimmed. Three that work:

A concrete scene, mid-action. "Forty-eight hours before the event, all eleven volunteers backed out." No setup, no context. The reader supplies it.

A number that raises a question. "I have changed my intended major four times and I can defend every one of them."

A claim they could disagree with. "The attention economy is not a shallowness machine. It is a self-focus machine." Contestable claims are interesting. Mission statements are not. A reader who mildly disagrees is a reader who is still reading.

Three that kill it:

  • Restating the question. "There are many reasons I want to join X."
  • "I have always been passionate about." They have read this forty times tonight.
  • A quote or dictionary opener. Even a good quote costs you your only free sentence.

Specificity is the whole game

Every applicant claims initiative, leadership, and curiosity. Nobody can claim your details.

GenericSpecific
I led a large organizationI ran a 90-person org and a coalition of 20 others
We improved the processCut check-in from 25 minutes to 6 by pre-printing badges
Interested in consultingI want to know why the nonprofit I worked at ran three overlapping intake forms
Passionate about designI redrew our flyer six times because nobody could find the date

Names, numbers, mechanisms. If you cannot put a number on it, put a mechanism on it: what specifically you did that changed what specifically happened.

Never invent the number. If it is not known, write [NEED: how many] and ask.

Answer the question that was asked

The most common failure is not bad writing. It is answering an adjacent, easier question.

  • "A time you failed" is not "a time I struggled and then triumphed." Give a real failure with a real cost you did not fully recover. That is the test: can you look at yourself honestly.
  • "Why this org" is not "why this field." If the answer works for three orgs, it is not an answer to this one.
  • "A time you disagreed with a teammate" is not "a time I was right." Resolution matters more than vindication.
  • "Tell us about yourself" is a trap for people who list. Pick one thread and follow it all the way down.

The two questions under almost every prompt

Applications ask ten things and score two. See the unasked-questions skill for the full method, but these two run under nearly every prompt:

Why us and not the six others like you? If you are applying to several orgs in one lane, every one of them knows it. Any sentence in a "why us" answer that would work for a different org is a wasted sentence. Name one specific thing: a project they ran, an alum outcome, a workshop you attended, a person you talked to. Never their website adjectives back at them.

Are you here to learn or to be impressive? This one cuts hardest against strong applicants. People who have actually shipped things fail it constantly by arriving as someone who already knows. Naming your gap honestly is the move that works: "the work felt like consulting, but I was doing it on intuition." That gives the org a job.

The "why us" trap

Write five applications without watching for this and all five have the same shape: here is what I built, here is what I cannot do yet, please teach me.

Vary it. Some answers should be what you will do for them, in specific terms. "You run four client projects a semester and none of them have a person who can build the thing at the end. I can build the thing." That is a different sentence than anything else in the pile.

Word limits are a design constraint, not a trim job

The limit determines which story you can tell, before you write a word.

A 75-word answer cannot hold a story that needs setup. If you open a hard subject with no room to land it, the reader gets the weight and none of the resolution, and they close the tab uneasy. That is worse than a smaller story told completely.

So pick the story that fits, then use 90 to 100 percent of the limit. An answer at 40 percent reads as low effort even when it is tight, because the reader is comparing you to someone who used all 250.

The fun questions are real questions

Mostly a student-org thing, and occasionally accelerator. Favorite snack. A song that describes your life. Your life as a TV show. These are not filler. This is the org deciding whether they want to sit next to you on Tuesday nights for a semester.

Answer with an actual specific thing you actually like. Strategic answers are visible from space and read as someone who cannot relax. Specific and slightly odd beats clever every time.

One caution: an answer that depends on something painful the reader does not know about you will land differently than you expect. If it needs backstory they do not have, pick a different answer.

The other types have their own version of a question that looks soft and is not:

  • job: "do you have any questions for us." Scored more than applicants think, and the failure mode is asking something the careers page answers.
  • fellowship and grad-school: the optional statement or the "anything else we should know" box. Taking it is the answer.
  • grant: sustainability. It sounds like boilerplate and it is the question the committee actually argues about.
  • accelerator: "what is your biggest risk." Naming a real one plainly reads as maturity. Saying execution reads as someone who has not thought about it.

Repetition

Within one application: never tell the same story twice. The reader sees the whole form and it makes you look like you have one experience.

Across different orgs: reuse your strongest material freely. A reader going through 200 applications is not cross-referencing one applicant, and every applicant reuses. Just re-angle it toward what each org actually asked.

Structure inside an answer

If the form mandates headings, use theirs, in their order. This is the norm for grant and common for fellowship, and a reviewer hunting for your evaluation plan should not have to find it. grad-school statements have their own expected shape, in reference/grad-school.md, and it is not this one.

Otherwise, for anything over 100 words:

  1. Concrete opening, no setup
  2. What you did, in mechanisms
  3. What happened, with a number if a real one exists
  4. What it changed about how you think

Cut the fourth if you are over the limit. It is the part everyone writes and the part that reads most like everyone.

Numbers have to match across every document

The same claim appears on the resume, in three essays, and in the interview. If it grows between documents, that is the thing that gets caught, and it usually gets caught in the room rather than on the page.

Pick the version you can defend, write it in you/PROFILE.md, and use that one everywhere. A smaller number you can walk someone through beats a bigger one you cannot.

Before calling an answer done

  • Could a stranger swap this into their form unchanged? If yes, not finished.
  • Is every claim true, yours, and consistent with every other document?
  • Are you at 90 to 100 percent of the limit?
  • Does the first sentence earn the second?
  • Did you answer the question they asked, or the one you wanted?
  • Go down its unasked-questions list. Could a reader with only your answer in front of them answer each one? Three misses is your revision.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.