Feed your agent. Keep what it cooks.

You are cooking a HardlySimple "dogfood bowl": The solar system, next twelve months.

Build a complete picture of the solar system and where its bodies are heading over the coming twelve months: the planets themselves, the sky events they produce, and the spacecraft currently flying between them.

Everything below runs through the HardlySimple MCP server (https://hardlysimple.com/mcp). If it is not connected yet, install it first: https://hardlysimple.com/get-mcp. Work in MY account — you are not writing files, you are creating objects on the platform.

## Ground rules

- Open with start_companion_session (your provider, model id and effort) so this run is attributed and shows up live, and close with end_companion_session.
- Everything for this bowl goes in ONE new databank and hangs off ONE task on my personal board. Do not scatter it across my existing containers.
- Real field types beat text: dates as date, quantities as number, categories as single_select — and, when the subject has places in it, points as location ({ lat, lng }) and outlines as geojson. A chart can only plot what was typed honestly, and a map can only be drawn from a column that admits it holds a place.
- Cite sources and give every figure the year it refers to. Say plainly in the data when a value is approximate or derived.
- If a tool fights you — a bad schema, a confusing error, a missing capability — call report_session_friction. Being told where the platform is rough is half the point of this exercise.

## What to gather first

- The bodies: the eight planets plus Pluto and Ceres — diameter, mass, moons, and the orbital elements that matter (semi-major axis in AU, eccentricity, inclination, orbital period, mean orbital speed).
- The sky calendar for the next twelve months: oppositions, solar and lunar eclipses, meteor-shower peaks with expected rates, greatest elongations of Mercury and Venus, equinoxes and solstices. Date, body, what to look for, and where on Earth it is visible.
- Trajectories: for each planet, sample its heliocentric longitude and its distance from the Sun once a month across the year, so the motion can be plotted rather than described. A mean-element approximation is fine — say so in the data and record the epoch and method you used.
- The spacecraft in flight: orbit insertions, arrivals and gravity-assist flybys happening in the same window (BepiColombo, JUICE, Hera, Lucy, Psyche and anything else en route).
- Sources and dates for every row. An ephemeris without an epoch is a rumour.

## Then build, in this order

1. list_taskboards, pick my PERSONAL default board, and create_task there: title "Dogfood bowl 1 — the solar system over the coming year", the brief as the description, tags ["dogfood"]. Keep the task id — everything links back to it.
2. create_databank (scope personal) titled "Dogfood — Solar System", then attach it to the task with add_databank_item (kind task) so the card and the container know about each other.
3. SimpleTable: create_structured_workspace "Solar System", then create_structured_table for each of — Bodies (one row per planet + Pluto and Ceres); Sky events (one row per dated event in the coming year); Trajectory samples (one row per body per month) — declaring typed fields up front. Fill them with bulk_insert_structured_records (100 rows per call, all_or_nothing so a bad row tells you which one). Then add_databank_item (kind structured_workspace), and link the tables to the task (structuredTableIds on update, or attach_databank_item_to_task).
4. Charts: save at least two with create_structured_chart — one live (re-reads its table forever) and one snapshot (frozen at capture) — then add_databank_item (kind chart). Kinds: bar, hbar, grouped, share, line, area, donut, treemap, heatmap, scatter, and three that draw a MAP instead of axes — choropleth (colours countries or US states from a text column of names or codes), bubblemap (a circle per location cell, sized by a number) and shapemap (your own geojson outlines). If your tool catalog has no chart tools, your MCP session predates them: reconnect the server and try again, and open the table at /databanks/simpletable/tables/<id>?view=chart meanwhile.
5. Sketch: create_sketch, then add_shapes_to_sketch and add_diagram_to_sketch to draw the thing rather than describe it. Place the tables and documents on the canvas with add_databank_item_to_sketch, then link_sketch_to_task and add_databank_item (kind sketch).
6. Knowledge bundle: create_knowledge_bundle, create_concepts for the ideas a newcomer would trip over (definition, why it matters, how it relates to the others), then add_databank_item (kind knowledge_bundle) and link_knowledge_bundle_to_task.
7. The decks — the same story in every style the platform has, each one a DECK object with its own URL rather than a file you uploaded. Call get_deck_standard({ kind }) FIRST: it hands back the house layout for that kind, the deck-* class vocabulary to build from, and a cover and a signoff already written. Then create_deck once per kind, passing taskId and databankId in the same call so each deck lands on the card and in the databank without a second round trip. Paste snippets.cover as the first unit and snippets.signoff as the last, verbatim, and build everything between them out of the deck-* classes — never hard-code a colour, a font or a logo, because the platform injects those and that is exactly what lets the deck re-theme itself the day the design changes. This subject is numbers attached to named bodies, so the flip deck almost writes itself: the body on the front, its diameter, moon count and orbital period on the back. Point the decision deck at the year ahead — of everything you found, which three am I actually setting an alarm for?
8. The four showing kinds, which differ only in GEOMETRY — that is why they are separate kinds and not one setting, and writing all four is the fastest way to feel the difference. `presentation`: ten slides, type in viewport units so it fills a 27" screen. `flip`: six to ten cards with a real BACK to each — write both faces, because a card nobody needs to turn over is just a slide. `print`: four to six true A4 pages with a running head and numbered feet, which export to PDF exactly as laid out and therefore carry NO entrance motion (an animation that has not run prints as a blank sheet). `web`: the long write-up as five or six full-bleed bands on one long scroll — this is the epic, so it is where the sources and the caveats live.
9. The decision deck: create_deck kind "decision" with NO html at all — just a `goal` and three or four `decisions`, each with its options and a line of `context` carrying the facts I need in order to choose. The platform writes that page itself, in the same house style, with the answer hooks already wired: fewer tokens than writing it, and it cannot drift from the standard. Pass taskId so the ask lands in the card thread where I will actually see it.
10. The storyboard: a SECOND sketch — create_sketch "The solar system, next twelve months — storyboard" — about the RUN rather than the subject. Place every object you made on it: add_object_to_sketch for the task, the SimpleTable workspace, each saved chart, the subject sketch and the knowledge bundle (objectKind task | structured_workspace | structured_chart | sketch | knowledge_bundle), and add_databank_item_to_sketch for each of the five decks. Lay them left to right in the order you built them, leaving room between clusters. Then caption every one with add_shapes_to_sketch: a short text shape beside each saying what it IS, why this bowl needed it, and what I would do with it next — and arrows joining them so the reading order is obvious (research → tables → charts → decks). Someone who opens only this canvas should be able to explain the whole bowl without opening anything else. Finish with link_sketch_to_task and add_databank_item (kind sketch).
11. Write the run up on the card with add_task_comment (kind "status"): what you built, what surprised you, and a link to each object. Then regenerate_task_summary so the board reads well at a glance.
12. Put the year on my calendar: create_calendar_event for every eclipse, opposition and shower peak you found, each with the one line I would need on the night.

## When you are done

- Report back with the URLs: the task, the databank, the SimpleTable workspace, the charts, BOTH sketches (the subject and the storyboard), all five decks and the knowledge bundle (they live under https://hardlysimple.com).
- Tell me what you could not do, and what you would have wanted the platform to give you.

By the end you have a year of sky, on your own calendar, backed by a table you can re-chart any time.

You are cooking a HardlySimple "dogfood bowl": Benelux, the things people miss.

Assemble what is genuinely surprising about the Netherlands, Belgium and Luxembourg: the comparisons that overturn an assumption, not the facts a tourist board would lead with.

Everything below runs through the HardlySimple MCP server (https://hardlysimple.com/mcp). If it is not connected yet, install it first: https://hardlysimple.com/get-mcp. Work in MY account — you are not writing files, you are creating objects on the platform.

## Ground rules

- Open with start_companion_session (your provider, model id and effort) so this run is attributed and shows up live, and close with end_companion_session.
- Everything for this bowl goes in ONE new databank and hangs off ONE task on my personal board. Do not scatter it across my existing containers.
- Real field types beat text: dates as date, quantities as number, categories as single_select — and, when the subject has places in it, points as location ({ lat, lng }) and outlines as geojson. A chart can only plot what was typed honestly, and a map can only be drawn from a column that admits it holds a place.
- Cite sources and give every figure the year it refers to. Say plainly in the data when a value is approximate or derived.
- If a tool fights you — a bad schema, a confusing error, a missing capability — call report_session_friction. Being told where the platform is rough is half the point of this exercise.

## What to gather first

- The side-by-side fundamentals for all three: area, population, density, GDP per capita, highest and lowest point, official languages, capital, EU accession.
- The surprising column — one claim per row, each of which changes what a reader thought was true. Cross-border commuters as a share of Luxembourg's workforce; the enclaves and counter-enclaves at Baarle; the 2016 Belgium–Netherlands border swap; the four-country point that existed until 1919; how much farmland the Netherlands exports from; how dense Belgium's rail network is; free nationwide public transport in Luxembourg.
- For every claim: the number, the year it refers to, and the source. A statistic without a year is a rumour — mark anything you could not date.
- At least one dimension all three can be ranked on (density, commuters, languages spoken, land below sea level) so the table can be charted rather than read.
- The geography as DATA, not prose: each country's ISO code (NL, BE, LU) so it can be joined to a map, and the coordinates of the places the surprises actually happen — Baarle-Hertog and Baarle-Nassau, the Vaalserberg tripoint, Zeeland's lowest point, the vanished four-country point. Latitude and longitude per place, plus a rough outline as GeoJSON for at least one border oddity.
- The Benelux Union itself: signed in exile in 1944, in force in 1948, and the template the EEC was later built on.

## Then build, in this order

1. list_taskboards, pick my PERSONAL default board, and create_task there: title "Dogfood bowl 2 — Benelux, the things people miss", the brief as the description, tags ["dogfood"]. Keep the task id — everything links back to it.
2. create_databank (scope personal) titled "Dogfood — Benelux", then attach it to the task with add_databank_item (kind task) so the card and the container know about each other.
3. SimpleTable: create_structured_workspace "Benelux", then create_structured_table for each of — Countries (fundamentals + ISO code, one row each); Surprises (claim, number, year, source, country); Places (one row per notable spot: name, country, a location field, and a geojson outline where you have one) — declaring typed fields up front. Fill them with bulk_insert_structured_records (100 rows per call, all_or_nothing so a bad row tells you which one). Then add_databank_item (kind structured_workspace), and link the tables to the task (structuredTableIds on update, or attach_databank_item_to_task).
4. Charts: save at least two with create_structured_chart — one live (re-reads its table forever) and one snapshot (frozen at capture) — then add_databank_item (kind chart). Kinds: bar, hbar, grouped, share, line, area, donut, treemap, heatmap, scatter, and three that draw a MAP instead of axes — choropleth (colours countries or US states from a text column of names or codes), bubblemap (a circle per location cell, sized by a number) and shapemap (your own geojson outlines). This subject is three countries and a handful of very specific spots, so at least two of your charts should be maps: a choropleth over the Countries table (basemap world — the ISO code column is what it joins on) coloured by the ranked dimension, and a bubblemap over Places. Zoom is automatic: a table whose points sit inside Benelux gets Benelux, not the Atlantic. If your tool catalog has no chart tools, your MCP session predates them: reconnect the server and try again, and open the table at /databanks/simpletable/tables/<id>?view=chart meanwhile.
5. Sketch: create_sketch, then add_shapes_to_sketch and add_diagram_to_sketch to draw the thing rather than describe it. Place the tables and documents on the canvas with add_databank_item_to_sketch, then link_sketch_to_task and add_databank_item (kind sketch).
6. Knowledge bundle: create_knowledge_bundle, create_concepts for the ideas a newcomer would trip over (definition, why it matters, how it relates to the others), then add_databank_item (kind knowledge_bundle) and link_knowledge_bundle_to_task.
7. The decks — the same story in every style the platform has, each one a DECK object with its own URL rather than a file you uploaded. Call get_deck_standard({ kind }) FIRST: it hands back the house layout for that kind, the deck-* class vocabulary to build from, and a cover and a signoff already written. Then create_deck once per kind, passing taskId and databankId in the same call so each deck lands on the card and in the databank without a second round trip. Paste snippets.cover as the first unit and snippets.signoff as the last, verbatim, and build everything between them out of the deck-* classes — never hard-code a colour, a font or a logo, because the platform injects those and that is exactly what lets the deck re-theme itself the day the design changes. Every row in your surprises table is already a front and a back: the assumption on the front, the dated number that overturns it on the back. Point the decision deck at the write-up itself — which surprise opens the piece, and which country leads it?
8. The four showing kinds, which differ only in GEOMETRY — that is why they are separate kinds and not one setting, and writing all four is the fastest way to feel the difference. `presentation`: ten slides, type in viewport units so it fills a 27" screen. `flip`: six to ten cards with a real BACK to each — write both faces, because a card nobody needs to turn over is just a slide. `print`: four to six true A4 pages with a running head and numbered feet, which export to PDF exactly as laid out and therefore carry NO entrance motion (an animation that has not run prints as a blank sheet). `web`: the long write-up as five or six full-bleed bands on one long scroll — this is the epic, so it is where the sources and the caveats live.
9. The decision deck: create_deck kind "decision" with NO html at all — just a `goal` and three or four `decisions`, each with its options and a line of `context` carrying the facts I need in order to choose. The platform writes that page itself, in the same house style, with the answer hooks already wired: fewer tokens than writing it, and it cannot drift from the standard. Pass taskId so the ask lands in the card thread where I will actually see it.
10. The storyboard: a SECOND sketch — create_sketch "Benelux, the things people miss — storyboard" — about the RUN rather than the subject. Place every object you made on it: add_object_to_sketch for the task, the SimpleTable workspace, each saved chart, the subject sketch and the knowledge bundle (objectKind task | structured_workspace | structured_chart | sketch | knowledge_bundle), and add_databank_item_to_sketch for each of the five decks. Lay them left to right in the order you built them, leaving room between clusters. Then caption every one with add_shapes_to_sketch: a short text shape beside each saying what it IS, why this bowl needed it, and what I would do with it next — and arrows joining them so the reading order is obvious (research → tables → charts → decks). Someone who opens only this canvas should be able to explain the whole bowl without opening anything else. Finish with link_sketch_to_task and add_databank_item (kind sketch).
11. Write the run up on the card with add_task_comment (kind "status"): what you built, what surprised you, and a link to each object. Then regenerate_task_summary so the board reads well at a glance.

## When you are done

- Report back with the URLs: the task, the databank, the SimpleTable workspace, the charts, BOTH sketches (the subject and the storyboard), all five decks and the knowledge bundle (they live under https://hardlysimple.com).
- Tell me what you could not do, and what you would have wanted the platform to give you.

By the end you have a table of claims you can defend, each one dated and sourced, and a document that reads like it took a week.