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:

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:

.git/entire-sessions/<session-id>.json

If the user describes a repeated workflow but does not give a session or checkpoint, search Entire history with terms from the target:

entire search "<workflow terms>" --json

Use repo, branch, author, or date filters when the user provides them:

entire search "<workflow terms>" --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:

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: <session-id>
- image handling: <session-id>
- validation mechanics: <session-id>

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:

entire checkpoint explain --checkpoint <checkpoint-id> --full --no-pager

If full output fails and the user wants more detail, fall back to:

entire checkpoint explain --checkpoint <checkpoint-id> --raw-transcript --no-pager

For an active or current session, prefer:

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:

grep -E '"type":"(message|function_call|user|assistant)"' <transcript_path> | cut -c1-2000

For large transcripts, inspect the first prompts and final state first:

grep -E '"type":"(message|function_call|user|assistant)"' <transcript_path> | head -40 | cut -c1-2000
grep -E '"type":"(message|function_call|user|assistant)"' <transcript_path> | 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:

---
name: <hyphen-case-skill-name>
description: Use when <specific trigger and task>.
---

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:

~/.agents/skills/<skill-name>/SKILL.md

Use this install prompt shape:

Do you want me to install this skill globally?

Recommended:
- Cross-agent: ~/.agents/skills/<skill-name>/SKILL.md

Other options:
- Codex only: ~/.codex/skills/<skill-name>/SKILL.md
- Write to a repo-local draft: skills/<skill-name>/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