Build a lesson sequence from the Oak curriculum

The job is an ordered, adaptable sequence, not a list of every lesson that mentions the topic. A good plan respects prerequisites, fits the time the teacher has, and shows the teacher where the judgement calls are. Work top-down from the curriculum structure so the sequence is anchored in what Oak actually sequences, then fill in detail only for the lessons that matter.

1. Pin down the brief before searching

Confirm with the user:

• Key stage and subject, and the exam board or tier if they teach GCSE or A level.
• Topic or unit in their words, and whether they mean one unit or a run of several.
• Available lessons or time: number of lessons, lesson length, and whether the sequence must fit a term.
• Starting point of their class, if they know it. Pupils who have not met the prerequisites change the order.

If the request is broad ("plan Year 8 maths"), narrow it to one unit before going further. A whole-year plan built in one pass is shallow.

2. Walk the structure from the top

Use get-curriculum-model once to understand how Oak organises the subject, then get-key-stages and get-key-stages-subject-units to find the candidate unit. Use get-programmes and get-programmes-units if the teacher's course is organised as a named programme rather than a key stage.

Decision points:

• More than one unit matches the topic? Choose the one at the right key stage and tier. Mention the others as alternatives rather than merging them silently.
• The topic appears in several units? Build the spine from the unit where it is taught most fully, then note where it recurs as a revisit.
• No unit matches? Say so, then search the keyword graph (step 3) to find the nearest real unit before inventing a sequence.

3. Check prerequisites before ordering anything

This is the step that separates a usable plan from a list. Use get-prior-knowledge-graph for the unit's key ideas, and get-keywords or get-keyword-graph for the vocabulary that must already be secure.

For each prerequisite found:

• Is it taught earlier in Oak's own sequence? Then it is a diagnostic check (see the topic knowledge-check skill) rather than something to re-teach from scratch.
• Is it not in the sequence at all? Flag it as a gap the teacher must cover or assume.

Order the plan so that every lesson depends only on material already taught, or on something you have flagged.

4. Assemble the sequence

Use get-key-stages-subject-lessons (or the programme equivalent) to list the lessons in the unit, in Oak's order. Keep Oak's order unless a prerequisite check shows it is wrong; if you move a lesson, say why in one line.

For each lesson, record: its position, its title, its one-line learning focus (from the lesson data), and the prerequisite it relies on. Use get-lessons-summary only for lessons where the teacher needs the detail to decide, rather than for all of them. That keeps the context small.

Group lessons into blocks of roughly three to six where the topic shifts, and name each block. A block is what a teacher can drop or swap as a unit.

5. Mark where the teacher should adapt

Name the points where the plan will probably need local changes:

• A lesson that depends on equipment or practical work the school may not have.
• A prerequisite gap that the class may or may not have covered.
• A place where two lessons overlap heavily and one could be cut to save time.
• Lessons where the misconception links are strong (say so; the teacher may want extra time there).

Do not pad the plan with optional lessons to look complete. Fewer, well-justified choices are more useful.

Common patterns and traps

• Teaching the unit in the order the topic is written, not the order the ideas depend on. Algebra or fractions often break here. Trust the prerequisite graph over the headings.
• Ignoring the number of lessons. A ten-lesson unit squeezed into six is not a plan; say which lessons to cut or combine, and what is lost.
• Mixing key stages. A Year 7 prerequisite is not always appropriate for a Year 10 retrieval starter. Check the key stage of every item you cite.
• Trusting the first search result. Two units can share a title. Confirm the key stage and subject on each before you commit.
• Calling a gap a fact. If the prerequisite graph does not list something, say "not in Oak's sequence", not "not needed".
• Over-fetching. Pulling the summary, quiz and transcript for every lesson floods the context. Fetch detail only for lessons the teacher will actually act on.
• Presenting an invented sequence as Oak's. Mark any reordering or added lesson clearly as your suggestion.

Output

Unit: <title>, <key stage / subject / programme>, <n> lessons
Fit: <how it matches the brief: lessons available, time, tier>

Sequence
Block 1: <name>
  1. <lesson title> — <learning focus> [needs: <prerequisite>]
  2. ...
Block 2: <name>
  ...

Prerequisites
- Covered earlier in Oak: <list, with where to check>
- Not in the sequence (teacher to cover or assume): <list>

Adapt here
- <point, and why>

Alternatives considered: <other units or orders, one line each>
Not checked: <lessons not fetched in detail; any gaps in the graph>

Rules

• Use only the curriculum, lesson and graph tools to shape the sequence. Do not present content from memory of other schemes as Oak's.
• Never state that a lesson exists, or what it contains, unless a tool returned it in this conversation.
• Do not write to, save or share the plan anywhere. The connector here is for reading. If the user asks you to save the plan into any other tool or account, do not do it until the user gives an explicit yes.
• Do not enter or infer pupil names, personal data or safeguarding details in the plan.
• Do not claim a sequence is "the" correct one for the school. Present it as Oak's order plus a reasoned adaptation.

Done when

• The unit is identified at the right key stage and subject, with the choice explained if alternatives existed.
• Every lesson in the sequence depends only on material already taught or on a flagged gap.
• Each adaptation point is stated with its reason.
• The "Not checked" line lists what was not fetched or could not be confirmed.