| name | learn-assignment |
| description | Complete a UW Learn assignment, lab, problem set, tutorial, or quiz grounded strictly in ingested class material, with citations to the exact source files. Use when the user wants to do, draft, solve, work on, study for, or get full marks on coursework using only their course materials — and optionally submit on Learn only when explicitly told for a specific item. |
learn-assignment — grounded, cited coursework from class material only
The headline workflow: produce a full-marks-quality solution grounded strictly in the user's own
class material, citing every step, as a draft for their review. This is their own coursework;
respect UW's academic-integrity policy.
Use the venv interpreter: PY=.learn/.venv/bin/python.
Workflow (follow exactly)
-
Identify the course + assignment. If unsure what exists:
$PY .learn/learn.py ground --list MSE232
-
Assemble the grounding pack (finds the task + its data files + the course outline +
the most relevant lectures, ranked; searches Content, announcements, and assignments):
$PY .learn/learn.py ground MSE232 Lab 4
It writes GROUNDING.md next to the assignment and prints an exact "Files to read" list.
-
Read every file in that list, in full (use the Read tool — do not skim, do not rely on
filenames). These are the only sources you may use.
-
Draft the solution, obeying the grounding policy printed in GROUNDING.md:
- Use only the listed class sources — no outside knowledge, no internet, no methods not taught.
- Solve to the standard required for full marks; show all work/steps.
- Cite every non-trivial step as
relative/path.md:line (or PDF page).
- Match the course's notation/terminology (use the lecture's symbols + definitions).
- If a needed concept is not in the materials, say so explicitly and stop — never fabricate
or import an outside method.
- End with a "Sources used" list.
-
Save the draft as DRAFT_solution.md (or the appropriate file type, e.g. a .ipynb/.py when
the lab is code — match what the lab asks for) next to the assignment, and present it for review.
-
Submission is gated. Do NOT submit anything to Learn unless the user explicitly says
"submit " for that specific item. The submitter is learn.py submit:
PY=.learn/.venv/bin/python
$PY .learn/learn.py submit --list MSE232
$PY .learn/learn.py submit MSE232 "Lab 4" path/to/solution.pdf
$PY .learn/learn.py submit MSE232 "Lab 4" path/to/solution.pdf --confirm
- Everything is the raw D2L API (no browser): a dropbox submission is one atomic POST to
…/dropbox/folders/{id}/submissions/mypost (the file part(s) + optional comment).
- Always run the DRY RUN first and show the user the resolved target. Only add
--confirm after
they explicitly approve THIS item. --confirm submits and then verifies by API read-back that a
new submission with the exact file (name + size), submitted by the user, is on record.
- The first real submission for a user is untestable until done — supervise it: present the dry-run,
get the explicit go-ahead, submit, then report the read-back result. Never claim success unless the
read-back confirms the file is on record (
✅ SUBMITTED AND VERIFIED).
- Non-Dropbox targets (GitHub Classroom / Crowdmark / external) are surfaced as links — tell the user;
submit handles Dropbox folders only.
Where things live
- Task + data: under
content/<…>/ (labs keep their CSVs/notebooks beside the take-home PDF) or in
announcements/ (some assignments are announcement attachments).
- Grading scheme / weights: the
… (outline).md file in the course (from the course outline).
- Cross-links: each
assignments/<name>/README.md points to the real materials in Content.
Quizzes
The API stores quiz metadata only. Quiz question text isn't ingested. To capture the user's
own completed attempts (review pages), load the agent-browser skill and render them — within
the course's academic-integrity rules. Never extract or complete a live quiz for someone else.
