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
- sakuruamayday-ops/enterprise-project-application-assistanttheir own version, first seen Oct 9, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- application-typesSkill
- honesty-guardSkill
- interviewing-youSkill
- mock-interviewSkill
- no-slop-writingSkill
- org-researchSkill
- reader-povSkill
- unasked-questionsSkill
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
- Distinctive: line 57
Every applicant claims initiative, leadership, and curiosity.
- Very specific: line 70
Never invent the number: If it is not known, write [NEED: how many] and ask.
- Distinctive: line 92
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.
- Distinctive: line 105
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, …
- Distinctive: line 152
Within one application: never tell the same story twice.
- Very specific: line 161
If the form mandates headings, use theirs, in their order.
≈ “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.
Files
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:
| Type | The reader | How long they spend |
student-org | A peer who will be your teammate | 60 to 90 seconds |
job | A filter, then a hiring manager | Under a minute, then longer |
fellowship | A committee scoring published criteria | Long, several readers |
grad-school | Faculty reading for fit with a lab | Long |
grant | A program officer with a checklist | Long, structured |
accelerator | A partner looking for a reason to take a call | Fast |
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.
| Generic | Specific |
| I led a large organization | I ran a 90-person org and a coalition of 20 others |
| We improved the process | Cut check-in from 25 minutes to 6 by pre-printing badges |
| Interested in consulting | I want to know why the nonprofit I worked at ran three overlapping intake forms |
| Passionate about design | I 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.fellowshipandgrad-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:
- Concrete opening, no setup
- What you did, in mechanisms
- What happened, with a number if a real one exists
- 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.
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
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.

