Stop Session

Stop a learning session

This skill closes a bracketed session: it records what happened in PROGRESS.md and gives the user a summary. It pairs with start-session.

When to use

The user explicitly signals the session is ending: "stop session", "let's wrap up for today", "end session", "we're done". For role-play sessions the signals also include "debrief" plus the flavor-specific signal per the active overlay — "end simulation" (speech-therapy), "end defense" (academic-research), "end review" (coding).

Do not invoke this skill proactively just because a conversation got long. The user brackets sessions explicitly; respect that.

What to update

Sub-project PROGRESS.md

Read and update .studyenv/<name>/PROGRESS.md (the sub-project the session ran in):

1. Topics table — for each topic touched this session, set the topic's status to the highest stage reached:

   • introduced — covered in theory this session (raise from blank)
   • exercised — practiced via a practice session (raise from introduced)
   • reviewed — exercise output / proofs / artifacts reviewed and pushed deeper (raise from exercised)

   A topic's status is the highest stage ever reached — never downgrade. If a topic was exercised and this session only touched theory on it, keep exercised.

2. Status line — if the sub-project's overall status changed (e.g. created → ready after first materials added, ready → in progress after first session), update it. Valid statuses: created, ready, in progress, blocked (with reason logged), stopped, finished. See ../../reference/conventions.md for definitions.

3. Journal — append an entry under today's date summarizing what happened: topics touched and at what new status, exercise outcomes, any notable misconceptions surfaced or breakthroughs, blockers if any.

Cross-project tracker (.studyenv/PROGRESS.md)

First read the sub-project AGENTS.md Tracking: field (../../reference/conventions.md → Tracking scope). If Tracking: local-only, skip this section entirely — the sub-project is self-tracked; do not mirror and do not warn about a missing cross-project tracker.

Otherwise (the global default, including an absent field), mirror any sub-project status change into the Projects table of .studyenv/PROGRESS.md. Update the Projects row for this sub-project; the Notes column is a one-line snapshot of where the project is now (typically the latest journal-entry summary, compressed). If .studyenv/PROGRESS.md is not found, the sub-project's own PROGRESS.md stays the source of truth — tell the user no tracker was located rather than creating one (bootstrap owns tracker creation).

Summarize for the user

After updates are written, give the user a concise summary:

• What was covered (topic(s), session type).
• New status of any topic that moved.
• What looks like a natural next session — but do not start it; this skill only closes the current one.

Keep this short. The full record is now in PROGRESS.md; the summary is the human-readable highlight reel.

Role-play debriefs (simulation, defense, review)

A role-play session runs a structured debrief out of character before the standard stop-session flow (see ../../reference/conventions.md → Role-play session protocol (generic), Phase 3). The generic move is the same — step out of character, debrief against the overlay's rubric, write artifacts, then run the normal updates below. The flavor supplies the rubric and the artifact path:

• simulation (Domain: speech-therapy) — see ../../domains/speech-therapy.md Phase 3 (which conditions were uncovered vs. missed during anamnesis, clinical reasoning, communication, what a supervisor would flag). Artifacts go to .studyenv/<name>/work/cases/<patient-id>/.
• defense (Domain: academic-research) — see ../../domains/academic-research.md Phase 3 (which questions were handled vs. fumbled, whether the contribution was defended, soundness of the method/stats answers, what a real committee would flag). Artifacts go to .studyenv/<name>/work/defenses/<topic-id>/.
• review / interview (Domain: coding) — see ../../domains/coding.md Review / interview session protocol (were design choices justified and edge cases anticipated; for interviews, decomposition / correctness / complexity / communication; what a real reviewer or panel would flag). Artifacts go to .studyenv/<name>/work/reviews/<change-id>/.

After the debrief, this skill's normal PROGRESS.md updates still apply.

Onboarding sessions

onboarding sessions are opened via the dedicated onboard-session skill, not start-session. They are not in-character, so there is no role-play debrief — they close through the standard flow above, for any overlay that flavors it (coding ships the canonical codebase flavor). When recording it, the Journal entry notes which parts of the corpus were walked and at what comprehension, which recent change was reproduced and how the user's version compared to the real one, and the next part to onboard onto. Topics in the Topics table map to subsystems / areas of the corpus. Artifacts live under work/onboarding/ (see the active overlay, e.g. ../../domains/coding.md).

Why these rules

• "Highest stage ever reached" status is what makes PROGRESS.md a useful map: it answers "have we ever exercised this?" rather than "what did we touch most recently?".
• Mirroring sub-project status into .studyenv/PROGRESS.md keeps the cross-project view consistent without requiring the user to do bookkeeping.
• A short human summary at session end matters even with the full record in PROGRESS.md — it cues the user's memory for next time.

Related skills

• start-session, onboard-session — opened this session.
• bootstrap, set-curriculum — the other lifecycle skills.