القائمة
This skill should be used when the user asks to "analyze session", "summarize session", "compact session", "what happened in session", "/compact-session", or provides a path to a .jsonl session file and wants a summary of what was done.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | compact-session |
| description | This skill should be used when the user asks to "analyze session", "summarize session", "compact session", "what happened in session", "/compact-session", or provides a path to a .jsonl session file and wants a summary of what was done. |
| version | 2.0.0 |
| context | fork |
| model | haiku |
| allowed-tools | Read, Write, Bash |
Analyze a Claude Code session JSONL file and generate a structured Markdown summary.
The user must provide a path to a .jsonl session file as an argument.
The path is available as a clickable 📄 link in the status line (OSC8 hyperlink).
If no path was provided → ask the user to pass it:
"Передай путь к файлу сессии (
.jsonl). Его можно скопировать из 📄 ссылки в строке состояния."
Each line is an independent JSON object. Parse each line separately.
{"type": "user", "message": {"role": "user", "content": "текст запроса"}, "uuid": "...", "timestamp": "..."}
content may be a string or an array of blocks.
{"message": {"role": "assistant", "content": [
{"type": "thinking", "thinking": "внутренние рассуждения"},
{"type": "text", "text": "ответ пользователю"},
{"type": "tool_use", "name": "Bash", "input": {"command": "..."}}
]}, "uuid": "...", "timestamp": "..."}
{"type": "user", "message": {"role": "user", "content": [
{"type": "tool_result", "tool_use_id": "...", "content": "вывод инструмента"}
]}}
{"type": "file-history-snapshot", ...} — пропуститьparentUuid, isSidechain, sessionId (no message) — пропуститьSkip user message content that starts with:
<local-command-caveat>, <command-name>, <local-command-stdout>, <command-message>
Skip skill/command body injections — long multi-section markdown starting with
## Правила, ## Алгоритм, ## Instructions, ## Your task.
Skip meta-commands: /clear, /verify, /terminal-setup, /compact-session.
text blocks — primary sourcethinking blocks — use to fill gaps; summarise reasoning, never quote verbatimtool_use blocks — identify which tools were used and what was donetool_result blocks (in user messages) — use only if essential to understand outcomeWrite the report in Russian. Use Markdown. Total ≤ 150 lines.
Do not include: file paths to the session file, UUIDs, timestamps, message counts, or any meta-information about the file itself. Report only what was discussed and done.
Main goal in one sentence (from first substantive user message).
One bullet per distinct user task, condensed to one line.
For each task — what the assistant actually did:
файл:строка если доступно)One paragraph, 2–4 sentences, in Russian, plain language.
Do not quote large content verbatim. Focus on intent and outcomes.
After generating the Markdown report, save it to a file in the project's tmp/ directory:
mkdir -p tmp via Bash to ensure the directory exists.date +%Y%m%d-%H%M%S via Bash to get a timestamp.tmp/compact-session-<timestamp>.md using the Write tool
(absolute path: prepend the result of pwd to the filename)."Отчёт сохранён:
tmp/compact-session-<timestamp>.md"
Use the current working directory (project root where the session was opened).
Do not save to the system /tmp — always use the project-local tmp/ folder.
Use when improving ONE numeric metric under a controlled research loop with a fixed eval and kept/reverted experiments. Not for a feature (use loop-delivery) or a failing test (use loop-repair).
Use when delivering ONE bounded change — a feature, refactor, or chore — as a controlled, audited loop in any repo. Not for a failing test (use loop-repair) or a numeric metric (use loop-autoresearch).
Use when a specific test, CI job, or regression is failing and must be fixed under a reproduce-first controlled loop with proven regression coverage. Not for delivering a change (use loop-delivery) or metrics (use loop-autoresearch).
Use when a loen loop stage — plan, act, check, or result — must be validated and gated before the next one. Mode-aware for delivery/repair/research; the execution-loop analog of check-chain.
Use when you need a cross-run dashboard over all docs/loen/ runs, or --triage to turn failing runs into proposed next actions (proposals only; never launches loops or edits runs).
Use when an active, human-approved loen run should keep going multi-turn on its own — wraps it in Claude's native /goal from loop.yaml. Optional; never bootstraps a run or submits /goal itself.