context-persistence

Context Persistence Skill

Purpose

Ensure Claude Code can resume work seamlessly after context resets, session interruptions, or long breaks by maintaining structured documentation of current work, decisions, and progress.

When to Use This Skill

Automatically activates when you mention:

• Waypoint plans, waypoint planning
• Resuming work, continuing work
• Session survival, context reset
• Task handoff, progress tracking
• Long-running features or projects
• Need to document current state

The Problem: Context Resets

What happens during a context reset:

• ❌ All conversation history lost
• ❌ Current task context forgotten
• ❌ Decisions and rationale gone
• ❌ Progress not tracked
• ❌ Have to re-explain everything

With context persistence:

• ✅ Current task documented
• ✅ Decisions and rationale preserved
• ✅ Progress clearly tracked
• ✅ Quick resume in < 1 minute
• ✅ Seamless handoff to future sessions

Three-File Structure

The core pattern uses three complementary files in plans/active/{task-name}/:

1. {task-name}-plan.md - The Strategic Plan

Purpose: High-level strategy and approach

Contains:

• Feature/task overview
• Requirements and acceptance criteria
• Architecture approach
• Implementation phases
• Dependencies and constraints
• Risks and mitigations

Update frequency: Rarely (only when approach changes)

Example:

# Authentication Implementation Plan

## Overview
Add JWT-based authentication to replace session cookies for mobile app support.

## Requirements
- JWT tokens with refresh mechanism
- Supabase Auth integration
- Protected API routes
- Mobile-friendly (stateless)

## Architecture
- Auth middleware in Edge Functions
- Token storage in httpOnly cookies (web) + AsyncStorage (mobile)
- Row-Level Security policies for data access

## Implementation Phases
1. Supabase Auth setup
2. Edge Function auth middleware
3. Frontend auth hooks
4. RLS policies
5. Migration from existing auth

## Dependencies
- Supabase setup complete
- Database schema finalized

2. {task-name}-context.md - Current State & Progress

Purpose: Living document of current state, decisions, and progress

Contains:

• SESSION PROGRESS (updated frequently)
• Key decisions made
• Important discoveries
• Current blockers
• Files modified
• Quick resume instructions

Update frequency: After each significant change or decision

Example:

# Authentication Implementation Context

## SESSION PROGRESS (2025-01-15 14:30)

### ✅ COMPLETED
- [x] Supabase Auth configured
- [x] Created auth middleware for Edge Functions
- [x] Implemented login/signup pages
- [x] Added auth context provider

### 🟡 IN PROGRESS
- [ ] Implementing token refresh logic (CURRENT)
  - Working on: lib/supabase/auth.ts
  - Next: Handle token expiration gracefully

### ⏳ PENDING
- [ ] Add RLS policies
- [ ] Migrate existing users
- [ ] Add mobile auth flow
- [ ] Write auth tests

### 🎯 NEXT ACTION
Continue implementing refreshToken() function in lib/supabase/auth.ts
- Handle expired tokens
- Refresh transparently
- Redirect to login if refresh fails

## KEY DECISIONS

### Decision: JWT vs. Session Cookies (2025-01-12)
**Chose**: JWT tokens
**Rationale**: Need stateless auth for mobile apps
**Impact**: Requires token refresh mechanism

### Decision: Supabase Auth vs. Custom (2025-01-13)
**Chose**: Supabase Auth
**Rationale**: Built-in RLS integration, handles token refresh
**Impact**: Less custom code, tighter Supabase integration

## IMPORTANT DISCOVERIES

### Token Refresh Timing
Discovered tokens expire after 1 hour by default. Need to:
- Refresh proactively at 50 minutes
- Handle edge case of offline user
- Store refresh token securely

### RLS Row vs. Column Level
Supabase RLS is row-level only, not column-level.
For sensitive columns, need separate tables.

## CURRENT BLOCKERS

None currently. Auth flow is straightforward with Supabase.

## FILES MODIFIED

### Created
- lib/supabase/auth.ts (auth utilities)
- app/(auth)/login/page.tsx
- app/(auth)/signup/page.tsx
- components/auth/auth-provider.tsx

### Modified
- lib/supabase/client.ts (added auth hooks)
- middleware.ts (added auth middleware)

## QUICK RESUME

To continue this work:
1. Read this file (context.md) for current state
2. Check tasks.md for checklist
3. Refer to plan.md for overall strategy
4. Current file: lib/supabase/auth.ts
5. Next: Implement refreshToken() function
6. After that: Test token refresh flow

3. {task-name}-tasks.md - Actionable Checklist

Purpose: Granular, actionable tasks with acceptance criteria

Contains:

• Detailed task breakdown
• Acceptance criteria for each task
• Dependencies between tasks
• Task status (pending/in-progress/complete)

Update frequency: Daily or after completing tasks

Example:

# Authentication Implementation Tasks

## Phase 1: Supabase Setup ✅

- [x] Create Supabase project (Acceptance: Project created, credentials stored)
- [x] Enable Email auth provider (Acceptance: Can sign up via email)
- [x] Configure redirect URLs (Acceptance: Auth callbacks work locally + prod)
- [x] Add auth schema to database (Acceptance: Users table exists)

## Phase 2: Backend Auth 🟡

- [x] Create auth utilities (Acceptance: getUser(), signIn(), signUp() functions work)
- [ ] Implement token refresh **(IN PROGRESS)**
  - Acceptance: Tokens refresh automatically before expiry
  - Dependencies: Auth utilities complete
  - Notes: Need to handle offline case
- [ ] Add auth middleware to Edge Functions
  - Acceptance: Protected routes return 401 if not authenticated
  - Dependencies: Token refresh working
- [ ] Create auth helper for server components
  - Acceptance: Can check auth in Server Components

## Phase 3: Frontend Auth ⏳

- [x] Create auth context provider (Acceptance: Auth state available app-wide)
- [x] Build login page (Acceptance: Can log in with email/password)
- [x] Build signup page (Acceptance: Can create account)
- [ ] Add protected route wrapper
  - Acceptance: Redirects to login if not authenticated
  - Dependencies: Auth context complete
- [ ] Add loading states
  - Acceptance: Shows loading spinner during auth checks

## Phase 4: Security 🔒

- [ ] Add RLS policies
  - Acceptance: Users can only access their own data
  - Files: supabase/migrations/xxx_rls_policies.sql
- [ ] Test auth edge cases
  - Expired tokens
  - Invalid tokens
  - Network failures
  - Concurrent sessions

## Phase 5: Migration 📦

- [ ] Create migration script for existing users
- [ ] Test migration locally
- [ ] Schedule maintenance window
- [ ] Execute migration in production
- [ ] Verify all users migrated successfully

SESSION PROGRESS Pattern

The SESSION PROGRESS section is the most important part of context.md:

Structure

## SESSION PROGRESS (2025-01-15 14:30)

### ✅ COMPLETED
[What's done - be specific]

### 🟡 IN PROGRESS
[What you're working on RIGHT NOW]

### ⏳ PENDING
[What's coming next]

### 🚫 BLOCKED
[What's preventing progress - if any]

### 🎯 NEXT ACTION
[Specific next step with file + function]

Best Practices

DO ✅:

• Update after each significant milestone
• Be specific about current file/function
• Include "NEXT ACTION" for easy resume
• Mark completed items immediately
• Note blockers as they arise

DON'T ❌:

• Leave stale progress (update regularly)
• Be vague ("working on auth" → "implementing refreshToken() in auth.ts")
• Forget to mark completed items
• Skip the NEXT ACTION (critical for resume)

Update Frequency

| Event | Update SESSION PROGRESS? | |-------|-------------------------| | Completed a full task | ✅ Yes | | Significant decision made | ✅ Yes | | Discovered blocker | ✅ Yes | | Changed approach | ✅ Yes | | Switching to different task | ✅ Yes | | Minor code change | ❌ No | | Formatting/cleanup | ❌ No | | Reading code | ❌ No |

Quick Resume Instructions

Always include this section in context