Back to Details

session-to-skill

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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.
使用此Skill帮助用户将Entire会话历史转换为聚焦的Skill草稿。
目标并非机械性地转换完整对话记录，而是将会话和检查点作为素材，提取用户希望重复执行的可重用工作流。

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.
首次调用此Skill时，响应需以以下内容开头：
Entire Session To Skill:
随后空一行，再添加具体内容。
  • 仅在首次调用的响应中添加上述标题，同一调用的后续交互中请勿重复打印。
  • 错误或提前退出响应中请勿包含该标题，例如当Entire未安装、当前目录不是git仓库、未找到相关会话，或用户未明确指出想要提取的可重用行为时。

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 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.
  1. 首先确定Skill需要捕获的可重用行为。若用户未说明Skill的用途，需先询问该问题，再读取对话记录。
  2. 以Entire历史记录为依据。优先使用
    entire search
    、
    entire session current
    、会话元数据文件和
    entire explain
    ，而非让用户粘贴旧对话记录。
  3. Skill草稿应聚焦于未来的行为，而非会话回顾。保留持久化工作流、仓库约定、用户修正、命令、验证步骤以及需要避免的操作。
  4. 当多个会话可能相关时，总结重复的工作流模式，推荐一组素材来源，并在展开对话记录前请用户确认。
  5. 除非用户明确批准目标路径，否则请勿编写、安装或覆盖Skill文件。默认情况下，在响应中展示
    SKILL.md
    草稿。
  6. 生成的Skill中请勿包含机密信息、私人凭证、原始日志或不必要的对话记录细节。

Workflow

工作流

1. Clarify The Skill Target

1. 明确Skill目标

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.
若用户给出清晰目标，继续操作。示例：
  • "将我的博客发布工作流转换为Skill"
  • "从会话019创建一个Skill..."
  • "我一直在撰写发布说明；把这个做成可重用的Skill"
若目标模糊，询问：
text
这个Skill应该帮你重复完成什么操作？
若用户指定了Skill名称，使用该名称。否则根据目标推断一个简短的连字符格式名称，然后在编写文件前请用户确认。

2. Infer The Repeated Pattern

2. 推断重复模式

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/<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:
bash
entire search "<workflow terms>" --json
Use repo, branch, author, or date filters when the user provides them:
bash
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:
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: <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?
若用户提供了检查点ID，直接跳转到检查点展开步骤。
若用户提供了会话ID，从以下路径读取匹配的会话元数据：
text
.git/entire-sessions/<session-id>.json
若用户描述了重复工作流但未提供会话或检查点ID，使用目标中的关键词搜索Entire历史记录：
bash
entire search "<workflow terms>" --json
当用户提供仓库、分支、作者或日期信息时，使用相应过滤器：
bash
entire search "<workflow terms>" --json --repo owner/name --branch branch-name --author "Name" --date month
仔细解读搜索结果：
  • 若
    entire search
    返回的有效JSON中
    "total": 0
    或
    results
    数组为空，请勿将其称为认证失败。应说明未找到匹配的索引记录，然后回退到本地会话元数据。
  • 仅当命令输出明确提及认证、登录或凭证要求时，才说明需要认证。
  • 若搜索因其他原因失败，报告简短错误信息，并在可用时回退到本地会话元数据。
回退到本地时，检查
.git/entire-sessions/*.json
，并根据
last_prompt
、
description
、
files_touched
、
started_at
、
last_interaction_time
、
agent_type
以及用户的工作流关键词进行匹配。
在展示原始会话选项前，先查看顶部结果并推断重复的工作流模式。优先展示模式，而非会话ID。
展示内容包括：
  • 你认为用户想要捕获的重复工作流
  • 你推荐使用的最匹配的素材来源组
  • 每个来源的作用（用通俗语言描述，如“核心工作流”、“图片处理”、“验证步骤”或“文案编辑模式”）
  • 你计划忽略的会话（因这些会话仅包含元数据、重复内容或一次性操作）
将会话ID和检查点ID作为辅助细节，而非主要决策依据。在展开详细对话记录前，请用户确认模式和素材来源组。
示例：
text
我发现了一个重复工作流：在entire.io平台从草稿发布博客文章，使用仓库特定的前置内容、带slug的资源文件夹、用户提供的图片以及网站检查步骤。

我推荐使用以下最匹配的会话作为素材来源：
- 核心工作流：<session-id>
- 图片处理：<session-id>
- 验证机制：<session-id>

除非你要求包含，否则我将忽略仅含元数据或一次性编辑的会话。我可以使用这组素材来源继续操作吗？

3. Read Source Material

3. 读取素材来源

For a checkpoint, run:
bash
entire explain --checkpoint <checkpoint-id> --full --no-pager
If full output fails and the user wants more detail, fall back to:
bash
entire explain --checkpoint <checkpoint-id> --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)"' <transcript_path> | cut -c1-2000
For large transcripts, inspect the first prompts and final state first:
bash
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.
对于检查点，运行：
bash
entire explain --checkpoint <checkpoint-id> --full --no-pager
若完整输出失败且用户需要更多细节，回退到：
bash
entire explain --checkpoint <checkpoint-id> --raw-transcript --no-pager
对于活跃或当前会话，优先使用：
bash
entire session current
若已安装的Entire CLI暂不支持单数形式的
session
组，直接使用会话元数据回退方案：检查
.git/entire-sessions/*.json
，根据
last_interaction_time
、
started_at
、
agent_type
或用户请求的Agent选择相关会话，然后提取
transcript_path
。
读取原始对话记录时，提取相关的对话和工具调用行，无需完整展示给用户：
bash
grep -E '"type":"(message|function_call|user|assistant)"' <transcript_path> | cut -c1-2000
对于大型对话记录，先查看初始提示和最终状态：
bash
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
若会话元数据列出了涉及的文件，仅检查理解持久化约定所需的文件。除非Skill目标要求，否则避免全面探索仓库。

4. Extract Durable Lessons

4. 提取持久化经验

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.
在编写草稿前，先明确以下内容：
  • 未来Skill应完成的重复目标
  • 触发Skill激活的条件
  • 未来Agent需要询问的必填输入
  • 仓库特定的路径、文件格式、前置内容、命名规则或资源放置方式
  • 验证工作流有效的命令和检查步骤
  • 会话中的用户修正和偏好
  • 失败的方法或需要避免的行为
  • 属于一次性操作、不应纳入Skill的内容
若选择了多个会话，仅整合重复或明确可重用的经验。当会话内容矛盾时，请勿折中处理，需请用户选择。

5. Draft The Skill

5. 编写Skill草稿

Create a complete 
SKILL.md
draft with required front matter:
markdown
---
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.
创建完整的
SKILL.md
草稿，包含必填的前置内容：
markdown
---
name: <hyphen-case-skill-name>
description: Use when <specific trigger and task>.
---
正文应包含：
  • 简短的用途说明
  • 清晰的规则或约束
  • 分步工作流
  • 仅当命令属于可重用行为时才包含精确命令
  • 预期输出和验证步骤
  • 故障处理或需要询问用户的场景
保持Skill简洁。请勿包含会话回顾、完整对话记录片段、检查点ID或实现说明，除非这些内容对未来使用至关重要。

6. Deliver And Offer Installation

6. 交付并提供安装选项

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-name>/SKILL.md
Use this install prompt shape:
text
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
除非用户已明确指定写入路径，否则先展示
SKILL.md
草稿。
展示草稿后，询问用户是否要全局安装。推荐跨Agent路径：
text
~/.agents/skills/<skill-name>/SKILL.md
使用以下安装提示格式：
text
是否要我将此Skill全局安装？

推荐选项：
- 跨Agent：~/.agents/skills/<skill-name>/SKILL.md

其他选项：
- 仅Codex：~/.codex/skills/<skill-name>/SKILL.md
- 写入仓库本地草稿：skills/<skill-name>/SKILL.md
- 仅保留草稿
仅在用户选择目标路径后才写入文件。若目标路径已存在，覆盖前需询问用户。
除非用户明确要求开发链接式安装，否则请勿创建符号链接。若用户要求创建符号链接，需在创建前说明源路径和目标路径。
写入Skill文件后，总结以下内容：
  • 文件写入位置
  • 参考的会话/检查点
  • 任何假设或未解决的问题