# Session To Skill > Use when the user wants to turn one or more Entire-tracked sessions, checkpoints, or repeated agent workflows into a reusable agent skill. - Skill: `entireio/session-to-skill` (Agent Skill) - Install (CLI): `npx skillmds@latest add entireio/session-to-skill` - Raw SKILL.md: https://api.skillmd.com/api/skills/entireio/session-to-skill/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: entireio (https://skillmd.com/u/entireio) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/entireio/session-to-skill --- # Session To Skill Use this skill to help the user turn Entire session history into a focused skill draft. The goal is not to convert a whole transcript mechanically. Treat sessions and checkpoints as source material, then extract the reusable workflow the user wants to repeat. ## Response Format Begin the first response to this skill invocation with the line: `Entire Session To Skill:` followed by a blank line, then the content. - Apply the header to the **first response of the invocation only.** Do not re-print it on follow-up turns within the same invocation. - Do **not** include the header on error or early-exit responses, such as when Entire is not installed, the current directory is not a git repository, no relevant sessions are found, or the user has not identified what reusable behavior they want. ## Rules 1. First identify the reusable behavior the skill should capture. If the user has not said what the skill should help with, ask that question before reading transcripts. 2. Use Entire history as evidence. Prefer `entire search`, `entire session current`, session metadata files, and `entire checkpoint explain` over asking the user to paste old transcripts. 3. A skill draft should be focused on future behavior, not a recap of the session. Preserve durable workflow, repo conventions, user corrections, commands, validation, and things to avoid. 4. When several sessions may be relevant, summarize the repeated workflow pattern, recommend a source set, and ask the user to confirm before expanding transcripts. 5. Do not write, install, or overwrite a skill file unless the user explicitly approves the destination. By default, present the `SKILL.md` draft in the response. 6. Do not include secrets, private credentials, raw logs, or unnecessary transcript detail in the generated skill. ## Workflow ### 1. Clarify The Skill Target If the user gives a clear target, continue. Examples: - "turn my blog publishing workflow into a skill" - "make a skill from session 019..." - "I keep doing release note drafting; make that reusable" If the target is vague, ask: ```text What should this skill help you do repeatedly? ``` If the user wants a specific skill name, use it. Otherwise infer a short hyphen-case name from the target, then confirm it before writing files. ### 2. Infer The Repeated Pattern If the user gives a checkpoint ID, skip to checkpoint expansion. If the user gives a session ID, read the matching session metadata from: ```text .git/entire-sessions/.json ``` If the user describes a repeated workflow but does not give a session or checkpoint, search Entire history with terms from the target: ```bash entire search "" --json ``` Use repo, branch, author, or date filters when the user provides them: ```bash entire search "" --json --repo owner/name --branch branch-name --author "Name" --date month ``` Interpret search results carefully: - If `entire search` returns valid JSON with `"total": 0` or an empty `results` array, do **not** call it an authentication failure. Say no indexed matches were found, then fall back to local session metadata. - Only say authentication is required if the command output explicitly says authentication, login, or credentials are required. - If search fails for any other reason, report the short error and fall back to local session metadata when available. When falling back locally, inspect `.git/entire-sessions/*.json` and match against `last_prompt`, `description`, `files_touched`, `started_at`, `last_interaction_time`, `agent_type`, and the user's workflow terms. Review the top results and infer the repeated workflow pattern before showing raw session choices. Lead with the pattern, not the IDs. Present: - the repeated workflow you think the user wants to capture - the strongest source set you recommend using - what each source contributes in plain language, such as "core workflow", "image handling", "validation", or "copy-editing pattern" - any sessions you plan to ignore because they look metadata-only, duplicate, or one-off Keep session IDs and checkpoint IDs as supporting details, not the main decision surface. Ask the user to confirm the pattern and source set before expanding detailed transcripts. Example: ```text I found a repeated workflow: publishing blog posts in entire.io from drafts, using repo-specific front matter, slugged asset folders, user-provided images, and website checks. I recommend using the strongest matching sessions as source material: - core workflow: - image handling: - validation mechanics: I will ignore metadata-only or one-off edit sessions unless you want them included. Should I continue with this source set? ``` ### 3. Read Source Material For a checkpoint, run: ```bash entire checkpoint explain --checkpoint --full --no-pager ``` If full output fails and the user wants more detail, fall back to: ```bash entire checkpoint explain --checkpoint --raw-transcript --no-pager ``` For an active or current session, prefer: ```bash entire session current ``` If the installed Entire CLI does not support the singular `session` group yet, use the session metadata fallback directly: inspect `.git/entire-sessions/*.json`, pick the relevant session by `last_interaction_time`, `started_at`, `agent_type`, or the user's requested agent, then extract `transcript_path`. When reading a raw transcript, extract relevant conversation and tool-call lines without dumping them to the user: ```bash grep -E '"type":"(message|function_call|user|assistant)"' | cut -c1-2000 ``` For large transcripts, inspect the first prompts and final state first: ```bash grep -E '"type":"(message|function_call|user|assistant)"' | head -40 | cut -c1-2000 grep -E '"type":"(message|function_call|user|assistant)"' | tail -160 | cut -c1-2000 ``` If the session metadata lists files touched, inspect only files needed to understand durable conventions. Avoid broad repo exploration unless the skill target requires it. ### 4. Extract Durable Lessons Before drafting, privately identify: - the repeated goal the future skill should accomplish - triggers that should activate the skill - required inputs the future agent should ask for - repo-specific paths, file formats, front matter, naming, or asset placement - commands and checks that proved the workflow worked - user corrections and preferences from the session - failed approaches or behaviors to avoid - what was one-off and should not go into the skill If multiple sessions were selected, combine only the repeated or clearly reusable lessons. Do not average contradictory instructions; ask the user to choose when sessions disagree. ### 5. Draft The Skill Create a complete `SKILL.md` draft with required front matter: ```markdown --- name: description: Use when . --- ``` The body should include: - a short purpose statement - clear rules or guardrails - a step-by-step workflow - exact commands only when they are part of the reusable behavior - expected outputs and validation steps - failure handling or when to ask the user Keep the skill concise. Do not include the session recap, full transcript excerpts, checkpoint IDs, or implementation notes unless they are essential to future use. ### 6. Deliver And Offer Installation Present the `SKILL.md` draft first unless the user already gave an explicit write path. After presenting the draft, ask whether the user wants it installed globally. Recommend the cross-agent path: ```text ~/.agents/skills//SKILL.md ``` Use this install prompt shape: ```text Do you want me to install this skill globally? Recommended: - Cross-agent: ~/.agents/skills//SKILL.md Other options: - Codex only: ~/.codex/skills//SKILL.md - Write to a repo-local draft: skills//SKILL.md - Leave as draft only ``` Only write files after the user chooses a destination. If the destination already exists, ask before overwriting it. Do not create symlinks unless the user explicitly asks for a development-linked install. If they ask for a symlink, explain the source and target paths before creating it. After writing a skill file, summarize: - where it was written - which session(s) or checkpoint(s) informed it - any assumptions or open questions