# Grill Founder

> 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.

- Skill: `lightarktech/grill-founder` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lightarktech/grill-founder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lightarktech/grill-founder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: lightarktech (https://skillmd.com/u/lightarktech)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lightarktech/grill-founder

---


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.