AI workflow for creating exercises

Context

As part of my work on Mathia at Prof en Poche, I had the opportunity to build 4 different game templates covering fractions, geometry, and quantities and measurement. These templates were designed by learning designers through specification documents. These documents contained:

• a short description of the game and each of its modes;
• every variant of the exercise for the three levels, ages 9 to 12 (for example, no thousandths for the youngest pupils);
• the learning paths to attach;
• personalised feedback to show depending on the mistake the pupil made.

Exercises and learning paths had to be created in the WordPress back office. A single template can mean around fifty exercises, which is very slow by hand because every action comes with a loading time. There were a lot of exercises to produce in a short time, so I designed a workflow with Claude Code to save time, from reading the document to importing into WordPress.

Approach

Skills, agents and workflow

The workflow has three levels, each with its own role:

• Skills are reusable knowledge, loaded only by the agents that need it: the WordPress import syntax, or the curriculum and teaching rules for each level.
• Agents are roles, each with its own context, model and skills: specification, import, development, code review and teaching review.
• The workflow orchestrates everything: the order of the steps, what runs in parallel, and the points where I check the work myself before moving on.

• Agent
• Skill
• Human checkpoint

Learning designers' document

↓

Specification agentOpus

↓

✓Specification approval

Single reference for the rest of the workflow

↓

Content

↓

Import agent

• WordPress import

↓

2 XML files

Exercises and learning paths

↓

✓Review and manual import

Code

↓

Developer agents×N

In parallel, then tested against the user stories

↓

Code reviewer

Project Claude rules

Teaching reviewer

• Teaching

The specification as a contract

Before developing the template and its variants, a first agent writes a complete specification (plan): a summary of the game and the steps to follow, such as creating every teaching variable of an exercise (for example, the proportion of squares or triangles in a geometry exercise) before importing them into WordPress.

This specification lets me run a first check that the document has been understood and that the plan to build it holds up. It also clears up every uncertainty in the document and settles conflicting instructions. Once approved, the specification, not the original document, is the reference for every agent that follows.

I chose an Opus agent for this phase: the whole rest of the workflow builds on this specification. A small mistake at this point can weigh heavily on everything after it and take several rounds of fixes.

Importing into WordPress

Rather than creating exercises by hand, I went with WordPress's built-in import tool. So that Claude could understand the import syntax for exercises and learning paths, I first exported these entities to provide an example of each item (exercise and learning path), along with an explanation of each field. That became the WordPress import skill.

Once the specification is approved, an import agent formats the exercises and learning paths as XML files the import tool understands and produces two files, which I check before importing. The import stays manual on purpose: it forces a review, where a WordPress MCP would have pushed everything straight through.

Development and reviews

A few developer agents then run in parallel on the independent tasks defined in the specification. When they finish, they test that the feature meets the specification's user stories. Two review agents then take over:

• a code reviewer checks that the code follows the project's Claude rules;
• a teaching reviewer, equipped with the teaching skill, makes sure the questions shown to the pupil match the curriculum for their level and, where possible, fixes generated content that has no teaching value.

Outcome

The workflow's results weren't very convincing at first, so I iterated on its content (for example, adding the teaching skill). These additions improved the output: fewer fixes after each run of the workflow and questions better suited to each pupil's level. It isn't perfect yet, but each recurring problem points to a specific next step: a skill to complete or a check to add.

Takeaways

• The specification is where a mistake costs the most: that's where I put the most capable model and my first checkpoint.
• Keeping human checkpoints at key points, rather than automating everything, forces a review that catches what the agents miss.