In this article
A goose recipe packages instructions, settings and extensions. Parameters must match its placeholders; a saved recipe does not install a model or grant tool access.
A goose recipe packages a recognizable workflow so its variable inputs can be supplied again. It is useful for repeated local tasks such as summarizing a chosen source file under a stable review format. Reproducibility still depends on the model, extensions and working environment, rather than the saved prompt alone.
Define the stable task and changing inputs
The Recipes overview describes packaging prompts, settings and extensions. Write down what remains constant and what must be chosen for every run. A source path, output destination and review style have different meanings and should not be hidden in one free-form field.
For a local code summary, keep the summarization instruction fixed and require the source file explicitly. Avoid reusing a personal absolute path as an unexplained default. A colleague or a later session may otherwise read a different file while believing it is running the same task.
Follow the parameter contract
The recipe reference describes named placeholders and typed parameter definitions. Its required, optional and user-prompt behaviors differ. Optional parameters need defaults, while required and file parameters have separate restrictions. Read the current contract before inventing a convenient-looking field.
Check that every used placeholder has the intended definition. Inspect the expanded instructions before interpreting the answer. A literal unresolved placeholder can produce plausible but unrelated output; that is an input-preparation failure, not evidence that the model misunderstood the source file.
Verify the selected local model
The provider documentation describes the separate model connection. A recipe cannot turn an unavailable runtime into a working local endpoint. Confirm model identity and a simple response before introducing the recipe’s tool-dependent workflow.
Keep the model revision and applicable generation settings visible in the experiment. Repeating a recipe after changing its model is useful, but it is a new condition. A matching recipe filename does not guarantee identical inference behavior or identical handling of structured tool requests.
Review extension capabilities
The extensions guide explains how tools are supplied to goose. Check which extensions the recipe expects and whether they are available in the actual environment. Package availability, connection health and permission for the requested resource are distinct checks.
For the sample summarization task, begin with the smallest required file-reading capability. Inspect the named source and output location. A recipe that previously worked with another user’s extension configuration should not receive broader access merely to reproduce an unexplained historical result.
Test repetitions and incomplete input
Run the recipe with two different sample files and confirm that their facts do not leak into each other’s summaries. Then omit an expected input and observe the documented validation or prompting behavior. Include a path containing spaces if that resembles actual use.
Store the recipe revision, parameter values and output together for the exercise. Distinguish a repeatable workflow from deterministic model output. The useful result is a clear input contract and reviewed task execution, with missing dependencies reported explicitly instead of silently replacing the requested operation with an unsupported text answer.
Related reading
Reproducible inference stacks: preserving a GPU pilot’s result, Coding LLMs on 12GB VRAM: Budget Context and Headroom.