The context budget must be controlled
The context window accumulates messages, files, logs, rules, and command results. Even useful materials can turn into noise over time: duplicates, old hypotheses, and long results appear and obscure the main goal.
A deteriorating response does not always mean there is a model problem. Often the cause is a poorly organized session workspace.
Checking with `/context`
`/context` helps assess what fills the session: how much the history has grown, whether logs take up too much space, whether the needed files remain present, and whether the main focus has become mixed with side topics.
- Check the size and composition of the history.
- Find large logs or repeated results.
- Make sure the goal, scope, and important constraints remain visible.
- Decide whether compressing the history is enough or a new session is needed.
/contextWhen to use `/compact`
`/compact` compresses the previous history into a shorter summary. It is appropriate when the task has not changed but repetitions, logs, and intermediate reasoning take up too much space.
Before compressing, explicitly name the data that must be preserved: the goal, scope, non-goals, verified facts, important errors, rejected hypotheses, and next action.
/compact
Preserve: goal, scope, non-goals, verified facts,
important stack trace, rejected hypotheses, and next step.When `/clear` is needed
`/clear` is appropriate when the topic has changed or the original boundaries are already difficult to recover. After clearing, re-enter the task spec, evidence, and criteria rather than carrying over the entire old history.
/clearAn external task spec after compaction
- expected result;
- permitted files or directories;
- technical prohibitions;
- acceptance conditions;
- verification plan and next step.
Canonical lesson source · JavaRush
Open JavaRush material