No GLOSSARY.md exists yet, so I'll create one when the first term is settled. These are the questions with no prerequisites. The rest of the design depends on your answers to them.
❓ Q1 - What is a "meal plan"?: Is a Meal Plan a persistent object a user creates, names, and keeps (for example "Week of Oct 14"), or just the user's single current week view that gets overwritten? Is it tied to a calendar week (dated) or to a generic Mon–Sun template that can be reused?
➡️ Make it a persistent, named object tied to a specific calendar week (it has a start date). Users can duplicate a past plan into a new week. That covers the template use case without a second concept.
❓ Q2 - How many meals per day?: "Pick recipes for each day" is ambiguous. Does each day hold one recipe, or several, such as breakfast, lunch, dinner, and snack slots? Can one slot hold multiple recipes, such as a main and a side?
➡️ Each day has named meal slots (breakfast, lunch, dinner, snack). A slot can hold multiple recipes, and any slot can be left empty.
❓ Q3 - Which recipes can be planned?: Can users plan only recipes from the site (their own, other users' public ones, and saved ones), or also free-text entries like "leftovers" or "eating out"? What happens to a plan when the recipe's author edits or deletes the recipe?
➡️ Only site recipes, plus a free-text "note" entry that adds nothing to the shopping list. When a recipe is edited, the plan reflects the latest version. When a recipe is deleted or made private, the plan keeps a tombstone entry, and the shopping list excludes it with a visible warning.
❓ Q4 - Servings: Recipes have a fixed yield, such as "serves 4". Can the user set a servings count per planned entry (scaling the ingredient quantities), or is every entry one cooking of the recipe as written?
➡️ Yes. Each planned entry has its own servings count, which defaults to the recipe's yield. Ingredient quantities are scaled proportionally.
❓ Q5 - Shopping list: derived or stored?: Is the Shopping List always computed live from the plan, or is it a separate object created from the plan? If it's separate, it can hold checked-off items and manual additions. If it's live, those need somewhere else to live.
➡️ Make it a separate object generated from the plan. It stores check-off state and manual extra items. Regenerating is an explicit user action that preserves checked-off and manual items where it can.
❓ Q6 - Ownership and sharing: Is a meal plan private to its owner, or can it be shared or published, for example a household co-editing one or a public "my week of meals" post? This is a recipe-sharing site, so sharing is likely to come up.
➡️ Private to the owner in v1. Others can copy a plan only via an explicit share link that creates their own copy. There is no co-editing.
I'll record the terms (Meal Plan, Meal Slot, Planned Entry, Shopping List) in GLOSSARY.md as you settle them. Ingredient merging, unit conversion, and pantry handling come in the next round, once Q4 and Q5 are settled.
How it was tried: I installed grill-with-docs together with the grilling and domain-modeling skills it calls, in a clean temporary folder, and invoked it as a slash command with a made-up design (a meal-plan feature for a recipe site). Only Skill and Read tools were allowed, so no files could be written: the model says it will create GLOSSARY.md once terms are settled, and no document was actually produced in this run. It shows the first round of questions only.
What it does
The same relentless interview as grill-me, plus documentation: as decisions land, they are recorded as architecture decision records (ADRs) and a domain glossary. It calls two skills, grilling (the questioning) and domain-modeling (sharpening terms and recording them).
How it works
- You invoke it yourself (the model will not trigger it on its own).
- It tells the agent to call
grillinganddomain-modeling. - You are interviewed one question at a time while the docs are updated.
Good for
Design discussions where you want the reasoning kept, not lost in chat. Needs grilling and domain-modeling installed. It writes documents into your project.
Medium risk: No scripts and no network access of its own, but the interview it starts is meant to create documents as decisions are made (ADRs and a glossary), so it will write files into your project. Check the diff before committing, and run it in a repo where that is acceptable. It calls `grilling` and `domain-modeling`, which must be installed. It is flagged to be invoked manually. Tried once with `grilling` and `domain-modeling` installed alongside, with file writing disabled, so no documents were actually written and only the first round of questions was observed.