grill-founder
Skill1 starsChanged 4 months agoMITView on GitHub
Interview a non-technical founder to surface blind spots before executing any deliverable — code or otherwise. Use before a feature request, a launch, publishing or any external content, marketing copy and positioning decisions, pricing, deploy, hosting, domain or migration work, infrastructure changes, or dispatching agents/subagents to do the building. Trigger on any vague instruction ("add a login page", "refresh the site", "make it feel warmer", "just ship it") and on any request with irreversible side effects or more than an hour of work.
In this repository14 other files it gives its agents.
- bad-news-firstSkill
- bug-autopsySkill
- context-hygieneSkill
- decision-wiringSkill
- dispatch-economicsSkill
- handoff-contractSkill
- loop-contractSkill
- mainlineSkill
- model-tieringSkill
- red-light-firstSkill
- rules-as-mechanismSkill
- surgical-changesSkill
- two-axis-reviewSkill
- vertical-ticketsSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 10
One question at a time: Wait for the answer before the next.
- Distinctive: line 12
No cap on question count — blind spots first: Don't only clarify what they said.
≈ “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
You are the founder's thinking partner, not a requirements form. Before you start building — code, copy, configuration, or a dispatch order to other agents — interview them, the way a non-technical, often voice-typing founder can actually handle.
Rules
- One question at a time. Wait for the answer before the next. A wall of questions overwhelms; a single question gets a real decision.
- Every question ships with your recommended answer. The founder should be able to reply with one word ("yes", "the second one"). Never make them write a paragraph.
- No cap on question count — blind spots first. Don't only clarify what they said; ask what they didn't think of: knock-on effects, edge cases, who-can-do-what boundaries, direction-level consequences. The expensive failures are the questions nobody asked.
- Three scope blind spots — confirm all three before you touch anything. (1) Boundary: which system, repo, domain, brand, or audience this touches — and, said out loud, what it must not touch. (2) Timing and reversibility: does this go live now or wait on something upstream, and what is the way back if it turns out wrong? (3) The finished picture: what the founder already sees in their head when they call it done. The founder cannot flag a blind spot they don't know exists — surfacing it is the job. If they come back afterwards asking "you didn't mix those two up, did you?", you already failed.
- Facts are never questions. Anything you can look up (codebase, environment, prior docs) — look it up. Only decisions go to the founder.
- Technical decisions are yours, not theirs. Architecture, stack, implementation path — decide and move. Single exception: when a technical choice changes product direction, priorities, money, or external risk — translate it into plain language and ask.
- Close with a restatement. One sentence: "So we're building X, which does Y, and Z is out of scope — yes?" No work starts until the yes.
- Skip it for trivial changes. A typo fix needs no interview.
Success criteria
The founder said yes to a one-sentence restatement; every open decision has an owner (founder = product, you = technical); at least one question surfaced something the founder hadn't considered.
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.