From vector-memory
This skill should be used when the user asks to "set a waypoint", "save my progress", "save session state", "load waypoint", "resume work", "where were we", "what was I working on", "start a new session", "switch tasks", mentions "session persistence", "context management", or discusses when and how to use waypoints effectively. Provides guidance on the waypoint lifecycle for session continuity.
How this skill is triggered — by the user, by Claude, or both
Slash command
/vector-memory:waypoint-workflowThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Waypoints capture a structured snapshot of session state — what was accomplished, what decisions were made, and what comes next. They enable seamless session resumption across context boundaries.
Waypoints capture a structured snapshot of session state — what was accomplished, what decisions were made, and what comes next. They enable seamless session resumption across context boundaries.
A waypoint is NOT a memory. Memories are individual facts, decisions, or insights stored via mcp__vector-memory__store_memories. A waypoint is a session-level summary that ties memories together with project state, providing a resume point.
Waypoint = Session State Snapshot
Set a waypoint whenever a logical unit of work finishes:
Anti-pattern: Setting a waypoint mid-task creates confusing resume points. Wait for a natural stopping point.
Always set a waypoint before running /clear. Context clearing without a waypoint means losing all session state. The plugin's /clear detection hook provides a safety net, but explicitly setting one is better practice.
When pivoting to a different area of work, set the current state first. This preserves the mental model of the previous task for clean resumption later.
Long sessions accumulate context that becomes expensive to reconstruct. Set waypoints periodically to create recovery points. The plugin's context monitor warns at 50% and 75% context usage — treat these as waypoint prompts.
At the beginning of each session, load the waypoint to restore context. The plugin's SessionStart hook suggests this automatically. To continue previous work, accept; to start fresh, decline.
If context was cleared mid-project, load the waypoint to restore orientation.
When resuming work on a project after time away, the waypoint provides faster orientation than re-reading code.
Waypoints and memories serve different purposes and work together:
Extract memories first — review the session for significant decisions, insights, patterns, and blockers. Store each as an individual memory via mcp__vector-memory__store_memories with appropriate metadata type tags (decision, implementation, insight, blocker, next-step, context).
Then set the waypoint — call mcp__vector-memory__set_waypoint with the summary, completed items, next steps, and the memory IDs returned from step 1.
On load, both are retrieved — /waypoint:get loads the waypoint AND searches for relevant memories, plus fetches any specifically linked memory IDs.
This two-step process ensures individual insights persist as searchable memories while the waypoint provides the session-level narrative that ties them together. See the vector-memory-usage skill for guidance on writing high-quality memories.
src/middleware/auth.ts, passing all 12 tests" is better than "worked on auth"/api/login endpoint" is better than "improve security"/clear to prevent data lossmcp__vector-memory__store_memories first, then reference their IDs in the waypointA well-structured waypoint looks like this:
project: "acme-api"
branch: "feature/user-auth"
summary: "Implemented JWT-based authentication with refresh tokens. All 18 auth tests passing. Ready to add rate limiting."
completed:
- "JWT auth middleware in src/middleware/auth.ts with RS256 signing"
- "Refresh token rotation in src/services/token.service.ts"
- "Auth routes: POST /login, POST /refresh, POST /logout in src/routes/auth.ts"
- "18 tests passing in tests/auth.test.ts"
in_progress_blocked:
- "Rate limiting design not started yet"
key_decisions:
- "Chose JWT over sessions because API is stateless and serves mobile clients"
- "Used RS256 (asymmetric) over HS256 for future microservice token verification"
- "Refresh tokens stored in httpOnly cookies, not localStorage, for XSS protection"
next_steps:
- "Add rate limiting to /login endpoint (consider express-rate-limit)"
- "Add password reset flow"
- "Set up CI pipeline for auth tests"
memory_ids:
- "mem_a1b2c3"
- "mem_d4e5f6"
The recommended workflow for each work session:
1. Session starts → Load waypoint (/waypoint:get)
2. Work on tasks
3. Context monitor warns at 50% → Consider setting a waypoint soon
4. Complete discrete task → Set waypoint (/waypoint:set)
5. Clear context (/clear) → Fresh context for next task
6. Repeat from step 1
This cycle prevents context rot, keeps token usage efficient, and ensures memories remain high-quality.
| Command / Tool | Purpose |
|---|---|
/waypoint:get | Load waypoint + recent git activity + relevant memories |
/waypoint:set | Extract memories from session, then set waypoint snapshot |
mcp__vector-memory__set_waypoint | Underlying MCP tool for storing waypoint data |
mcp__vector-memory__get_waypoint | Underlying MCP tool for retrieving the latest waypoint |
mcp__vector-memory__store_memories | Store individual memories before setting waypoint |
mcp__vector-memory__search_memories | Search for relevant memories during waypoint load |
npx claudepluginhub aeriondyseti/vector-memory-mcp --plugin vector-memorySaves session progress by committing changes, pushing to remote, creating/updating pull requests, persisting decisions/patterns to memory layers, compiling briefings, and archiving features. Use for checkpointing work or PRs.
Wraps up a work session by recording changed files, caveats, decisions, and next steps so a fresh session can resume without re-deriving context.
Saves session state and writes a handoff note so the next Claude Code session can continue cleanly. Read/writes a remember.md file at the project root.