Skill: Report Authoring

Needs the Cook MCP server (tools like render_report and write_config). If these tools are missing, the Cook MCP server isn't connected: if you installed the cooklang plugin or extension, check that its cook server is running (e.g. /mcp) or reinstall it; otherwise add it from https://github.com/cook-md/cook-mcp. Do not compute report values by hand instead.

Author and run Jinja2 report templates over the user's recipes with the render_report tool — or reuse a saved one — then answer from the output or present the report. Use this skill when the user wants a computed value (ingredient counts, a scaled printout), a custom report or summary, or a new report template. For nutrition or dietitian-style evaluations, follow the nutrition-reports skill instead.

Templates that don't call nutrition functions render locally, with no login. Datastore values live in YAML files under db/; cook-mcp has no tool that writes them, so ask the user to add data there (or use your client's file tools).

The tool

render_report renders one template against one .cook recipe or .menu plan and returns { "rendered", "checks", "resolve_failures" }, or an error naming the template line. It never edits files.

Arguments — the template, exactly one of:

• template — inline Jinja2 source, for drafts and one-off reports.
• template_path — a saved template file, relative to the collection root (e.g. reports/cost.md.jinja). Prefer it whenever a suitable saved template exists.

The input, exactly one of:

• input_path — a .cook or .menu file as list_recipes returned it (kind inferred from the extension).
• input — inline Cooklang text, with kind ("cook" or "menu").

Optional:

• scale — recipe scale factor (default 1). Scales .cook recipes only, not .menu quantities.
• base_path — folder that @./ references resolve from; defaults to the collection root, which is almost always right.

Template context and filters

Within a template you have:

• ingredients — list; each item has .name and .quantity.
• metadata — recipe metadata, including metadata.title and any custom keys.
• scale — the numeric scale factor.
• For .menu input: plan — the plan's days and meals with their expanded ingredients (a menu is read through plan.*, not ingredients).

Collection data:

• aisled(ingredients) — groups ingredients by store aisle from config/aisle.conf: a map of aisle → items, unlisted items under other. Use it with | items.
• excluding_pantry(ingredients) — drops ingredients already in config/pantry.conf; from_pantry(ingredients) keeps only those.
• db('key.path') — reads the collection's YAML datastore, the db/ folder at the root: db('eggs.shopping.price') is the price key of db/eggs/shopping.yml. Use it for per-ingredient data the recipes don't carry (prices, shelf life, densities). A missing key renders empty.

Filters available:

• Standard Jinja: sort(attribute='name'), default(...), round, join, selectattr, items, length.
• Text: titleize, humanize, upcase_first.
• Numbers: number_with_precision, number_with_delimiter, number_to_percentage, number_to_currency, format_price, numeric.

Example — an ingredients list:

# {{ metadata.title | default("Ingredients") }}

{% for ingredient in ingredients | sort(attribute='name') -%}
- {{ ingredient.name }}{% if ingredient.quantity %}: {{ ingredient.quantity }}{% endif %}
{% endfor %}

Example — a cost estimate from the datastore, skipping what's in stock:

{% set ns = namespace(total=0) %}
{% for aisle, items in aisled(excluding_pantry(ingredients)) | items %}
## {{ aisle | titleize }}
{% for i in items -%}
{% set price = db(i.name ~ '.shopping.price') %}
- {{ i.name }}{% if price %}: {{ price | format_price }}{% set ns.total = ns.total + price %}{% endif %}
{% endfor %}
{% endfor %}
**Estimated total:** {{ ns.total | format_price }}

For a plain shopping list, use the shopping_list tool rather than a template: it merges duplicates across recipes, groups by aisle and subtracts the pantry.

Workflow: reuse or author -> render -> present

1. Saved templates live in reports/ (CookCLI) or config/reports/ (Cook Editor): list_recipes kind: "template" lists both. If one matches the request (read the name; ask the user when it isn't conclusive), render it with template_path and skip to step 4.
2. Otherwise draft the template inline.
3. Call render_report with template. If it errors, read the message (minijinja reports the line), fix the template, and render again until it renders cleanly.
4. To answer a question (e.g. "how many ingredients?"), read rendered and reply with the answer. To present a report, show the rendered markdown to the user as it came back.

Saving a reusable template

When the user wants to keep a report, save the template as a .jinja file:

• Save it where the collection already keeps templates — reports/ (CookCLI) or config/reports/ (Cook Editor), whichever list_recipes kind: "template" shows in use; default reports/. Subfolders are fine.
• Declare the output format via the inner extension: weekly-cost.md.jinja -> markdown, menu.html.jinja -> HTML, shopping.txt.jinja -> plain text.
• Save it with write_config (path e.g. reports/weekly-cost.md.jinja, the full template as content), and tell the user where.
• From then on, render it with template_path — never re-send the source inline.

Render inline for one-off questions; offer once to save a template, and save only if the user accepts.