session-continuity
Aggressive session accountability via Obsidian timeline. PROACTIVELY log decisions, commits, ideas, and blockers AS THEY HAPPEN. Triggers on any significant action.
When & Why to Use This Skill
The Session Continuity skill provides a robust framework for maintaining persistent context across Claude Code sessions through proactive, real-time logging to an Obsidian timeline. By capturing decisions, commits, and blockers as they occur, it eliminates information loss caused by session timeouts or context window limits, ensuring a seamless workflow for long-term development projects.
Use Cases
- Multi-Session Project Tracking: Maintaining a continuous 'source of truth' for complex software projects that span days or weeks, allowing the agent to instantly recall previous architectural decisions.
- Async Task Handoff: Using the Obsidian Inbox feature to capture tasks or ideas from mobile devices and having Claude automatically review and address them at the start of the next session.
- Development Audit Trail: Automatically generating a chronological log of commits, resolved blockers, and insights, which serves as both a progress report and a searchable knowledge base.
- Crash and Timeout Recovery: Protecting work progress against unexpected session terminations by ensuring that the most recent state and decisions are logged externally in real-time.
| name | session-continuity |
|---|---|
| description | Aggressive session accountability via Obsidian timeline. PROACTIVELY log decisions, commits, ideas, and blockers AS THEY HAPPEN. Triggers on any significant action. |
Session Continuity
Maintain context across Claude Code sessions using aggressive, real-time logging.
Core Principle: Log Early, Log Often
Don't wait for session end. Log as things happen:
- Made a decision? Log it immediately.
- Committed code? Log the commit.
- Hit a blocker? Log it before context is lost.
- Had an insight? Capture it now.
You are accountable for maintaining context. The user may forget, the session may crash, context may compact. The timeline is the source of truth.
Environment
| Variable | Required | Description |
|---|---|---|
CLAUDE_TIMELINE_PATH |
Yes | Path to timeline file |
When to Log
Log immediately after any of these:
| Trigger | Format |
|---|---|
| Decision | - HH:MM **Decision**: Using X because Y |
| Commit | - HH:MM **Commit**: message (abc123) |
| Blocker | - HH:MM **Blocker**: description |
| Resolved | - HH:MM **Resolved**: how it was fixed |
| Idea | - HH:MM **Idea**: insight or suggestion |
| State | - HH:MM **State**: service on port, config changed |
Be aggressive. When in doubt, log it.
Session Start
- Read timeline from
$CLAUDE_TIMELINE_PATH - Check Inbox first - this is how user communicates async
- Acknowledge: "Timeline loaded. Inbox: [N items]. Last entry: [date]."
Inbox Protocol
The Inbox is for async capture from any device (phone, tablet, mobile Obsidian).
## Inbox
> Async capture from any device. Claude reviews at session start.
- [ ] Add Sonarr to Traefik routes
- [ ] Look into why n8n keeps disconnecting
At session start:
- Check Inbox for items
- Acknowledge what's there
- Ask if user wants to address them now
- When addressed: work on it, log the work, remove from Inbox
Timeline Format
# Claude Code Timeline
## Inbox
> Async capture from any device. Claude reviews at session start.
## Work Log
### 2025-12-19
- 23:15 **Decision**: Using Traefik - better Docker integration
- 23:30 **Commit**: feat: add prometheus (abc123)
- 23:45 **Blocker**: OAuth not redirecting
- 00:10 **Resolved**: OAuth needed explicit redirect_uri
MCP vs Filesystem
Prefer MCP if obsidian-mcp-server is available:
- Read:
mcp__obsidian-mcp-server__obsidian_read_note - Write:
mcp__obsidian-mcp-server__obsidian_update_noteorobsidian_search_replace
Fallback to native Read/Edit tools.