Designing a Course with an AI Co-Designer

How I Used Claude Code to Translate a 16-Week In-Person Course into a 4-Week Intensive Online Format

Author

Davi Moreira

Published

May 11, 2026

Modified

May 20, 2026

WarningWork in progress: read it as a field journal, not a finished manual

This page documents a course that is not yet finalized. The Summer 2026 offering of QM47400 (Predictive Analytics) runs from May 18 to June 12, 2026, and I am still iterating on notebooks, video guides, quizzes, and the midterm. Treat what follows as an honest, mid-stream account of working with Claude Code as an AI co-designer: what has worked for me, what cost me time, and what I would tell a colleague before they start.

NoteHow this page was written

True to its subject, this page was itself drafted with the help of Claude Code, the same tool I am describing below. I outlined the structure I wanted, dictated the lessons in my own voice, and asked Claude to produce a first pass that I then revised until it sounded like me. So the recommendations and judgments are mine, and the prose you are reading is itself an example of the workflow it describes.

1 Who this page is for

This page is written for faculty colleagues, especially those building or revising a course, who are curious about whether AI coding assistants are useful for teaching material and not just for software engineering. If you have ever maintained a syllabus in plain text, edited slides as code (Beamer, Quarto, R Markdown), or even just kept course files in a Git repository, the workflow below will feel natural. If you have not, this page will give you a sense of what becomes possible if you take the small step of putting your course material under version control.

I am sharing this in the same spirit as Pedro H. C. Sant’Anna’s My Claude Code Setup, which is, frankly, the page that nudged me to write my own. Where Pedro’s guide is the polished playbook of a research economist building an end-to-end agent system, mine is a teaching-oriented field report on what an undergraduate business-analytics course actually looks like when an AI is sitting beside you while you build it.

2 The starting point

I did not begin this project from zero. The 2025 Fall version of QM47400 was already a full-semester course (15 weeks, in-person, with quizzes, a Kaggle case competition, and a poster session). Three properties of that existing course mattered enormously when I brought Claude Code into the picture:

  1. The course website was already a Quarto project. index.qmd, syllabus.qmd, and schedule.qmd are plain-text files rendered to HTML. The whole site lives in docs/ and is served by GitHub Pages.
  2. All other artifacts were already plain-text-friendly. Slides were Quarto/RevealJS source, notebooks were .ipynb JSON, and quizzes, exam, and project rubrics were Markdown.
  3. The repository was already on GitHub with a sensible structure (notebooks/, _syllabus/, _quizzes/, _midterm_exam/, _lecture_notes/, lecture_slides/, brightspace/, and so on).

If your course is in a similar shape, meaning files you can read in a text editor and organized in folders, the workflow below is directly transferable. If your course currently lives entirely in PowerPoint decks, Word documents, and the Brightspace or Canvas authoring UI, your first investment should be moving the source-of-truth artifacts into plain text. That is the precondition that makes an AI co-designer useful.

Dimension 2025 Fall (semester, in-person) 2026 Summer (4-week intensive, online)
Duration 15 weeks 4 weeks (20 business days plus a Day 0 launchpad)
Mode In-person, on campus Fully online
Daily student engagement Standard 3-credit class plus outside study About 112.5 minutes per day
Synchronous time Regular class meetings One Zoom session per week, Fridays 10:30am to 12:00pm EST
Primary instruction medium Live lectures and slides Micro-videos (≤12 min each) plus Colab notebooks
Pedagogy Lecture, in-class examples, homework Concept, Demo, PAUSE-AND-DO practice, Solution discussion
AI assistance for students Optional, ad hoc Built into the workflow via Gemini in Colab (“vibe coding”: draft, verify, document)
Number of lessons One per class meeting 21 notebooks (one per business day plus a Day 0 launchpad)
Assessment mix Attendance, participation, quizzes, homework, Kaggle case competition, final project and poster Quizzes, daily PAUSE-AND-DO, midterm casebook, project milestones, final case competition, peer review
Capstone Poster at the Undergraduate Research Conference Executive narrative plus a project case video
Topic coverage Linear regression, classification, resampling, regularization, trees and ensembles, time series, deep learning, unsupervised learning The same predictive arc compressed into 20 days; deep learning and unsupervised learning are trimmed to make room for explicit CV-first evaluation, calibration, fairness, and a deployment-and-monitoring notebook
Source-of-truth files Slides, syllabus, homework PDFs Notebooks, video guides, brightspace pages, quizzes, exam, all as plain text
TipYou do not need to be a developer

I am comfortable on the command line and with Git, and that lowered my activation cost. But everything I describe below can be done in natural language, which means telling Claude what you want, reviewing what it produced, and asking it to commit the change. You do not need to type a single Git command yourself.

3 The honest tradeoffs

Before the recommendations, three lessons I wish I had taken seriously earlier.

3.1 You will spend more time than you expect

Translating a 15-week course into a 4-week intensive looks, on paper, like compression. In practice it is a redesign. Cognitive load, daily engagement of roughly 112.5 minutes per day, notebook pacing, the order in which concepts appear, the difficulty curve from EDA to gradient boosting in fourteen business days: none of that survives the move unchanged. The CONVERSATION_LOG.md in this repo has 16+ working sessions logged across roughly four months. The AI sped up production, not deliberation. I still had to decide what to teach, in what order, and at what depth. The minute I tried to skip that step and let the assistant just propose a plan, the plan was bland and had to be redone.

3.2 Flexibility is a double-edged sword

Claude Code is extremely flexible. It will adopt almost any convention you ask it to. That is wonderful, because the tool conforms to your course rather than the other way around. But it also means there is no obvious right way to use it, and the time-to-effectiveness is dominated by figuring out your own style. Expect to throw away your first two or three workflows before settling on one that fits.

3.3 Where the AI really shines: structured artifacts at scale

The cautions above are real, but they are not the whole picture. There is a category of work where the assistant is unambiguously better than I am, and it is worth naming because it is the easiest first win for a colleague who has not yet tried this. Generating structured, schema-compliant artifacts at scale is exactly that kind of work, and the example I lean on most is Brightspace-ready quiz CSVs.

Brightspace’s Question Library accepts CSV uploads in a specific column format. Once I showed the assistant the format (one example file in the repo is enough), it can generate dozens of well-structured multiple-choice and short-answer questions from a short topic brief, all in the exact CSV shape Brightspace expects, with distractors that are pedagogically plausible rather than obviously wrong. I review and edit, I do not draft from scratch. What used to be an hour of formatting per quiz is now ten minutes of review. The same pattern works for grading rubrics, casebook scaffolds, peer-review forms, and any other artifact whose value lies in being uniform, complete, and machine-uploadable.

3.4 Think of the AI assistant as a rotating TA/RA team

This is the mental model that finally made the workflow click for me. Claude is the best teaching assistant I have ever had: fast, patient, indefatigable, and well-read. But it is not the same TA in every session. Tone drifts. Default formatting drifts. Last week’s good habit can quietly become next week’s regression. The implication is simple and load-bearing:

If you would tell a new TA something on their first day, write it down where the next TA will see it.

Everything in Recommendations below is a consequence of taking that one sentence seriously.

4 Recommendations

4.1 Treat CLAUDE.md as the project’s constitution

CLAUDE.md is the file Claude Code reads at the start of every session. Anything written there is in the assistant’s context by default, like a standing handout you would give every new RA on day one. My CLAUDE.md has grown from a few paragraphs to a structured document with:

  • Project mission (course code, run dates, pedagogy).
  • A small table of “see also” reference files, so the constitution stays slim and detailed material lives elsewhere.
  • Critical rules with a 🚨 prefix that flag the regressions I have actually been bitten by.
  • Style guidelines as a table (random seed 474, train/val/test split 60/20/20, figure size, money in markdown cells, emoji vocabulary).
  • Anti-patterns drawn from real prior mistakes, not from hypotheticals.
  • A session-end checklist.

The most valuable parts are the critical rules and anti-patterns, because they encode lessons the assistant cannot derive from the code. Two real examples from this repository:

NoteExample rule: voice and audience in student-facing content

The student notebook is read by students, not by instructors who then teach it. Every sentence in a student-facing cell, including Gemini prompts and “After running, verify” checklists, must be written to the student, never about the student, and never to the instructor.

This rule exists because in early sessions the assistant drifted into instructor-voice phrasings like “… so students see the per-class breakdown.” The student is the reader, so the phrase is wrong. After the rule went into CLAUDE.md, the regression effectively stopped. I also wrote a small script (scripts/voice_check_guides.py) that grep-audits modified files, so the constitution is enforced and not just declared.

NoteExample rule: CV-first evaluation and test-set lock

From notebook 9 onward, all model-performance claims come from cross-validation. Before notebook 14, the test set is locked and no model evaluation touches it. Notebook 14’s “Opening the Locked Test Set” ceremony is the one and only authorized test-set opening in the entire course.

This is not a style preference. It is the pedagogical spine of the course. If the assistant generates an accuracy_score(y_test, ...) call in notebook 11 because it is the obvious thing to write, notebook 14’s payoff disappears. Encoded as a CLAUDE.md rule plus a runnable audit (scripts/audit_cv_first.py), the rule is durable across sessions.

The pattern is the same in both cases: write the rule down, then encode it as a check the assistant can run on demand.

4.2 Keep a source .md file for every artifact

This is the recommendation I would give first if a colleague asked me for one thing only. Every kind of artifact in the course has a corresponding plain-text “source” file in the repo:

Artifact Source-of-truth file(s)
Notebooks (student-facing) notebooks/nbNN_topic_student.ipynb
Notebooks (instructor, with solutions) notebooks/nbNN_topic_instructor.ipynb (gitignored, local-only)
Video lecture guide (script and timestamps) video_guides/NN_video_lecture_guide.md (gitignored)
Brightspace content pages brightspace/NN_topic.md
Quizzes _quizzes/2026Summer/
Midterm exam _midterm_exam/2026Summer/
Notebook to NotebookLM podcast transcript _notebook_lm/<basename>.md (auto-generated, gitignored)
Course map and rationale MGMT47400_Online4Week_Plan_2026Summer.md
Implementation plan claude_course_plan.md
Conventions and decisions DECISIONS.md
Troubleshooting playbook TROUBLESHOOTING.md
Session-by-session history CONVERSATION_LOG.md

Two benefits compound here. First, the AI can read and edit any of these directly. There is no copy-paste from a web UI, no screenshots, no “look at this PDF.” Second, when a quiz question changes, you can ask the assistant to propagate that change to the matching brightspace page, to the relevant video-guide section, and to the schedule. Plain-text source files are what make that propagation possible.

TipWhat goes into a source .md file

Not just the artifact itself, but also the rationale for it. Each brightspace page in this repo begins with what the student is learning today, why this matters, and how this connects to yesterday and tomorrow. That framing is for me and for the assistant, not only for the student. When the assistant has the rationale, it edits the artifact in ways that preserve intent.

4.3 Adopt an instructor-first notebook workflow

Notebooks are the workhorse of this course (21 of them, roughly one per business day). The convention I settled on after a lot of failed alternatives:

  1. Edit the instructor notebook first. nbNN_topic_instructor.ipynb is the source of truth and contains all solutions inside cells marked with INSTRUCTOR SOLUTION. This file is gitignored and never leaves my machine.
  2. Generate the student notebook from it. Copy the instructor file, strip every cell tagged with INSTRUCTOR SOLUTION, update the Colab badge URL, and commit only the student file.
  3. Update the matching video guide in video_guides/, which is also gitignored. Speaking prompts, cell references, and timestamps live there.
  4. Render the Quarto site and commit docs/ so the website actually reflects the change.

This sequencing matters because it gives the assistant a single, unambiguous answer to the question where do I write the next edit? Without it, the assistant has been known to edit the student file directly, lose the solution version, and force me to reconstruct it from memory. With it, the workflow is mechanical.

One more piece of sequencing surprised me, and I think it generalizes. I can only record the lecture videos after the notebook is genuinely finalized, because the camera captures whatever is on the screen and any later edit forces a re-take. So before I press record, I read the notebook end to end and walk through the matching video-guide narrative one more time. That last pass catches anything that drifted while I was working on adjacent notebooks, and it ensures the notebook, the guide, and the recording all say the same thing. If you skip the pass, the recording will reveal the disagreement and you will lose an hour.

4.4 Encode invariants as runnable scripts

The most reliable rules in this project are the ones I made the assistant enforce on itself before committing. Two examples, both real, both in scripts/:

Notescripts/audit_cv_first.py

Scans every notebooks/*_student.ipynb for model-evaluation uses of X_test and y_test that violate the CV-first rule. The only acceptable hits are the two authorized openings in notebook 14 (the test-set ceremony) and notebook 18 (the Kaggle-submission demo). Anything else is flagged and must be fixed before commit.

Notescripts/voice_check_guides.py

Audits video-guide markdown for instructor-voice violations inside blockquotes only (the read-aloud sections), while leaving wrapper prose untouched. It flags students (as a third-party noun), the instructor, on camera, and speaking prompt, but whitelists Student's t because that one is the statistical test, not a regression.

Why this matters: a rule that lives only in CLAUDE.md depends on the assistant remembering and applying it. A rule that exists as a script gets run every commit, regardless of which “TA” is on shift today. The conversation about voice does not have to happen again. The audit either passes or it does not.

4.5 Automate the boring parts with hooks

Claude Code lets you configure shell commands to run automatically after certain tool calls. I use this for one thing right now, and it has paid for itself many times over. The project’s .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write|NotebookEdit",
        "hooks": [
          {
            "type": "command",
            "command": "f=$(jq -r '.tool_input.file_path // .tool_input.notebook_path // empty'); case \"$f\" in *_instructor.ipynb) bash \"$CLAUDE_PROJECT_DIR/scripts/sync_instructor_md.sh\" \"$f\" >&2 ;; esac"
          }
        ]
      }
    ]
  }
}

Translation: every time the assistant edits an instructor notebook, a shell script regenerates the corresponding _notebook_lm/<basename>.md file so NotebookLM (Google’s research and podcast tool) can ingest the latest version automatically. I never have to remember to export to markdown for NotebookLM, because the hook does it on every edit. This is the same idea Pedro Sant’Anna documents extensively in his guide.

4.6 Log decisions, not just changes

Git remembers what changed. It does not remember why. I keep three companions to the commit log:

  • DECISIONS.md collects short entries explaining load-bearing choices (random seed, split ratios, evaluation spine, narrative voice). When I or the assistant catch myself second-guessing a choice three weeks later, this file ends the debate.
  • CONVERSATION_LOG.md is a session-by-session journal, appended at the end of each working session. Sixteen-plus sessions in, this is where I look first when I have forgotten what we tried in a prior round.
  • TROUBLESHOOTING.md lists the failure modes I have actually hit: Quarto rendering glitches, GitHub Pages caching, Colab MathJax breaking on unescaped $ in money strings. Future-me reads this so future-me does not re-debug it.

4.7 Skills: a venue I have not explored yet (but you might)

Claude Code supports user-defined skills, which are reusable, invocable workflows (often registered as slash commands) that bundle a prompt, a sequence of steps, and access to specific tools. I have not built any skills for this course yet, because the project’s velocity has been dominated by writing notebooks and rendering the site rather than by automating my own meta-workflow. That said, every time I find myself typing the same opening instructions into a session for the third time, I am one step closer to needing a skill, and I plan to invest there in the next iteration.

If you are starting a new project from scratch, skills are likely a high-leverage place to invest early. For a domain-specific catalog of how academics are using them, I recommend the Claude Code Skills for Academics PDF (listed in the references below), which collects concrete patterns by discipline and is the cleanest starting point I have found.

5 Examples from this repository

Concrete is more useful than abstract. Three patterns from this course, named so a colleague can lift them.

5.1 The Pause-and-Do block

Every student notebook is organized around the rhythm Concept, Demo, Pause-and-Do practice, Solution discussion. The Pause-and-Do block has a fixed six-cell anatomy in the instructor notebook (cells 4 through 6 are stripped from the student copy):

1. ## 📝 PAUSE-AND-DO Exercise X       (markdown, prompt)
2. > 💡 Gemini Prompt: ...              (markdown, AI prompt + verify checklist)
3. # YOUR SOLUTION CODE HERE           (code, student writes here)
4. ### INSTRUCTOR SOLUTION             (markdown, removed for student)
5. # INSTRUCTOR SOLUTION               (code, removed for student)
6. <!-- INSTRUCTOR SOLUTION -->        (markdown, "reading the output", removed)

This is encoded in NOTEBOOK_TEMPLATE.md so any session, mine or the assistant’s, can produce a new exercise in the canonical shape without me re-explaining it.

5.2 The narrative polish pattern

Every markdown cell in a student notebook follows five structural elements borrowed from notebooks/nb08_cross_validation_model_comparison_student.ipynb, which I treat as the canonical voice for the course:

  1. A business-case “Why This Matters” cell with a named stakeholder (the HomeValue CFO, the MedScreen chief medical officer, the TechCorp People Analytics lead).
  2. Narrative prose, not bullet lists, in “Reading the output” cells.
  3. Inline Q&A blocks introduced by the grep-findable phrase “A question that often comes up here”.
  4. Explicit section bridges, for example “Section 2 landed the regression estimate with a tight CI. Now apply the identical four steps to the classification problem.”
  5. Warm wrap-ups with a one-paragraph bridge to the next notebook.

Because the pattern is documented and the trigger phrases are grep-findable, the assistant can polish a batch of notebooks consistently, and I can spot-check by running grep "A question that often comes up" across all student notebooks.

5.3 The render-and-commit ritual

The most common project-wide mistake I made in the first two months was pushing a content change without rendering Quarto, so the website would silently go stale. I fixed this by writing the ritual into the constitution, in plain steps the assistant can follow:

# 1. Commit content changes
git add notebooks/nbNN_topic_student.ipynb
git commit -m "feat: Update notebook NN"

# 2. Render the Quarto site
/Applications/RStudio.app/Contents/Resources/app/quarto/bin/quarto render

# 3. Commit rendered docs/
git add docs/
git commit -m "build: Render Quarto site"

# 4. Push everything
git push origin main

Tiny ritual, large payoff. As long as the assistant follows the four-step sequence, the website never drifts from the notebooks.

6 Pitfalls I hit (so you don’t have to)

A short list, in rough chronological order:

  • Trusting “looks done” without rendering. Content pushed, website stale. Fixed by promoting render-and-commit to a critical workflow in CLAUDE.md.
  • Letting solutions leak into the student notebook. Fixed by the instructor-first workflow plus an unambiguous INSTRUCTOR SOLUTION marker convention.
  • Drift in voice between sessions. The student-versus-instructor voice problem. Fixed by the voice_check_guides.py audit plus an explicit rule with examples in CLAUDE.md.
  • Test-set leakage in early-week notebooks. Fixed by the CV-first rule plus the audit_cv_first.py script.
  • Overwriting CONVERSATION_LOG.md instead of appending. Lose the history once, lose it forever. Now an explicit anti-pattern in the constitution.
  • git add . accidentally staging temp files, large CSVs, or local-only video drafts. Always git add <specific files>. Reviewing git status before staging is now part of the routine.

7 If you are just starting

A pragmatic on-ramp for a colleague whose course is already in plain-text form (or close to it):

  1. Initialize a Git repo for your course and put one artifact in it, even just the syllabus. Commit it.
  2. Install Claude Code (or any comparable AI coding assistant). Open the repo and ask it, in natural language, to describe the structure back to you. This is the cheapest way to learn whether the tool sees your project the way you do.
  3. Write a one-page CLAUDE.md with the course mission, three style rules you care most about, and a list of “see also” files. Do not over-engineer it. It will grow.
  4. Convert one artifact to a source .md file, for example one quiz or one brightspace page. Ask the assistant to edit it. Notice what it gets right and what it gets wrong. Capture the corrections in CLAUDE.md.
  5. Adopt the four-step render-commit-push ritual as soon as you have a website. Drift is the single most common failure.
  6. Keep a CONVERSATION_LOG.md from session one. Even three sentences per session is enough. You will thank yourself in month three.

Then iterate. Expect month one to feel like overhead and month three to feel like leverage. That gap is the cost of learning the tool. It is real, it is shorter than you fear, and you only pay it once.

8 Using this course as a template for your own

If you would like to use this repository as a starting point rather than reinventing the workflow, there are two paths. Replicate the design if you teach a course that resembles QM47400 in spirit, meaning a data-skills course delivered online or in a compressed window. Use it as a reference if your domain is different, and lift only the patterns that transfer.

The seven steps below are the most direct on-ramp. Each step lists what to do, the prompt you can paste into Claude Code (shown in blockquotes), and the files in this repository to point the assistant at (shown as hyperlinks).

8.1 Step 1. Get the repository onto your machine

  1. Clone the repo into a sensible working directory:
git clone https://github.com/davi-moreira/2026Summer_predictive_analytics_purdue_MGMT474.git
cd 2026Summer_predictive_analytics_purdue_MGMT474

  1. Install Claude Code if you have not yet, then launch it from inside the cloned repo so the working directory is set correctly.

  2. (Optional but recommended.) Open the same directory in your preferred editor or IDE so you can read along while the assistant works.

8.2 Step 2. Get oriented before you change anything

  1. Ask the assistant to read the constitution and the course plan, then describe the project back to you:

Read claude.md and MGMT47400_Online4Week_Plan_2026Summer.md. Describe back to me how this course is structured: the pedagogy, the 21-notebook arc, the source-of-truth files, and the rules that are non-obvious.

  1. Ask for the file map:

List every kind of source file in this repo and what each one is the source of truth for. Group them by artifact type (notebooks, video guides, brightspace pages, quizzes, exam, and so on).

  1. Spot-check by opening one notebook the assistant cites, for example notebooks/nb08_cross_validation_model_comparison_student.ipynb, so you can see what “canonical voice” actually looks like.

8.3 Step 3. Translate the constitution to your domain

  1. Copy claude.md into your own repo (rename to CLAUDE.md or keep it lowercase, either works), then ask the assistant to adapt it:

This is the constitution from another course’s repo. Adapt it for my course, which is [your course code and topic]. Replace QM47400, swap “predictive analytics” for my subject, and go through each critical rule and anti-pattern one by one. For each, tell me whether it transfers cleanly, needs editing, or does not apply.

  1. Keep the structural elements even if every concrete rule changes: project mission, the “see also” reference table, critical rules with a 🚨 prefix, style guidelines as a table, anti-patterns, and a session-end checklist.

  2. Also copy and adapt the companion files: DECISIONS.md, TROUBLESHOOTING.md, and NOTEBOOK_TEMPLATE.md. They start small and grow alongside the project.

8.4 Step 4. Adopt one pattern at a time, not all at once

Start with the two patterns that cost almost nothing and remove the two most common failure modes.

  1. The render-and-commit ritual. Copy the four-step ritual from §5.3 into your own CLAUDE.md as a critical workflow, adjusted to your renderer (Quarto, Jekyll, Hugo, MkDocs).

  2. Per-artifact source .md files. Pick one artifact (a syllabus, one quiz, one Brightspace content page). Convert it to plain-text Markdown. Edit it with the assistant. Notice what the assistant gets right and where it drifts. Capture the corrections in CLAUDE.md.

  3. After those two are stable, add the instructor-first notebook workflow from §4.3 if your course uses notebooks or lab worksheets. This is the highest-leverage addition for any course built around hands-on practice.

8.5 Step 5. Adapt the audit scripts to your invariants

  1. Read both audit scripts in this repo:
  1. Identify two or three invariants in your course that you keep correcting by hand. Then ask the assistant:

Read both audit scripts in scripts/. The invariants in my course are: [list them]. Write the equivalent audit scripts and explain how to wire them into the commit workflow.

  1. A few domain-specific invariants worth automating:
  • Causal inference course: no causal claim on observational data without a stated identifying assumption.
  • Writing-intensive course: passive voice flagged in graded examples and rubrics.
  • Lab course: every method section cites the protocol it follows.
  • Any course with student-facing materials: a voice check like voice_check_guides.py.

8.6 Step 6. Reuse the bulk-CSV pattern for Brightspace quizzes

  1. Either export one existing quiz from Brightspace as CSV, or build one by hand in the format Brightspace’s Question Library expects.

  2. Save that file inside _quizzes/ in your repo. This becomes your schema example.

  3. Generate the next quiz by pointing the assistant at the schema example:

Use _quizzes/<term>/<example-quiz>.csv as the format. Generate a 10-question quiz on [topic], in the same CSV shape, with plausible distractors and one correct answer per question.

  1. Review, edit, upload. The hour you invest in step (a) pays back across the entire semester.

8.7 Step 7. Share what you build (and what failed)

  1. Open an issue on the course repository describing what you adapted, what worked, and what failed.

  2. Or just email me directly. I keep updating this page as I learn, and a sharper version of any of these patterns from a different discipline is genuinely useful to me.

9 References

Feedback welcome. If you are a Daniels School colleague (or anyone else) adopting parts of this workflow for your own course, I would genuinely like to hear what worked and what did not. Email me at dcordeir@purdue.edu. I will update this page as the Summer 2026 offering proceeds and as my own practice changes.