Hey everyone ![]()
I recently built Waypoint, an open-source agent skill for engineering work that spans multiple coding-agent sessions.
The problem
Coding agents can be highly productive within a single session, but continuity becomes fragile when the work exceeds one context window.
A fresh session often has to reconstruct:
- what was originally approved;
- what has already been implemented;
- which decisions were made;
- what is blocked or waiting for a human;
- what should happen next;
- whether completed work was actually verified.
Chat summaries help, but I wanted execution state to live somewhere more durable, inspectable, and version-controlled.
What Waypoint does
Waypoint turns an approved implementation plan into local, resumable issues stored inside the project.
Instead of treating conversation history as the source of truth, each issue records:
- the intended outcome;
- approved plan and inherited context;
- dependencies;
- acceptance criteria;
- implementation decisions;
- progress checkpoints;
- verification evidence;
- human requests and responses;
- one exact next action;
- a fresh-session handoff.
This allows a new agent session to inspect the repository, validate the current state, and continue from a defined checkpoint rather than reconstructing the work from chat history.
Workflow
approved plan
↓
local issue sequence
↓
start one issue
↓
checkpoint progress
↓
pause for human input when required
↓
resume in the same or a fresh session
↓
verify acceptance criteria with evidence
↓
complete and unlock dependent work
Waypoint uses guarded state transitions:
planned → ready → in_progress → verification → done
│ │
├→ blocked │
└→ awaiting_human → in_progress
done → reopened → in_progress
Safety guards
Waypoint includes several controls for keeping long-running agent work reliable:
- Dependencies must be completed before dependent work starts.
- Active-work limits reduce accidental parallel ownership.
- Human-waiting issues cannot resume through a generic transition.
- Completion requires checked acceptance criteria and recorded evidence.
- Generated dashboard state is validated against issue files.
- Conflicting installer files are not overwritten without explicit approval.
Installation
npx skills add omorShahriar/waypoint
Then ask your coding agent:
Initialize Waypoint in this project.
Example prompts:
Use Waypoint to turn docs/plans/operator-console.md into local issues.
Use Waypoint to start S0.
Use Waypoint to checkpoint the current issue.
Use Waypoint to resume the current issue from its durable handoff.
Use Waypoint to verify S0 and complete it only if every acceptance criterion has evidence.
Current scope
Waypoint currently supports:
- local issue creation from approved plans;
- dependency-aware execution;
- guarded state transitions;
- durable checkpoints;
- human pause and resume;
- evidence-based completion;
- fresh-session handoffs;
- a generated project status dashboard.
It is project-agnostic, MIT licensed, requires Node.js 20+, and has no npm runtime dependencies.
Repository
github.com/omorShahriar/waypoint
I built Waypoint because I wanted coding-agent execution to remain understandable and resumable even after the original conversation disappears.
I would especially value feedback from developers using agents for real, multi-session implementation work:
- Does repository-local execution state fit your workflow?
- Is the issue lifecycle too strict, not strict enough, or appropriately guarded?
- What information does your agent usually lose when moving into a fresh session?
- Which coding agent should I test and document more deeply next?