Progress Update -- Session Log
The repo never lies. This keeps the record honest, current, and useful for the next session start.
Trigger
/progressor "update progress"- At end of session, before commit
Execution
Read last entry in PROGRESS.md (get current session number and state).
Gather from session context (or ask the student if unclear):
- What did we do this session? (specific activities: theory, build, review, brainstorm)
- What's the key thing learned? (one sentence, specific)
- Where exactly are we stopping? (mid-prep? exercise done? review pending?)
- Approximately how long was this session? (even rough: 15m, 1h, 3h)
- What concepts go into the spaced review deck?
Append new row to PROGRESS.md table:
| {session} | {date} | {time} | {topic} | {key learning} | {state} |Time format:
~15m,~1h,~3h. Even rough estimates help future students plan.Session state examples:
exercise complete, reviewed-- fully donetheory discussed, exercise not started-- mid-flowexercise built, review pending-- will review next sessionbrainstorm only -- wiki page created-- knowledge session
Update ROADMAP.md current status if topic or project state changed.
If concepts were learned, prompt to add them to spaced review deck.
Remind: "Run
/postfor your X post, then commit and push."
What Gets Captured
Every progress entry must tell the next session exactly where to pick up:
- What was DONE (so we don't repeat it)
- What is IN PROGRESS (so we continue it)
- What is NEXT (so we can plan the session)
Rules
- Every session ends with a progress update + commit. Non-negotiable.
- Key learning must be specific, not vague. "Learned about dicts" → rejected. "Learned that defaultdict avoids KeyError checks in frequency counting" → accepted.
- If the student can't articulate a key learning, the session wasn't focused enough. Flag it.
- Session state must be precise enough that next session's /checkin can pick up exactly where we left off.
- If wiki pages were created during the session, note them in the entry.