A session is a container for one task
A session should be treated as a separate container for one task or workstream. If a bugfix, documentation, tests, and architectural changes are combined in one chat, the context becomes noisy and Claude may lose the right direction.
A well-organized session has one goal, a defined change area, constraints, accepted decisions, and a clear next action.
| At the start of a session | At the end of an intermediate checkpoint |
|---|---|
| Task name | Verified facts |
| Expected result | Rejected hypotheses |
| Permitted files | Immutable constraints |
| Forbidden changes | Next step |
| Open questions | Verification results |
When to continue the current session
- the goal has not changed;
- the work area remains the same;
- the history is still easy to explain;
- Claude receives consistent context;
- the needed files and constraints remain visible.
When to start a new session
- a different task has started;
- the work boundaries have become mixed;
- the original goal is difficult to state;
- old context interferes with decision-making;
- the model returns to rejected assumptions.
An external short summary
After an important checkpoint, move the task goal, confirmed cause, rejected hypotheses, immutable constraints, and next action outside the session. This lets you quickly return to work without repeating the investigation.
# Task status
## Goal
Description of the expected result.
## Confirmed
- ...
## Rejected
- ...
## Constraints
- ...
## Next step
- ...A session lifecycle ritual
- Extract the goal, scope, constraints, and criteria from TASK_SPEC.md.
- Add only the necessary files, tests, logs, and reproduction steps.
- Check the context state through
/context. - Distinguish missing data from an overloaded history.
- When needed, add a specific file, compress the dialogue, or start a new session.
- Finish work at a clear intermediate checkpoint and save a summary.
Canonical lesson source · JavaRush
Open JavaRush material