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?