An orchestrated multi-agent pipeline that designs evidence-based curricula using Claude Code. A central orchestrator coordinates five specialist sub-agents through a sequential pipeline, enforcing quality gates between phases and presenting results to the user at key checkpoints.

Built using the FRAME methodology and grounded in 12 instructional design frameworks with peer-reviewed evidence ratings.

User Brief
    │
    ▼
┌─────────────────────────────────────────────────────┐
│              ORCHESTRATOR (CLAUDE.md)                │
│  Collects brief → Delegates → Gates → Delivers      │
└──────────┬──────────────────────────────────────────┘
           │
           ├─→ Phase 1: Intake & Research
           │   Brief validation, domain + audience research
           │
           ├─→ Phase 2: Persona Builder
           │   3–5 pedagogical learner personas
           │       🛑 USER CHECKPOINT — confirm personas
           │
           ├─→ Phase 3: Curriculum Designer
           │   Objectives, strategies, modules, activities, assessments, slide specs
           │       🔵 USER CHECKPOINT (recommended) — review curriculum structure
           │
           ├─→ Phase 4: Persona Tester
           │   Walk-throughs, friction map, differentiation responses
           │
           └─→ Phase 5: Delivery Packager
               Design rationale, curriculum package, pre-flight checklist

The user provides a project brief (topic, audience, format, duration, delivery profile). The orchestrator validates the brief, checks for constraint conflicts, and then delegates to each sub-agent in sequence. Between every phase, a quality gate verifies the output before the next sub-agent begins. If a gate fails, the pipeline stops and asks the user how to proceed — it never silently papers over problems.

There are two user checkpoints: a mandatory checkpoint after Phase 2 (personas), because everything downstream depends on accurate personas, and a recommended (waivable) checkpoint after Phase 3 (curriculum design), where the user can review objectives, module structure, and slide specs before persona testing begins.

course-building-agent/
│
├── CLAUDE.md                    ← Orchestrator instructions (Claude Code reads this)
├── ARCHITECTURE.md              ← How it all fits together
├── README.md                    ← This file
│
├── skills/                      ← Sub-agent skill files (one per phase)
│   ├── 01-intake-research/
│   │   └── SKILL.md             ← Phase 1: domain + audience research
│   ├── 02-persona-builder/
│   │   └── SKILL.md             ← Phase 2: pedagogical persona generation
│   ├── 03-curriculum-designer/
│   │   └── SKILL.md             ← Phase 3: objectives, modules, activities
│   ├── 04-persona-tester/
│   │   └── SKILL.md             ← Phase 4: walk-throughs, friction map
│   └── 05-delivery-packager/
│       └── SKILL.md             ← Phase 5: rationale, package, checklist
│
├── references/                  ← Shared knowledge base (all sub-agents access)
│   ├── rules.md                 ← 16 rules — the pipeline's operating system
│   ├── evidence-base.md         ← Full citations and evidence strength ratings
│   └── uploads/                 ← Upload expert reference materials and user-supplied documents here
│
├── scripts/                     ← Helper scripts
│   └── council-research.py      ← Sends research queries to LLM Council
│
├── examples/                    ← Example inputs for testing
│   └── example-brief.md         ← 5 sample briefs (workshop, e-learning, Zoom, academic, micro-learning)
│
└── outputs/                     ← Generated at runtime (not committed)
    ├── brief.md
    ├── external-research/       ← Optional Perplexity/NotebookLM outputs
    ├── phase1-research/
    ├── phase2-personas/
    ├── phase3-design/
    ├── phase4-testing/
    └── phase5-delivery/

Open this directory as your project in Claude Code. The CLAUDE.md file is read automatically as the project instructions. Then give it a brief:

> Design a 2-day workshop on data visualisation for 25 mid-career marketers

The orchestrator handles delegation, gates, and checkpoints. It will ask you for any missing brief fields before starting.

Run a specific phase manually:

# Run just the research phase
claude --skill skills/01-intake-research/SKILL.md

# Run just persona building (after research is done)
claude --skill skills/02-persona-builder/SKILL.md

Copy the skills/ and references/ directories into your own project's .claude/skills/ directory. Reference them from your own CLAUDE.md.

Before every new course generation, the orchestrator checks whether outputs/ contains files from a previous run. Stale artefacts cause cross-contamination — sub-agents inherit workspace context and may ingest files from prior courses. The orchestrator asks you to delete or archive old outputs before proceeding.

The orchestrator collects the following before any work begins:

If any required field is missing or too vague, the orchestrator stops and asks for clarification. It does not guess.

Expert reference materials and user-supplied documents (audience data, existing content, prior analysis) should be uploaded to references/uploads/ before starting the pipeline. This is the single designated location for all user-provided inputs that Sub-Agent 1 consumes during the research phase. The orchestrator will verify the folder's contents and explicitly list each file when delegating to Sub-Agent 1.

Before designing anything, the orchestrator tests all constraints for mutual compatibility: format–activity conflicts, audience–complexity mismatches, duration–scope mismatches, facilitation–format mismatches, and technology–interaction mismatches. Conflicts are presented to the user with options to adjust, prioritise, or design a documented compromise.

The orchestrator offers several options for external research before the pipeline starts:

Four options are presented: (a) run external research manually via Perplexity Pro and NotebookLM Pro (25–35 min user effort), (b) skip and rely on built-in research only, (c) provide expert reference materials only, or (d) run LLM Council research (automated) — sends the 5 research queries to a local LLM Council that provides web research + 5-model deliberation + peer review + chairman synthesis, fully automated in 15–25 minutes. Option (d) requires the LLM Council backend to be running at localhost:8001 (see ~/Code/personal/llm-council).

If external research is chosen, the orchestrator generates ready-to-use prompt templates with placeholders filled from the brief, creates template files for each research prompt, and verifies every research file before proceeding.

Sub-Agent 1 validates the brief and produces two research documents: a domain research summary (7 mandatory sections covering practitioner workflows, tool features, anti-patterns, regional context, best practices, misconceptions, recent developments, and prerequisites) and an audience research summary (5 mandatory sections covering roles, prior knowledge, motivations, barriers, and success indicators).

Three quality gates check structural completeness, domain depth (catching research that is structurally complete but content-shallow), and cross-contamination.

Sub-Agent 2 generates 3–5 pedagogical learner personas, each with 6 required attributes (name and context, background, current Bloom's level, motivation, friction points, success criterion). Every persona set must include a sceptic/reluctant learner, a covert struggler, and a role outlier. Chain-of-thought reasoning appears before each persona, and four validation checks run after all personas.

After the quality gate passes, the orchestrator presents personas to the user and waits for explicit confirmation. The pipeline does not proceed on silence.

Sub-Agent 3 produces five files: Bloom's-tagged learning objectives, instructional strategies with framework citations and alternatives, a sequenced module structure with Merrill and Kolb audits per unit, activities/assessments with alignment verification and TPACK checks, and structured slide specifications for every presentation-style activity. A content depth self-audit scores every module on specificity, practitioner workflow mapping, and activity concreteness.

After the quality gate passes, the orchestrator presents a curriculum summary and offers the user a review checkpoint (waivable).

Sub-Agent 4 stress-tests the curriculum by walking each persona through every module. It produces narrative walk-throughs (with bias calibration weighting negatives 2×), a friction map scoring every persona × module cell on 5 dimensions individually (6 for async/self-paced), and differentiation responses for every Amber or Red cell using one of four response types. Every finding is framed as a hypothesis.

Sub-Agent 5 compiles three stakeholder-ready deliverables: a design rationale document (with evidence citations, strength ratings, and boundary conditions for every decision), a complete curriculum package, and a format-adaptive pre-flight checklist with a validation plan.

The orchestrator presents a summary of key design decisions, friction hotspots, what remains hypothesis vs confirmed, and recommended next steps for real-learner validation. The user decides whether to accept, revise, or iterate.

All sub-agents operate under 16 rules defined in references/rules.md. These are the pipeline's operating system:

Every transition between phases passes through a quality gate. Gates use a Hard Stop Protocol: when any check fails, the orchestrator stops immediately, states the specific failure with evidence, states what is needed to pass, and asks the user how to proceed. It does not resume until the user responds.

Additional safeguards include sub-agent input scoping (each sub-agent receives only its required files), cross-contamination scans at every gate (grepping for terms from prior courses), and a domain depth advocacy role where the orchestrator actively assesses whether research enables practitioner-level activities, not just structurally complete sections.

The pipeline draws on 12 instructional design frameworks, each rated for evidence strength (Strong, Medium, or Weak). Ratings are defined in references/evidence-base.md. Strong means peer-reviewed and replicated; Medium means widely accepted with limited large-scale testing; Weak means expert consensus or novel application. All Weak-rated elements are treated as hypotheses.

The pipeline adapts to any delivery format through its delivery profile system:

• Face-to-face workshops (single or multi-day)
• Live online sessions (Zoom/Teams)
• Self-paced e-learning (with or without voiceover)
• Academic semesters (lectures + tutorials + labs)
• Micro-learning (5–15 minute units)
• Blended formats (mixed sync/async)

Format-specific adaptations are applied throughout — from research depth and structural vocabulary to activity types, assessment formats, and friction dimensions.

Why sub-agents instead of one monolithic prompt? Each phase has different cognitive demands. Research needs breadth; persona building needs empathy and data synthesis; curriculum design needs structural thinking; testing needs adversarial thinking; packaging needs precision. Splitting into sub-agents gives each focused instructions and the right mental model.

Why quality gates? Without gates, errors compound silently. A flawed persona produces a flawed friction map which produces flawed differentiation. Gates catch problems at the cheapest point to fix them.

Why a user checkpoint after personas? Personas are the highest-leverage input in the pipeline. Everything from objectives to friction maps depends on them. A 5-minute review here saves hours of rework downstream.

Why 16 rules instead of general guidance? Testing showed that general guidance produces inconsistent results. Specific rules with framework citations produce auditable, repeatable designs.

This agent was built using the FRAME methodology:

1. Find evidence — 12 instructional design frameworks researched
2. Role & Rules — 16 rules derived from the research, with chain-of-thought requirement
3. Assemble — materials from a real workshop project used as test case
4. Measure & Modify — test run with 4 personas, 6-question critique, 7 improvements
5. Expand & Embed — product tested with 4 test cases (2 typical, 2 edge), 3 prompt edits applied