Scaffold Exercises

/scaffold-exercises — Problem Set Scaffolder

Generate a graded problem set as two files: a clean student set (problems only) and a solution key (worked solutions + a one-line explainer per problem). Pattern imported from mattpocock/skills, adapted for economics teaching — the primary lens is graded coursework that mixes derivation, estimation, and code.

Input: $ARGUMENTS — a topic (e.g., "instrumental variables", "consumer theory", "quantile regression") and optional flags. See Flags.

When to use

• You have a lecture or reading and want a matching assignment with an answer key.
• You want a mix of problem types (derive, estimate, code) at a controlled difficulty, with solutions emitted separately so the student file stays clean.

Do not use this to grade submissions, auto-check answers, or build a timed exam — it scaffolds practice/graded material, not assessment infrastructure.

Problem types

If no dataset is supplied for an empirical problem, generate a small simulated one with a fixed seed (YYYYMMDD) so the answer key is deterministic and reproducible.

Workflow

Phase 0: Set topic, difficulty, counts, types (Pre-Flight)

Read any source material the user points at (lecture .tex/.qmd, a paper, a dataset header) and produce a Pre-Flight Report before generating problems:

## Pre-Flight Report — Problem Set

**Topic:** [topic]
**Source(s) read:** [lecture/paper/dataset — one-line takeaway each]
**Difficulty:** intro | core | advanced
**Counts by type:** analytical=N, empirical=N, coding=N  (total = `--count`)
**Dataset:** [provided path | simulated with seed YYYYMMDD | none]
**Learning objectives:** [2-4 bullets the set should exercise]

Resolve every flag here (interactive choices are gathered before generation, not mid-run). If the topic is too vague to write objectives, ask one clarifying question and stop. Otherwise proceed.

Phase 1: Generate problems

For each problem, write a number, a section heading, the prompt, and any data/notation it needs. Conventions:

• Motivation before mechanics — one sentence on why the problem is worth solving, matching create-lecture's pedagogy.
• Notation reuse — match symbols to the source lecture; never introduce a clashing symbol for an already-defined object.
• Difficulty calibration — intro checks one concept; core chains 2-3 steps; advanced requires a non-obvious insight or identification argument.
• Self-contained — each problem states its own assumptions; no "as in lecture 4" dangling references.

Phase 2: Generate worked solutions + explainers

For every problem, write:

1. A worked solution — full derivation, expected estimate, or runnable code (depending on type). Coding solutions must actually run; if Bash + R/Stata are available, execute the snippet and paste real output.
2. A "why this matters" explainer — 1-2 sentences linking the answer to the broader concept (the imported pattern's signature: every problem ships with a short rationale, not just a number).

Phase 3: Write student set + solution key

Emit two files (paths configurable; default under quality_reports/teaching/, beside /respond-to-eval's teaching plans. A new top-level directory such as exercises/ fails scripts/check-repo-hygiene.py once committed, unless it is added to that script's ROOT_ALLOW_DIRS):

• quality_reports/teaching/<topic-slug>_problems.md — the student set: sections, problems, any data, NO answers.
• quality_reports/teaching/<topic-slug>_solutions.md — the solution key: each problem restated, its worked solution, and its explainer.

The split is load-bearing: never leak a solution into the student file. With --no-solutions, write only the student set and stop.