---
name: chat-conversation-logger
description: "Log the current Claude.ai chat conversation as a timestamped, downloadable markdown file ready for an AI second brain. Captures the user's prompts verbatim — every word, plus attachment types — summarizes Claude's responses concisely, and notes every tool, artifact, and MCP call. Use this skill whenever the user types '/log', 'log this conversation', 'log this session', 'save conversation log', 'convo log', 'archive this chat', or any similar phrasing — even casually. This skill is manually invoked only: do NOT trigger on your own initiative without an explicit user request, even if the conversation seems like it might be useful to archive."
---

# Chat Conversation Logger

Archive Claude.ai chat sessions as structured, second-brain-ready markdown.

## Why This Skill Exists

The user's prompts are the primary value. When they review a logged session months later, what they want to see is *what they were thinking and asking* — their mental journey through a problem. Claude's responses are secondary context that confirms what happened.

This creates an asymmetric log:
- **User prompts**: captured 100% verbatim, plus attachment metadata
- **Claude's responses**: compressed to 2–3 lines (the gist, not the prose)
- **Tools and artifacts**: noted explicitly so the user can reconstruct *what was built*, not just what was said

Think of it as a lab notebook: the scientist's questions and observations are the record; the equipment readings are noted briefly. Don't over-document Claude's side — it's noise that buries the user's thought process.

The user has a parallel `conversation-logger` skill in Claude Code that does the same job there. This is the Claude.ai counterpart. The philosophy is identical; only the mechanics differ — no `~/.claude/history.jsonl` to read from, no per-message timestamps available, attachments matter more, and MCP/artifacts/search show up as tool calls instead of bash commands.

## How to Capture the Conversation in Claude.ai

Claude.ai does not expose a history file or per-message timestamps. The conversation context Claude has loaded *is* the source of truth. To produce the log:

1. Walk back through the loaded conversation from the start to the current turn.
2. For every **user turn**, record the full text verbatim. If the user attached files, pasted long blocks, or shared images, note each one in an `**Inputs**:` line above the prompt block.
3. For every **assistant turn**, write 2–3 lines summarizing what was decided/produced, plus a `→ Tools:` line listing the tools, artifacts, MCP calls, or web searches used. Skip purely conversational acknowledgments.
4. The current invocation (the `/log` request itself) is **not** logged — it's the trigger, not content.

If the conversation is very long (50+ turns), prefer fidelity on user prompts and brevity on Claude's side. Never paraphrase or "improve" a user prompt — copy the words.

### Verbatim means verbatim

Preserve typos, voice-to-text artifacts, autocorrect mishaps, casual phrasing, missing punctuation, and incomplete sentences. The way the user wrote it is part of the record — six months later, "claw code" instead of "Claude Code" tells the user this was a voice-dictated late-night thought, which is meaningful context. Don't silently fix anything. The only legitimate exception is redacting credentials (see Edge Cases below).

## Filename and Date

Filename pattern: `chat-prompt-log-YYYY-MM-DD-{N}-{topic-slug}.md`

Where:
- `chat-prompt-log-` — literal type prefix. **Always present.** Marks the file as a Claude.ai *chat* prompt log, distinct from the Claude Code `prompt-log-` logs (from the sibling `conversation-logger` skill) and from other dated docs (plans, retros, migration records). When both log types land in the same second-brain folder, the prefix keeps them grouped and unambiguous.
- `YYYY-MM-DD` — today's date (no hours/minutes; ISO 8601 day precision is enough).
- `{N}` — a zero-based stage number that orders this log within the day. The first log of the day is `0`, the next is `1`, etc. **Always present**, even for a single-log day.
- `{topic-slug}` — kebab-case, 3–8 words, descriptive.

Examples:
- `chat-prompt-log-2026-04-26-0-continuous-executive-agent-architecture.md`
- `chat-prompt-log-2026-04-26-1-continuous-executive-agent-followup.md`
- `chat-prompt-log-2026-03-12-0-eds-block-migration-with-make-com.md`
- `chat-prompt-log-2026-04-02-0-claude-certified-architect-study-plan.md`

Get the date from the system at log-creation time:

```bash
date "+%Y-%m-%d"
```

**Picking `{N}`**: default to `0`. If you have evidence of earlier logs from the same date in the target folder (you've logged something earlier in this same chat session, or the user references a prior file), increment past the highest existing number. The stage prefix is mandatory because it's what guarantees the folder stays alphanumerically sorted in true chronological order — minute-level filename timestamps are unnecessary; a stage counter is more meaningful.

**Optional human-readable stage hints**: the slug itself may start with a stage word (`init`, `building`, `refinement`, `followup`) when it helps a future reader understand what phase this log captures — but the *numeric* `{N}` is what enforces order, not the word.

Choose the topic slug from the substantive subject of the chat — not from the user's literal first prompt, which is often vague ("hey can you help me with something"). Slug rules: lowercase, hyphen-separated, 3–8 words, descriptive enough to disambiguate from similar sessions. The user often builds the same topic 2–3 times across separate chats; the slug + date + `{N}` together must make them distinguishable on a timeline.

If you genuinely cannot tell the topic, ask the user one short question before generating the file.

## Log Structure

Use the template at `assets/init-conversation-log-template.md`. The high-level shape:

```markdown
---
date: 2026-04-26
stage: 0
platform: claude-ai
model: claude-opus-4-7
topic: continuous-executive-agent-architecture
tags: [agentic-ai, agent-sdk, multi-agent]
prompt_count: 12
status: in-progress
---

# {Human-readable title} — Conversation Log

**Date**: 2026-04-26
**Platform**: Claude.ai
**Topic**: {one-line summary of what this chat was about}

---

## Session: {Session theme}

### Prompt 1: {Descriptive title}

**Inputs**: text only

> {Full user prompt — verbatim, no edits}

→ Response: {1–2 lines on what Claude decided/answered.}
→ Action: {1–2 lines on artifacts created, files written, decisions made.}
→ Tools: {comma-separated list — e.g. web_search, image_search, create_file}
```

For two fully-worked end-to-end examples (one short clean session, one long multi-tool build session), see `references/examples.md`.

### Frontmatter fields (in priority order)

- `date` (YYYY-MM-DD) — required
- `stage` — required integer matching the `{N}` in the filename
- `platform: claude-ai` — required, fixed value
- `model` — best-effort, e.g. `claude-opus-4-7`. If unknown, omit the field entirely rather than guessing.
- `topic` — same slug used in the filename (excluding the `chat-prompt-log-` type prefix and the `{N}` stage number)
- `tags` — 2–5 short kebab-case tags inferred from the content (e.g. `agentic-ai`, `aem-eds`, `oauth`, `mcp-server`). Bias toward tags the user has used in past sessions if you can tell from context.
- `prompt_count` — integer count of user prompts logged (excluding the trigger)
- `status` — one of `complete`, `in-progress`, `blocked`, `exploration`. Default `complete` unless context indicates otherwise.

Frontmatter exists so future ingestion into a second brain (search, filter, cluster) is painless. Don't invent fields the user didn't ask for, but don't skip these.

## Capturing Inputs (the `**Inputs**:` line)

Above each user prompt, write a one-line summary of what came in with it. This matters more on Claude.ai than in Claude Code because chats are commonly multimodal.

| Input type | Inputs line example | Below the prompt |
|---|---|---|
| Text only | `**Inputs**: text only` | (nothing extra) |
| Image | `**Inputs**: text + 1 image` | `📎 *Attachment: {filename or description}*` |
| Multiple images | `**Inputs**: text + 3 images` | one 📎 line per image |
| File upload (PDF, .docx, .csv, etc.) | `**Inputs**: text + 1 file (PDF, 12 pages)` | `📎 *File: {filename} — {one-line summary}*` |
| Long pasted document | `**Inputs**: text + pasted document (~2,400 words)` | `📎 *Pasted: {one-line summary of what it was}*` |
| Code block paste | `**Inputs**: text + pasted code (Python, ~150 lines)` | `📎 *Pasted code: {what it does}*` |
| Mixed | `**Inputs**: text + 1 image + 1 PDF` | one 📎 line per item |

Keep the verbatim user prompt clean — put the attachment description on its own 📎 line below the blockquote, not inside it.

## Response, Action, Tools (the asymmetric body)

Three lines per turn, each starting with `→`. This is more detail than the Claude Code version (which uses a single line), but still tightly compressed.

```markdown
→ Response: Diagnosed the blank-screen bug as a missing useEffect dependency.
→ Action: Updated 2 React components, regenerated the artifact, all tests passing.
→ Tools: visualize:show_widget, web_search
```

Rules:

- **One sentence per `→` line** unless something genuinely needs two. Never bullet lists, never sub-items.
- `→ Response` = what Claude *said* or *decided* — the conclusion, not the reasoning chain.
- `→ Action` = what Claude *did* in the world — files created, artifacts rendered, tools invoked at a high level, decisions committed.
- `→ Tools` = the actual tool names called, comma-separated. If none, write `→ Tools: none`. See `references/action-shorthand.md` for the canonical list.
- Status emoji on the Action line if applicable: ✅ complete, ⚠️ partial, ❌ blocked, 🚧 in progress.

If a turn was a pure conversational exchange with no tool use and no decision (e.g. "thanks!" → "you're welcome"), you can collapse it into a single combined line under the prompt or omit it entirely.

## Sessions

A single chat is usually one session. Start a new `## Session N:` header only when there's a clear theme shift (e.g. you spent the first half debugging and the second half writing docs). For most logs, one session is right.

## Generating and Delivering the File

Use the existing computer-use tools:

1. Run `date "+%Y-%m-%d-%H%M"` via `bash_tool` to get the real datetime.
2. Read the template from `assets/init-conversation-log-template.md`.
3. Fill it in by walking the conversation as described above.
4. `create_file` to `/mnt/user-data/outputs/{filename}.md`.
5. (Optional) Run `python scripts/validate_log.py /mnt/user-data/outputs/{filename}.md` to lint the output. Mention any warnings to the user but don't block delivery on them — this is a sanity check, not a gate.
6. `present_files` with that path so the user can download it.
7. Briefly tell the user what was logged — prompt count, topic, filename — in 2–3 lines max. Don't summarize the conversation in chat; that's what the file is for.

## Edge Cases

**Mid-session logging.** If the user invokes `/log` partway through a chat and then keeps working, log everything up to and including the previous user turn. Treat the next `/log` as a separate session — name the second file with a `-part-2` suffix or a new topic slug if the topic shifted.

**Re-logging the same conversation.** If the user asks to re-log (e.g. they want a corrected version), regenerate fresh rather than trying to diff. Use the same datetime as the first log if it's within a few minutes; otherwise, use current time.

**Very long conversations.** Above ~50 user prompts, the file gets unwieldy. Don't drop content, but consider splitting into sessions by theme. Never silently truncate — if you must abbreviate, say so explicitly in a `> [Note: this session contained 80+ prompts; representative ones logged in full, repetitive iteration prompts collapsed to summaries]` block.

**Sensitive content.** If the conversation contains secrets the user pasted (API keys, tokens, passwords, OAuth client secrets, JWT bearer tokens), redact them in the log: `> [REDACTED: API key]`. Better to lose fidelity than to write a credential into a file the user might sync to cloud storage. This is the *only* legitimate edit to a verbatim prompt.

**You can't see the conversation.** If for some reason the conversation context is empty or you only see the trigger message, ask the user — don't fabricate. Say: "I can only see the trigger message — does this chat have prior turns you want logged, or should I treat this as a fresh session starting now?"

## What NOT to Add

The Claude Code version of this skill explicitly bans verbose session summaries — "What Was Built" lists, "Key Decisions" sections, "Next Steps" tables. Same rule here. The prompts ARE the record. Don't duplicate them in summary form.

If a closing summary feels truly necessary (end of a major milestone), 2–3 lines max:

```markdown
---

**Session summary**: 12 prompts. Built v1 of the executive loop harness, debugged the priority queue, drafted the adaptTo() submission abstract.
```

That's the ceiling. No tables. No bullet lists of accomplishments.