Grill founder

Skill lightarktech/founder-coding-skills/skills/grill-founder

Claude Code skills for non-technical founders, solopreneurs & one-person companies running an AI engineering team — no coding experience required. Six battle-tested skills + a real token-burn postmortem.

Install

npx -y skills add lightarktech/founder-coding-skills --skill grill-founder

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

15 days oldThe repository was created 15 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

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

2.8 KB, 513 tokens by cl100k_base, as published. Nobody here has run it

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.

What ships with it

Read from the repository