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.
它做什么
和 grill-me 一样的不留情面的追问，外加文档：决策一旦敲定，就记录成架构决策记录（ADR）和领域术语表。它调用两个 Skill：grilling（负责提问）和 domain-modeling（打磨术语并记录）。
工作方式
- 由你手动调用（模型不会自己触发）。
- 它让代理调用
grilling和domain-modeling。 - 你被逐个提问，同时文档随之更新。
适合场景
希望把推理过程留下来、而不是淹没在聊天记录里的设计讨论。需要同时安装 grilling 和 domain-modeling，并且会向你的项目写入文档。
中风险：自身没有脚本、不联网，但它发起的追问会随着决策的产生写出文档（架构决策记录 ADR 和术语表），所以会向你的项目写入文件。提交前请看一下改动，并在允许这样做的仓库里使用。它会调用 `grilling` 和 `domain-modeling`，需要一并安装。它被标记为只能手动调用。 已和 `grilling`、`domain-modeling` 一起试用一次，试用时禁止了写文件，所以没有真正写出文档，只看到了第一轮提问。