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` 一起試用一次，試用時禁止了寫檔案，所以沒有真正寫出文件，只看到了第一輪提問。