Event & Activity Planner — build plan | Institute of Imagination

How to read this. What follows is the end state, worth writing down so early decisions point the right way. It is not the first build. The first build is one specific event, the next one, narrow and not especially flexible. Everything general is extracted from that afterwards. See §6.

1Where things stand

Everything the Institute of Imagination delivers is built from a core set of activities, mixed and matched into programmes according to funding and available resources. The activities exist and the information about them exists. What is missing is a shape that lets it be combined, scaled and printed.

The first Monday board failed for a reason worth learning from. It was a publishing project aimed at an outside audience, so it needed polish before it was useful to anyone. Polish is expensive, so it stalled. This one has to be useful on the morning someone is packing boxes.

2The activity folder

One folder per activity, carrying everything about it. The existing guide PDFs move in rather than living in a parallel library.

core-activities/
  junk-bots/
    activity.md          metadata (front matter) + description, method, safety
    materials.csv        everything needed, one row per item
    images/              build photos, examples, finished pieces
    files/               existing guide PDF, printables
    outputs/             generated: page, guide PDF, materials sheet, card

components/
  scribble-bot-motor-unit/
    component.md         how to build one, minutes per unit, photo
    materials.csv        dc motor, battery pack, 2 × AA, off-centre cork

Metadata sits in the markdown front matter, so nothing can fall out of sync with the description:

---
id: junk-bots
title: Junk Bots
ages: 5-11
duration: 45min
group-size: 5
technique: junk modelling
programmes: [my-big-idea, tinkertubs]
requires: []          # activities that must run first, usually empty
---

Below the front matter the description is written in named sections rather than as continuous prose. Four are asked for, two are there if someone wants them. Keeping the required set small matters, because every field on the template is a reason not to fill it in:

## What it is          required   one paragraph, neutral, for anyone
## Steps               required   how to run it, in order
## Safety              required   hazards and mitigations
## Notes               required   what went well, what to watch for

## For children        optional   child-facing wording, if someone writes it
## Background          optional   the science or idea behind it

The two optional sections exist so that anyone who has already written that material has somewhere to put it. Nobody is asked to produce them.

Assemblies get their own folder

A scribble bot motor unit is not a material. It is a small bill of materials in its own right. Giving it a folder means it can be reused across activities without retyping, it carries its own build instructions, and it carries a build time per unit, which is what lets the make list total the prep hours.

No central materials catalogue, by design. A canonical parts master needs an owner, a naming convention and someone empowered to say no. That is governance, and governance stalls. Instead the index is derived: a script reads every materials.csv, collects distinct names and flags near-duplicates. Nobody has to maintain a catalogue before they can write an activity.

3Materials and the three lists

The categories in use at iOi vary along three independent axes, so a single "type" column cannot carry them. Recording them separately is what sorts things into the right output.

Type	Comes back?	Attaches to	Needs producing?	What it covers
Consumables	No, used up	Activity	No	Tape, sticks, glue, card
Assemblies	Sometimes intact	Activity	Yes, build time	Pre-built parts, own folder
Tools	Yes, counted back	Activity	No	Scissors, cutters, glue guns
Paraphernalia	Yes, one of each	Event	No	Wind tunnel, ramps, banners
Resources, adults	No	Event	Yes, printing	Workshop plans, risk assessments
Resources, children	No	Activity	Yes, printing	Printables, reference sheets

Basis is the column everything depends on

item,                     type,          qty,  basis,      unit,     notes
masking tape,             consumable,    1,    per group,  roll,
lollipop sticks,          consumable,    50,   per group,  sticks,
Tuf-Kut scissors,         tool,          1,    per group,  pair,
scribble-bot-motor-unit,  assembly,      1,    per child,  unit,     see components/
invention idea sheet,     print-child,   1,    per child,  A4 mono,
wind tunnel,              paraphernalia, 1,    fixed,      unit,     one only

Basis is one of per child · per group · per session · fixed. Without it the sums are silently wrong, and one wrong pack list is enough for people to stop trusting the output. Who supplies an item, iOi or the school, is a per-event override rather than a property of the activity.

A group is one set of shared materials, not a class and not a table. Whether an activity runs at one station or six changes nothing, because the event declares how many groups there are, either directly or as children ÷ group size. Defining it this way removes the ambiguity rather than resolving it, so the same activity works at a single table in a classroom and at six stations at a science fair without any change to its file.

Three outputs, not one

Three Year 5 classes of 30, running Scribble Bots in groups of five:

Item	Arithmetic	Total	Output
Scribble bot motor unit	90 children × 1	90 units · 6 hours build	Make
Masking tape	18 groups × 1	18 rolls	Pick
Tuf-Kut scissors	18 groups × 1	18 pairs, counted back	Pick
Invention idea sheet	90 children × 1	90 × A4 mono	Print

Every quantity shows its working, as in the table above. A bare number has to be taken on trust; a number with its arithmetic beside it can be checked at a glance. Costs nothing to produce, and makes a wrong figure easy to spot while there is still time.

4Events, numbers and stock

Three levels, each doing one job. Activity is the reusable unit. Programme is a named selection of activities assembled to fit funding. An event is a date, a venue and a set of activities with group counts, inheriting the event kit and allowing per-item overrides.

The event kit is the standing checklist that barely changes: risk assessments, registers, first aid, banners, signage, spare tape. Modelled separately because it does not scale with the number of children.

Numbers arrive in three states

Confirmed

Booked numbers known in advance. Used directly, printed plainly.

children: 90 · confirmed

Estimated

10 is the floor, not the guess. Estimates round up to the next whole ten, and say so wherever the figure appears.

34 children → packed for 40

Not applicable

Items that do not scale per child. Their basis is per group, per session or fixed, and no headcount is asked for.

basis handles it

Groups are computed, not entered, from the group size on each activity. An estimate must not look like a fact, so estimated quantities carry a visible marker through every output including print, and the event shows an unresolved-numbers warning until each figure is confirmed. Anything that cannot be resolved from the inputs is reported as an error rather than silently becoming one or zero.

Stock is not held in the system

A live count only stays true if everyone updates it every time, forever. Once it drifts it is worse than nothing, because people trust it and stop looking. The stock check happens visually at planning and is not optional. What the system contributes is the sheet you carry to the cupboard: what this event needs, grouped by type, with long-lead items at the top. Masking tape can be bought this afternoon; motors and micro:bits cannot.

Storage locations are deliberately not recorded. Where things live is unsettled until the office is reorganised, so a location column would be recording something that is about to change. It is also purely additive: adding it later reorders the pick list without altering the schema or anything already written. Nothing is lost by leaving it out now.

5How it works

A git repository holds canon, two skills do the mechanical work, and SharePoint receives a complete readable copy of both the source files and the finished documents.

Three ways an activity gets written

Activities are designed by people, at least two of them besides you, and nobody should have to use Claude to do their job. So authoring by hand is a first-class path, not a fallback.

By hand, on a template

A Word document with headings that match the named sections, and a table for materials. No software to learn, no account needed. Filled in and handed over. This is the primary path for the people designing activities.

Build this early

Through me

The add-activity skill takes a filled template, an old PDF, a photo or a conversation, converts it into the folder and runs the validator before committing.

Conversion and legacy intake

A form, later

Back on the table, but not yet. Worth building once the schema has stopped moving and if the template proves too loose in practice.

After the first event

The template is the cheapest thing in this project and possibly the most valuable. It costs an afternoon, requires nobody to change tools, and it shapes what arrives so that conversion is nearly mechanical. It should be built as soon as the section names are settled, before any code at all.

The second skill, plan-event, takes the event and its numbers, reads the activity folders, runs the calculator and produces the three lists.

Two things are deliberately taken away from the language model. A validator checks every file against the schema before it is committed, so per group cannot become per-group next week. A calculator does all arithmetic from the CSVs. Code does the sums; the skill assembles what goes into them. These are the two jobs a model is worst at and they are both load-bearing.

A skill rather than a prompt because a skill is a folder: it carries those scripts, it is versioned so corrections accumulate, and it loads automatically rather than being remembered and pasted. The schema lives in the activities repository, not in the skills, because it describes the data rather than the workflow. Both skills read one definition.

The workflow

Renders: an option, not a requirement

Writing in named sections means a render is just a selection of sections plus a layout. That keeps the door open cheaply, and nothing more is being committed to.

For the next couple of projects, only the free ones get built: the same words filtered and laid out differently, which costs nothing per activity once the template exists. Those are the full guide, the bare minimum sheet, and the materials list.

Everything else stays a possibility. Cards, magazine pieces, child-facing versions and whatever else turns out to be useful are undefined and not being designed for. The only thing being done now is not painting them out: because the source is sectioned rather than continuous prose, adding one later costs a template rather than forty rewrites. If none is ever wanted, nothing has been wasted.

Worth noting the difference for whenever that day comes. Selections are free. Anything that needs different words for a different reader, a child-facing version most obviously, is a rewrite rather than a filter, so it has to be written by a person into its own section. That is why ## For children exists as an optional section and is not generated.

How many documents

Level	Written or gathered	Generated
Per activity	4 — `activity.md` · `materials.csv` · `images/` · `files/`	3 for now — full guide · bare minimum sheet · materials list. Further renders cost a template each, if any are ever wanted.
Per component	2 — `component.md` · `materials.csv`	1 — build sheet
Per event	1 — `event.md`	3 — pick list · make list · print list
Shared, whole repo	2 — `schema.md` · `event-kit.csv`	1 — derived materials index

What SharePoint holds

The activity folders complete: the source files and the finished documents. That is what makes it worth browsing rather than merely a backup, because the PDF someone actually wants is sitting in the folder next to the files it was made from.

It must be read-only. SharePoint syncs to everyone's Finder, so if people can edit the mirror the copies diverge silently and there is no way to tell which is right. Set the permissions rather than relying on a convention. That costs nothing SharePoint was wanted for: what you wanted was findability and not being locked in a closed garden, and a complete read-only copy gives both. Plain folders, plain CSVs, plain markdown, ordinary PDFs. A backup you can only open with the thing that broke is not a backup.

The read path already runs here. makerspace-planner.pages.dev is git-connected on the iOi Cloudflare account and auto-deploys on every push. Writing to SharePoint needs Microsoft Graph, an Entra app registration and admin consent, which is measured in weeks. So the mirror is a scheduled job, never part of the critical path, and everything works before those permissions arrive.

6What we build, in phases

Build one event, then extract the pattern. Not a system that could handle any event: that one, with its real activities, real numbers and real materials. Whatever needs hard-coding gets hard-coded. And because an event is assembled from activities, the activities come first — the event cannot be built until the folders it draws on exist.

This is the approach that produced the best document in the repository. DAY-OF-PLAY-EVENT-TEMPLATE.md is genuinely reusable because Marner was delivered first and the pattern was lifted out afterwards. Written beforehand it would have been guesswork. Written after, it knows that breaks run 20 minutes rather than 15, that volunteers without DBS need escorting, and that a technique can be published and then dropped because the materials could not be prepared. None of that was predictable.

The first event is the Science Fair at East London Mosque, Saturday 29 August. That is four weeks from now and most of the team is on holiday for part of it, so the working window is shorter than the calendar suggests. It is similar to an earlier school workshop, and the workshop plans and Monday boards for that event already exist, which makes it a starting point rather than a blank page. Everything below phase 2 waits until after 29 August.

Now — the template. Agree the named sections and produce the Word template for activity design. An afternoon's work, no code, and it is what lets the other two designers contribute without touching any of this. Do it first because it shapes everything that arrives afterwards.
Phase 1a — the Science Fair's activities. Build a folder for each activity the fair runs, starting from the earlier school workshop plans and Monday boards. Schema drafted as we go rather than up front. Output: real folders, real materials, validated.
Phase 1b — the event itself. Produce its three lists for real. Fixed numbers, fixed activities, no configurability. Success is that the fair is packed from these sheets rather than from the usual scramble.
Phase 2 — extract. Revisit what was hard-coded and ask what it should have been. Assumptions become columns, one-offs become fields, awkward cases become the schema. Short, and done in early September while the event is fresh.
Phase 3 — the two skills. Formalise what was done by hand into add-activity and plan-event, with the validator and calculator scripts. By now the schema is evidence rather than guesswork.
Phase 4 — widen and render. Bring the remaining activities in from the Monday exports and the SharePoint folder, and build the renderers: one template per view, the print stylesheet. Output: the whole catalogue has pages and printable sheets.
Phase 5 — publish, mirror, and decide on the form. Activity pages onto the wiki behind Access, the SharePoint mirror once Graph permissions land, links from the Monday boards. And an honest look at whether the Word template was good enough or whether a form is worth building.

Phase 0 runs alongside, not first. Migrating the wiki to the iOi Cloudflare account, confirming the Access gate and starting the Entra request are all still necessary, but nothing in phases 1 or 2 depends on them. With four weeks and a holiday, publishing waits and the Science Fair gets built against local files.

Phase 4 does double duty. Rendering markdown into house-style HTML is already an outstanding task in PROJECT-STATUS.md for the wiki itself. Same machinery, built once. It also settles the open question in stocktake.md §8: activity pages need images, toggles and a print stylesheet, so the wiki has to use the design system rather than plain markdown rendering.

Print rules to fix early

From the notes already in CLAUDE.md: concepts, methods and instructions must not break across pages, but material tables should be allowed to break with a repeating header, because a long list forced onto one page is worse than a split one. page-break-inside: avoid backfires on blocks near page height, bumping them to a fresh page and stranding the heading. Print renders the chosen view only, never the screen toggles.

7What I need from you

Most important: the earlier school workshop. The Science Fair is similar to it, so its workshop plans and Monday boards are the starting point for phase 1. Everything that exists for that event is worth more right now than anything else on this page.

To start

The earlier school workshop plans and its Monday boards. The direct precedent for the Science Fair.
The Science Fair brief — whatever exists. Venue, timings, expected numbers, activities planned or shortlisted, who is available given the holidays.
Monday board 1 export (CSV) — the comprehensive activity list. The project it was built for stalled, but it is the most complete inventory that exists.
Monday board 2 export (CSV) — activities with materials. The duplication is fine, I need to see it.
The Monday event packing template — the tool is bad but the template encodes real knowledge about what has to be packed.
SharePoint core activities folder, as-is. The closest thing to a working system today, so the new shape has to accommodate it.
One real risk assessment — it defines the shape of a common resource, which is what the event kit is built from.
Anything an activity designer has written recently, in its natural state. It tells me what the Word template has to accommodate.

Would make it noticeably better

An assembly described properly — the scribble bot unit or similar, written as you would explain it to someone building forty, plus a realistic minutes-per-unit figure.
Any pack list actually carried at a recent event, however scrappy. The gap between the official list and the real one is where the useful information is.
A workshop plan, so I can see what gets generated per event versus what carries forward.
A programme definition — how activities group into My Big Idea, the Power of Play, TinkerTubs, and how funding drives the selection.
Delivery constraints — box sizes, vehicle, courier or carried. Determines whether the pick list needs to group by box.

Nothing needs tidying first. Messy exports are more useful than cleaned-up ones, because the mess shows where the real edge cases are. Sorting it out is the job, not the prerequisite.

8Open questions and risks

Settled

Question	Answer
Material lists by age group	They do not vary. One folder per activity, quantities scale per child. No variants needed.
Several stations at once	Possible. Resolved by defining a group as one set of shared materials and letting the event declare how many.
Prerequisites	Possible but rare. A `requires` field exists in the front matter and stays empty until something needs it.
Packing by box	Not always. Box grouping is an event-level option rather than a global assumption.
The activity card, and renders generally	Optional and mostly undefined. Only the free renders get built for the next couple of projects. Sectioned source keeps the rest possible without designing for it.
Who authors	At least two other designers, working by hand. The Word template is the primary path; a form stays on the table for later.

Still open

Question	Why it matters
Default group size	Unknown, and it does not need answering in the abstract. I will derive it from the earlier school workshop plans and put a figure in front of you to correct.
Are the section names right?	What it is · method · for children · safety · background · notes. These become the Word template's headings, so they are worth ten minutes now. Anything missing that a designer would naturally write?
Realistic working days before 29 August	Holidays make the calendar misleading. Determines whether phase 1 covers all the fair's activities or only the ones that need the most preparation.

Risks

Risk	Mitigation
Publishing before the gate is on	The guides site was verified on 27 July as still on the personal Cloudflare account and serving without the intended password. Internal resources cannot publish until Access is genuinely in force. Phase 0, before anything else.
Two copies drifting	Already happened once with the design system. One-way flow, and SharePoint permissions set to read-only rather than relying on a convention.
Schema drift from the model	The validator runs before every commit. Wrong column, unknown basis or a near-duplicate material name is rejected.
Silent arithmetic errors	The calculator is a script, not a judgement. Basis is mandatory. Every quantity prints its working so a wrong figure is visible.
Polish before usefulness	The failure mode that stalled the first Monday board. One event, used for real, before anything is widened.
Depending on one person	Structural while skills only run in your Claude. Mitigated by the SharePoint copy being complete and readable without any of the machinery, and by the seats case.
The correction loop not happening	Without it the catalogue ages into fiction, as the institutional documentation already has. Make it one line on the pack list itself.