skills / other

grilling

what it does

Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.

Verified Before and after: 2 models 1 try per case View source Download .zip

Compare the answers

Answers from Claude Sonnet 5.5 and GPT-6.1 Sol · try 1 of 1

Same request, same model, once with the skill and once without. Read both and judge for yourself.

“Grill me on this plan before I start building.”

Source material given with the request

Side project: a recipe-sharing app. - React Native app, Supabase backend - Users can post recipes with photos and follow other cooks - Recipes can be private, shared with friends, or public - Offline mode so you can cook without signal - I want comments and likes too - Launch in 4 weeks, just me, evenings only
with the skill
Let's start with the decision that constrains all the others: **scope against your time budget.** You have about 4 weeks of evenings, which is roughly 60-80 hours if you're disciplined. The plan includes: - Auth and profiles - Recipe CRUD with photo upload - Follow graph - Three-tier visibility (private / friends / public) - Offline mode - Comments - Likes Offline sync and the visibility model are each easily a multi-week effort when done properly. Offline sync in particular tends to eat the whole schedule. **Question 1: What does "launch" mean to you, and which of these features must be in v1 for it to count?** **My recommendation:** Define launch as "a small group of real people (say 10-30 friends) can use it on their phones via TestFlight/internal testing." Then cut v1 to: - **In:** auth, recipe CRUD with photos, private/public visibility only, and read-only offline caching of recipes the user has saved or viewed (not offline editing or sync) - **Cut or defer:** friends-only visibility (it needs a mutual-friend model, which is different from one-way follow), comments, and full offline writes - **Maybe:** likes, since they're a cheap single table plus a counter, and follows
Show the rest (3 more lines)
That gives you something you can finish and put in front of people. Offline cooking, the feature that sets this app apart, still works in its most useful form: opening a recipe in the kitchen with no signal. What's your definition of launch, and which features do you consider non-negotiable?
without
Here's where I'd push hardest, starting with the biggest problems. ## 1. The math doesn't work Four weeks of evenings is roughly 60-80 hours. Your list includes auth, recipe CRUD, photo upload, a follow graph, three-tier privacy, offline sync, comments, likes, and a feed. Each of those is a week of work if you want it solid. **Which of these would you cut first, and why haven't you already?** ## 2. Offline mode is the scariest item - Do you mean **read-only offline** (cache saved recipes so you can cook) or **offline creation and editing** with sync? The first is a few days of work. The second is a distributed-systems problem. - If users can edit offline, what happens on conflict? Last-write-wins? Do you know what that does to a recipe edited on two devices? - Which recipes get cached? All followed cooks' recipes, or only ones the user explicitly saves? - Do photos get cached too? What's your storage budget on the device? - Are you using WatermelonDB, SQLite, React Query persistence, or something else? Have you tested it with Supabase before? My suggestion is a "Save for offline" button that caches one recipe's text and photos. That covers the cooking-without-signal use case in a fraction of the time. ## 3. "Friends" vs. "following" is undefined - Following is usually one-way. "Shared with friends" implies a mutual relationship. **Are these two separate graphs, or is "friend" just mutual follow?** - If it's mutual follow, what happens to a recipe's visibility when someone unfollows? - Can you share with a specific person, or only a whole friend list? - Have you written the Row Level Security policies for this? A bug here means private recipes leak, which is the worst failure your app can have. Comments and likes on a private recipe need to respect the same rules, and that's easy to forget.
Show the rest (45 more lines)
## 4. Public UGC has obligations Apple and Google both require, for apps with user-generated content: - A way to **report** content - A way to **block** users - Terms/EULA acceptance - **In-app account deletion**, which means deleting their recipes, photos, comments, and likes Have you budgeted time for these? Who reviews reports? It's you, and you have a day job. Would launching with private and friends-only first, and adding public later, be an option? ## 5. Photos are more work than they look - Are you resizing and compressing on the client before upload? Phone photos are 3-8 MB each. - How many photos per recipe? Per step, or just a hero image? - What are your Supabase storage and egress costs if 500 people each upload 10 photos? - Do private recipe photos live in a private bucket with signed URLs? How do those interact with offline caching, given that signed URLs expire? ## 6. Why would anyone use this instead of the alternatives? - Why not Notes, Paprika, Pinterest, or a shared Google Doc? - You're launching a social app with zero users. A feed of nobody's recipes is dead on arrival. **Who are your first 20 users, by name, and what will they post?** - Is the core value *storing my own recipes* (private, offline, useful alone) or *discovering others'* (needs network effects)? I suspect the first is far more achievable, and the social features are a layer on top. ## 7. What does "launch" mean? - App Store review can take days and can bounce you. Have you factored that into the 4 weeks? - Do you have an Apple Developer account ($99) and a Google Play account ($25)? Are you launching on both platforms? Testing both takes time too. - Is "launch" TestFlight with 10 friends, or the public stores? Those are very different goals. ## 8. Smaller gaps - Do you need notifications (new follower, comment)? That means push infrastructure. - Search: do you need it? Postgres full-text on recipes, or just browsing? - Recipe structure: freeform text, or structured ingredients and steps? Structure enables scaling and shopping lists but costs time. - Likes and comments counts: computed on the fly or denormalized? Either is fine at your scale, but decide now. - What happens when a followed cook deletes a recipe you cached offline? ## My blunt take Right now this is a 4-6 month plan. A realistic 4-week version looks like: 1. **Weeks 1-2:** Auth, recipe CRUD with photos, private and public only, and "save for offline" read-only caching. 2. **Week 3:** Follow and a simple feed, plus likes. 3. **Week 4:** Report/block/delete-account, polish, TestFlight. Comments, friends-only sharing, and offline editing come after launch. Answer these three and I'll know where to dig next: 1. What's the one thing that makes this worth using on day one with no network? 2. Which offline behavior do you actually need? 3. Who are your first 20 users?

Answers are shown exactly as the model wrote them, from the first try, and nothing is picked by hand.

The models

2 models

Claude Sonnet 5.5

made by Anthropic

claude-sonnet-5-5 · revision not reported by the provider

1 try per case · tested 3 Nov 2026

GPT-6.1 Sol

made by OpenAI

gpt-6.1-sol · revision not reported by the provider

1 try per case · tested 3 Nov 2026

The tasks

written by Carte Blanche
on-call-rotation-change

“We're changing our on-call setup next month. Interview me about the plan until you're sure it holds up.”

pricing-change-plan

“Before I take this to the founders, grill me on it.”

rate-limiter-design

“I'm about to build rate limiting for our public API. Stress-test the design with me first.”

recipe-app-plan

“Grill me on this plan before I start building.”

second-bakery-location

“I'm opening a second location for my bakery next spring. Poke holes in the plan, but go one thing at a time so I can actually think.”

Install

Download the .zip and unzip it. Put its files, in a folder named grilling, here:

Claude Code~/.claude/skills/Every project. For one project only, use .claude/skills/ inside it.
Codex~/.agents/skills/Every project. For one repository only, use .agents/skills/ inside it.
Cursor~/.cursor/skills/Cursor also reads the Claude Code and Codex folders above.

Then start a new session and ask for what the skill does. Other agents that read SKILL.md have their own skills folder; check their docs.

Coming after launch: get skills from inside your agent, no download needed.