# Course Dashboard — paste this into Claude Cowork This builds the course dashboard from the video: **one table per course that becomes the single source of truth, rendered as a dashboard you talk to.** It has three parts — a **Weekly Debrief** that looks back and learns how you're doing, an **Upcoming Week** view that gets you ready to participate in your next two classes, and a **Long-Term Success** view that keeps you on track for exams and papers. **How it stays flexible:** both the *table* and the *dashboard itself* are shaped to your course, not poured into a fixed mold. Claude infers the table's schema from your syllabus, then adapts the dashboard's sections to match — a seminar, a problem-set course, and a lecture course each come out differently. Every "smart" line (the reads, the reflection questions, the pre-class drafts, the study actions) is **written by Claude with judgment and cached in the table**; the browser only looks it up and never guesses. Inputs are usually partial, so it builds from what's there, marks the rest "to be announced," and fills in as you add materials. You update it by talking, never by hand. **Before you paste this, you need one thing:** 1. A **folder for a single course**, connected to this Cowork project. That's it — it can be empty. When you paste this prompt, Claude sets up the folders (**Syllabus & Info, Lecture Slides, Readings, My Notes, Assignments, Exams & Study**) and builds an empty dashboard, then asks you to drop your **syllabus** into *Syllabus & Info* to fill it in. Add slides, readings, and notes over the term. Connecting **Gmail** helps too — it catches deadline changes a syllabus never knows about (a moved exam, a new reading) — but the syllabus is the one thing that matters to start. **How to use:** copy this entire file, paste it into a Claude Cowork chat that's connected to your course folder, and send it. Claude does the rest. After it's built, you don't edit anything by hand — you just talk to it. --- You are building my dashboard for **one university course**, inside the folder you have access to. You are my private companion for this one course, optimized entirely around helping *me* learn it. The guiding principle is simple: **`course-model.json` is the single source of truth.** It holds the course as structured data. Every view is just a drawing of that table — and every "smart" part (each Coach read, the debrief questions, the "what I'm noticing" notes, each lecture's draft discussion post and class questions, the long-term actions) is a **cached entry you write from the table with judgment**, so the dashboard gives real feedback, renders instantly, and updates the moment I tell you something changed. Do the steps below, and never let the browser do the thinking. ## Step 0 — Scaffold the folders and build the empty shell Confirm you can see and read my connected course folder, then do these in order. **1. Create the standard folders** if they're not already there (empty is fine — no readme), so there's a clear home for each kind of file: ~~~ / Syllabus & Info/ — syllabus + any schedule / Canvas export (start here) Lecture Slides/ — slide decks Readings/ — assigned + optional readings My Notes/ — my notes, whiteboard photos, screenshots, reflections, graded feedback Assignments/ — problem sets, paper/project prompts + my drafts Exams & Study/ — past/sample exams, study guides, rubrics, index cards dashboard/ — you generate this; I don't touch it ~~~ Treat these folders as **strong hints about what each file is**, but don't depend on them — if I've misfiled something, read it anyway and infer from its content. Deadline changes come from my connected Gmail, so there's no email folder. **2. Build the empty shell right away — before asking me for anything.** Write `dashboard/course-model.json` with just a skeleton: a best-guess `course.title` from the folder name, `today` set to today's date, an empty `schedule`, an empty `learningModel`, and empty `views`. Render the dashboard artifact from the reference build (Step 4). With no schedule yet it shows a friendly onboarding shell — a "0% built" coverage bar and an "add your syllabus" message — so I can see my dashboard already exists. **3. Then ask me to populate the folders, starting with the syllabus.** Say something like: > Your dashboard shell is ready. Add your **syllabus** to the **Syllabus & Info** folder (PDF, Word, a link, even a screenshot) and tell me — that's all I need to build out your schedule, deadlines, and coaching. Then drop slides, readings, and notes into the other folders whenever you have them, and it fills in. Wait for the syllabus. Don't manufacture a long questionnaire and don't invent course content. Once the syllabus is there, continue to Step 1. ## Step 1 — Read everything and audit the course Read the **syllabus first** (in *Syllabus & Info*) — it defines the structure: the schedule, learning objectives, assignments, exams, grading, recurring requirements, and expectations. Then read everything else, using the folders as a guide to what each file is: *Lecture Slides* → slides, *Readings* → readings, *My Notes* → my notes, whiteboard photos, and feedback, *Assignments* → coursework, *Exams & Study* → exam prep. If a file is misfiled, read it anyway and infer from its content. If Gmail is connected, scan it for anything that moves a date (a professor email, a Canvas announcement). As you read, **audit what makes this course *this* course.** You are about to design a table, and its shape must fit the course. Ask: - How does it meet, and how is each session framed (a driving question? a topic? a case)? - How is it graded, and what are the **recurring requirements**? A discussion post? A weekly response paper? Problem sets? Lab reports? Reading responses? Each course is different — capture the real one. - What are the **major milestones** — midterms, a final, papers, a project, a presentation — and what format are they (multiple choice, essays, a research paper, a studio critique)? - Are there **distinctive study artifacts or rules** — an allowed index card, an open-book policy, a rubric, sample exams, a required question format? ## Step 2 — Build the table (`course-model.json`), with an INFERRED schema Save a structured representation at `dashboard/course-model.json`. This is the source of truth. **Infer the schema from the audit — do not impose a fixed one.** A lecture course with discussion posts and two midterms should not have the same shape as a seminar with weekly response papers or a methods course with problem sets. Include an `_schema_note` string explaining the shape you chose and why. Capture whatever this course actually has — for most courses that includes some of: - `course` — title, code, term, instructor, meeting days, and the **grading breakdown** (with sub-components, e.g. participation = posts + attendance). - `today` (ISO), `termStart`, `termEnd`. - `requirements` — the **recurring** obligations, each with its cadence and exact rule (e.g. "submit one question about the reading by 5pm the day before lecture"). This is course-specific — get it right. - `assessments` — the milestones (exams, papers, project, presentation), each with date, weight, what it covers, and format (and any rule like "one 3×5 index card"). - `schedule` — one row per class meeting: `n`, `date`, `type` ("lecture" | "exam" | "noclass"), `title`, the driving question `q`, and `reading` ({ `cite`, optional list, a 1–2 sentence `gist`, and the `theme` — how it connects to the course's big questions). Record no-class dates as `type: "noclass"`. **Handle missing detail honestly:** leave `title`/`reading` null when the syllabus doesn't give them yet. If a session is *expected* to have a reading that simply hasn't been posted, set `readingTBD: true` (distinct from leaving `reading` null for a session with genuinely none). These flags drive the coverage meter and the "to be posted" placeholders instead of you inventing content. - `learningModel` — an evolving, **probabilistic** read of me: `concepts` (each with `lec`, a `since` date it became knowable, a `conf` 0–1, and a `note`) and `misconceptions` (each with `lec`, `since`, an optional `resolved` date, `prio`, a `detail`, and `src` provenance tags). It starts small and grows from my notes and our chats. Rules: tag **provenance** (syllabus / note / you / lecture) so I can trust each claim. Give every concept/misconception a **`since`** date so nothing shows before it was knowable, and a **`resolved`** date instead of deleting it, so history stays honest. Where the syllabus is vague (an "end of finals week" deadline), make your best call and flag it. Never invent a date silently. ## Step 3 — Write the cached "smart view" tables (the important part) This is the upgrade. The coaching is **not** computed by the browser — a hardcoded rule writes generic, sometimes-wrong advice. Instead, **you (the LLM) write these from the table, using judgment, and cache them under `views`** so the dashboard renders them instantly by lookup. Respect **temporal integrity**: write each week's entries using only what's known by that week (never leak a later lecture's insight into an earlier week). Store: - **`views.coach.upcoming`** — `{ "": "<1–3 sentence read of the coming week: what to read, what's due, the through-line>" }`. - **`views.coach.debrief`** — `{ "": "<1–2 sentence read of the week just finished>" }`. - **`views.coach.longterm`** — `""`. - **`views.debrief`** — `{ "": { "questions": ["2–3 focused reflective questions about what was clear/confusing this week"], "noticing": [ {"type":"good"|"flag", "text":"a tentative, evidence-based observation about my understanding"} ] } }`. Write the noticing from the `learningModel`, phrased tentatively ("I suspect…", "looks solid"). - **`views.upcoming`** — `{ "": { "deliverable": {"label":"…","draft":"…","due":"…"}, "questions": ["2–3 things I could raise in class"], "prep": "", "diagram": "" } }`. **Every field is optional — include only what the course actually has.** - `deliverable` is the required pre-class work, and its shape is driven by the syllabus's recurring requirement. **If the course has no pre-class submission, omit `deliverable` entirely** — do not invent a discussion post. Set `label` to what it actually is and `draft` to a real draft of it: e.g. a discussion course → `{"label":"Draft your discussion post","draft":"","due":"5pm the day before"}`; a seminar → `{"label":"Draft your response paper","draft":"","due":"Sunday 11:59pm"}`; a problem-set course → `{"label":"Problem set 5","draft":"","due":"Friday 5pm"}`. A lecture course with only attendance and exams gets **no** `deliverable`. - If I've added a slide or a photo of a whiteboard/board diagram for a lecture, you may **redraw it cleanly as an inline SVG** in `diagram` — use the palette (cream/clay/ink), no external fonts — and the card renders it under "The board, cleaned up." Omit when there's nothing to draw. - **`views.longterm`** — `{ "actions": [ {"title":"…","body":"…","src":["syllabus"|"you"|…]} ], "examStrategy": "" }`. Pull the actions from real gaps in the `learningModel` and the milestone's requirements. - **`views.notes`** — `{ "": ["", "…"] }`. These are **my actual notes, cleaned up — not a short summary.** Read the note I added and rewrite it into a faithful, detailed set of bullets (usually 6–10) that preserves the substance — the frameworks, cases, names, dates, and examples I wrote down — improving clarity and fixing typos, but staying close to what I actually captured. Put my own confusions/open questions in their own bullets and **start them with "Flagged —" or "Open question —"** (the renderer highlights those in red). Write these only for lectures where I've added notes (record the file under that lecture's `materials`). The Weekly Debrief shows them as a bulleted "YOUR NOTES" block under the session. Also let the notes update the `learningModel` (a note revealing a mix-up becomes a flagged misconception; a confident, correct note raises confidence). Write entries for the current week and the near horizon (through the end of term if you can). Any week you don't write shows a graceful empty state — that's fine, but cover at least the current and next couple of weeks richly. ## Step 4 — Render the dashboard (adapt the reference build to the course) Create a Cowork artifact whose id and name include **this specific course**, never a generic label — e.g. id `qm2-dashboard` and name “QM II — Course Dashboard,” or id `gpps463-dashboard` and name “Politics of SE Asia — Course Dashboard.” Set the name by replacing `COURSE NAME` in the `cowork-artifact-meta` block at the top of the HTML (and the ``). The HTML at the bottom of this file is a **reference build**, not a fixed template. The fastest path is: start from it, drop in the model, and **reshape it to fit this course** — because a lecture course, a seminar, and a lab should not look identical. The design system and the guardrails below are fixed; the *sections* are yours to arrange. - **Drop in the model.** Replace `/*MODEL*/` with the entire `course-model.json` object. - **Keep the fixed parts:** the three tabs (**Weekly Debrief**, **Upcoming Week**, **Long-Term Success**) as the default intents; the week navigator on the first two; the cream/clay design system (tokens, type, spacing); and the principle that all narrative is a pure lookup into the cached `views`. - **Adapt the variable parts to the course.** Relabel and add/remove sections so they match what the syllabus actually has. The reference's Upcoming Week already renders each block only when its data exists (reading, `deliverable`, prep, questions, diagram) — so if you built the table honestly, unused blocks simply don't appear. Go further when a course needs it: a problem-set course might want a "this week's problem set" section; a paper-driven seminar a "thesis workshop" block; a studio a "crit prep" block. Invent sections when the course calls for them, and cut ones that don't apply. **Hard guardrails (never break these):** - **CSP-safe:** no inline `onclick`/`onkeydown`/`oninput` — the artifact sandbox blocks them. Bind everything with `addEventListener` and event delegation (as the reference does). - **Light mode**, self-contained (inline CSS/JS, no external fonts or scripts). - **The browser never guesses.** It does only mechanical work (which meetings are next, dates, bars); all judgment/narrative is looked up from `views`. - Keep **provenance**, **temporal integrity** (nothing shows before its `since`), and **probabilistic language**. **Before you finish, verify it.** Open/inspect the rendered artifact: confirm all three tabs render, the week nav works, the current week shows the right meetings, and — importantly — that no section appears that this course doesn't have (e.g. no "discussion post" block for a course without one). Fix anything off before telling me it's ready. ## Handling incomplete or evolving inputs Most syllabi are partial, and that's normal — a course may list readings but no per-day topics, or topics but no readings, or just a schedule of dates. Detail arrives week by week as I drop materials into the folder. Build for that: - **Never fabricate.** If a lecture's topic or reading isn't in my materials yet, leave it blank in the table (`title`/`reading` null). The dashboard shows a plain "topic TBA / add materials when released" placeholder rather than an invented one. - **Fill in as it arrives.** When I add a slide deck, a reading, or a Canvas update, fold it into the table and regenerate the affected `views` — the placeholders turn into real content. - **Reshape when new material changes what's possible.** If a course turns out to have a requirement you didn't see at first (a response paper, a quiz, a project), add that section to the dashboard then — don't force everything into the first shape you guessed. The view is allowed to grow with the course. - **Say what's missing.** If the syllabus is too thin to build much, build what you can and tell me exactly what to add next (usually: per-lecture topics, or the readings) so the dashboard gets more useful. - **Show the progress.** The dashboard's coverage meter reflects how filled-in the course is (a "% built" bar) and names what's still missing ("still waiting on 4 lecture topics and 9 readings"). This makes a thin course read as *in progress*, not broken — and it climbs visibly as I add materials, which is the point. ## Step 5 — Keep it live (talk to it; never hand-edit) From here the dashboard is a snapshot I refresh by talking to you. - When I tell you something about my understanding — "I finally get TFP," "Lecture 8 lost me," "the RD design still confuses me" — update the `learningModel` (raise/lower `conf`, mark a misconception `resolved` with today's date, set provenance to "you"), **rewrite the affected cached views** (the debrief noticing, the long-term actions), and re-render. - When something about the course changes — "the midterm moved to the 9th," "there's a new reading" — update the `schedule`/`assessments` row, rewrite affected views, re-render. - The **Weekly Debrief's questions are answered in chat.** When I reply, fold my answers into the learning model and update the dashboard. - **When I add my notes** (a text file, a photo of the board, a screenshot) for a session, attach the file under that lecture's `materials`, write a short recap into `views.notes`, and update the `learningModel` from what the notes reveal — then re-render. My notes then show up as a "YOUR NOTES" recap in that week's Debrief. (If I hand you a whiteboard/slide diagram, you may also redraw it cleanly into the lecture's `diagram`.) - When I ask a question — "what's due this week?", "am I ready for the midterm?" — answer in plain words straight from the table. Read it; don't guess. Always treat `course-model.json` as the one source of truth, and never let the dashboard or any cached view drift from it. ## Step 6 — Put it on autopilot (a weekly briefing) Set up a scheduled task so the dashboard keeps itself current and checks in with me. First ask whether I want it weekly or daily and at what time — **default to Sunday evening**, since that's when I plan my week. Then create a scheduled task that, on that cadence: 1. Re-reads my course folder (and Gmail/Canvas if connected) and updates `course-model.json` — new materials folded in, deadlines reconciled (newer source wins), ambiguities flagged, my "I finished/understood X" updates applied. 2. **Regenerates the cached `views`** with fresh judgment (the same pass as Step 3), respecting temporal integrity. 3. Re-renders the dashboard artifact (the one replacement from Step 4). 4. Sends me a short, skimmable briefing: my next two class meetings and what to prep, upcoming deadlines, the single highest-leverage thing to do now for my next big milestone, and anything that changed since last time. One thing to tell me: a scheduled task only runs while my desktop app is open and awake, so it fires the next time both are true. ## Each new week / new term - **Each week:** advance `today`, sweep the folder for anything I've added, and regenerate the cached views for the new current week and horizon. - **New term:** when I drop new syllabi/materials and say "rebuild," re-read from scratch, rebuild `course-model.json` with the new term's structure (re-inferring the schema — it may differ), rebuild the views, and re-render. Keep old items as history if I want it, or clear them — ask if it's unclear. I never edit the table or the template by hand. I can start on any day, in any term; the dashboard centers itself on today automatically. ## The reference build This is a complete, working dashboard to **start from and adapt** (Step 4), not a template to paste verbatim. At minimum, replace `/*MODEL*/` with your `course-model.json`. Then reshape the sections to fit the course, keeping the design system and the guardrails intact. Everything here renders each block only when its data exists, so an honest table already hides what doesn't apply. ```html <!doctype html> <script type="application/json" id="cowork-artifact-meta"> { "name": "COURSE NAME — Course Dashboard", "schemaVersion": 1, "description": "Personal course dashboard, rendered from course-model.json." } </script> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <title>Course Dashboard

Course dashboard

A snapshot rendered from your course table. All narrative is written by your coach and cached — update it by talking to me in the chat.
```