Export Session Log
Turn the available conversation, tool results, changed files, and commands into a concise Markdown work log that supports handoff, resumption, or article drafting.
When to Use
- The user asks for a
session log,work log,timeline,作業ログ, or to save the current session. - The user asks for
ブログネタ, ablog draft, anarticle seed, or material for Zenn, Qiita, or Hatena. - The work history, decisions, validation results, and next steps need to be preserved for later use.
Do Not Use For
- A transcript that reproduces every message in dialogue order.
- Knowledge extraction that intentionally omits the session history.
- Reconstructing work that is not present in the available conversation or evidence.
Workflow
- Infer the topic, standard or blog intent, and any explicit destination from the request.
- Read the current local time from the system and use the actual value in
yyyy-MM-ddTHH:mm:ssformat. With PowerShell, runGet-Date -Format "yyyy-MM-ddTHH:mm:ss". - Resolve the output root using the priority rules below. Ask before creating anything only when no root can be resolved.
- Extract the summary, phases, changed files, learnings, useful commands, references, outcome, and unfinished work from available evidence.
- Create or append the log using session-log-template.md.
- Read the saved file back and verify its frontmatter, title, Timeline, actual
exported_at, and any required References. - Report the saved path and the final
success,partial, orfailedstatus.
Output Root Resolution
An explicit destination always wins. Otherwise resolve by intent:
| Intent | Environment variable | Workspace fallback |
|---|---|---|
| Standard | EXPORT_SESSION_LOG_DIR |
{workspace}/output_sessions/ |
| Blog | EXPORT_SESSION_BLOG_DIR |
Existing {workspace}/drafts_topic/ |
- For blog output, ask for a destination when the environment variable is unset and
drafts_topic/does not exist. - Ask for a destination when there is no workspace and the applicable environment variable is unset.
- Do not create a directory or file before resolving the output root.
File Naming And Append Rules
- Name new files
YYYYMMDD-NN--{topic}.md. - Use a short, descriptive, lowercase kebab-case topic.
- Append to an existing same-day, same-topic file in the resolved destination.
- Otherwise increment the highest same-day
NN; start at01when none exists. - When appending, preserve the existing frontmatter and body, then add the append block from the template.
Content Rules
- Choose
typefromcoding,research,debug,design, ordiscussion. - Record only tools that were actually used.
- Use
Phase N - {phase name}headings rather than invented timestamps. - Compress three or more repeated attempts into
N attemptsplus the final resolution. - Prefer workspace-relative Markdown links for changed files.
- When external pages informed a conclusion, list only the pages actually used, with title and URL, under References.
- When another workspace file informed the work or is needed to resume it, list a sufficiently identifying path under References.
- Include only reusable commands. Remove secrets, tokens, passwords, personal data, and sensitive local values.
- Never present guessed times, unexecuted commands, unused search candidates, or hidden reasoning as session evidence.
Success Contract
- The Markdown file exists at the resolved destination and follows the requested intent and naming rules.
- The log captures the current session outcome, verification evidence, and remaining work at a resumable level.
- External sources and cross-workspace files have corresponding References when they were used.
- The result contains no secrets, sensitive data, or hidden reasoning.