---
name: sclear
description: Capture session evolution as a devlog entry, then clear. Use when the user wants to end a session but preserve what happened — decisions, pivots, learnings, and narrative hooks for future writing.
disable-model-invocation: true
allowed-tools: Bash(git *), Bash(date *), Bash(ls *), Bash(mkdir *), Write, Read, Glob, Grep
---

# Session Capture & Clear

You are about to end this session. Your job is to extract the valuable signal from this conversation and persist it **before** clearing. This is raw material for future blog posts on shinesonline.com — capture the journey, not just the output.

**CRITICAL SAFETY RULE: Do NOT clear the conversation if any write or verification step fails. If something goes wrong, stop and tell the user what failed. They can fix it and re-run `/sclear`, or just `/clear` manually if they don't care about the log.**

## Step 1: Determine the project

Figure out which project this session was about:
- Check the current working directory
- Look at what files were discussed or changed
- Derive a short kebab-case project slug (e.g., `shinesonline`, `reeve`, `claude-playpen`)
- If the session spanned multiple projects or was general, use `general`

## Step 2: Gather context

Before writing anything, collect:
- Run `git diff --stat` and `git log --oneline -5` if in a git repo (to see what changed)
- Run `git status` to see uncommitted work
- Review the conversation for decisions, pivots, surprises, and unfinished threads

## Step 3: Write the devlog entry

Create the directory if needed: `~/.claude/devlogs/{project-slug}/`

Write to: `~/.claude/devlogs/{project-slug}/YYYY-MM-DD-HHMMSS.md`

Use this structure:

```markdown
---
date: {ISO 8601 timestamp}
project: {project name}
session_id: {REQUIRED — the current session ID}
---

## What was the intent?
{Why did the user start this session? What were they trying to accomplish?}

## What actually happened?
{Brief narrative of how the session went — not a transcript, the arc.
Include: what worked, what didn't, where the approach changed.}

## Decisions made
{Bulleted list of concrete decisions, with brief rationale for each.
These are the things that would be hard to reconstruct from git log alone.}

## Pivots & surprises
{Anything that changed direction mid-session. What was the assumption,
what broke it, what replaced it. This is the most valuable section for
future writing — it's where the story lives.}

## Current state
{Where things stand right now. What's done, what's half-done, what's blocked.}

## Next moves
{What the user would likely do next session. Unfinished threads, open questions.}

## The interesting part
{If this session were a blog post, what's the hook? Not "I built X" but the
insight, tension, or lesson. One paragraph max. If nothing rises to that level,
say so — not every session has a post in it.}
```

**Writing guidelines:**
- Be honest and specific, not performative. "I tried X and it didn't work because Y" is more valuable than "we explored several approaches."
- Include actual file names, function names, error messages — specifics you'd forget in a week.
- Keep it under 400 words total. This is a log entry, not a blog post.
- Write in first person from the user's perspective ("I decided to..." not "the user decided to...")

## Step 4: Verify the write

After writing the file:
1. Read it back to confirm it was written correctly
2. Confirm the file is non-empty and contains the expected sections
3. Tell the user: the file path, a one-line summary of what was captured

**If verification fails: STOP. Tell the user. Do NOT clear.**

## Step 5: Prompt the user to clear

Only after successful verification:
- Tell the user: "Devlog saved to `{path}`. Run `/clear` when ready."
- Do NOT attempt to run `/clear` yourself — it's a built-in command that only the user can execute.
- The session-start hook will detect this devlog and skip the nudge next time.

**If the user forgets to `/clear`, no harm done — the devlog is already saved.**