agentsclimarketplace

Session open

Skill Oldvictech/session-continuity/session-open

Three Claude skills for keeping long projects coherent across chat sessions: verified handovers (session-close / session-open) and a canonical roadmap visualizer.

Install
npx -y skills add Oldvictech/session-continuity --skill session-open

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Get a fresh chat current on an ongoing project with minimum lost time, verification-first. Reads the project's canonical state files, optionally runs one targeted search of past conversations, verifies load-bearing claims before acting on them, then orients the user in plain language — ending with a reasoned recommended next action. Use when the user says "catch up", "get up to speed", "onboard me", "where did we leave off", "here's the handover", "continuing from a previous session", "/open", or "/handover-in". The RECEIVING half of a session-continuity pair — see session-close for the outgoing half.

SKILL.md

4.7 KB, as published. Nobody here has run it

Session Open

Absorb a handover the right way: descend from cheap-and-ambient to authoritative, verify what's load-bearing, translate the state for the user, recommend a next step, then wait for their call.

CONFIGURATION (adapt to your project)

Name your project's canonical files here. Defaults that work well:

  • ROADMAP.md — the plan: sequence, status, gates, pending decisions
  • TASKS.md — current actionable items
  • Latest HANDOVER — the previous session's delta (written by session-close)
  • (optional) an operating-model or conventions doc, a decision log, a ledger of shipped work, style/process guides your project follows

If your project has a second execution environment (a CLI agent, a build server, a separate machine) whose disk is the ground truth, name it too — it is "the implementation channel" below. If you have none, skip the probe step; the canonical files are your highest tier.

The trust ladder (read in increasing order of authority)

  1. Ambient memory / chat context — what this conversation already believes. A summary; possibly stale. Baseline only.
  2. Canonical files — the durable record. Overrides memory wherever they differ.
  3. Ground truth — the implementation channel's disk (real file state, hashes, test results), if one exists. The final authority; everything else is a claim.

When tiers disagree, the higher tier wins. Never act on a tier-1 belief as if it were tier-3 verified. A report is a claim; the artifact is evidence.

Step 1 — Read the canonical files (+ one targeted past-chat search)

Read the canonical files. If the handover references something it doesn't explain ("the X trap", "why Y was reverted") and past-conversation search is available, run ONE focused search to resolve it — a targeted query, not a sweep. Skip if nothing is unclear.

If a file is missing from where you look first, try the project's other access paths (mounted copies can lag an uploaded knowledge base) before concluding it doesn't exist.

Step 2 — Verify load-bearing claims before acting on them

Identify what this session will act on first: anything the handover tagged UNVERIFIED, any status the next action depends on, any number about to be cited.

  • If an implementation channel exists: draft a READ-ONLY probe (no edits, no long jobs) asking for on-disk facts only — "report what is on disk; do not infer." Scope it to what the session will act on, not everything pending — each probe costs the user a round-trip. If several items qualify, ask the user which they'll work on, then probe that. Present the probe as a copy-pasteable block.
  • If none exists: treat the canonical files as top tier, and explicitly tag anything that is only asserted in the handover as UNVERIFIED in your orientation.

Step 3 — Orient the user, recommend, then wait

## Caught up — <date>

### Where we are (plain language)
[2-4 sentences anyone can act on: state, what last session did, what's next.]

### Verified
[Facts confirmed against the highest available tier — safe to act on.]

### Unverified or desynced
[Claims the probe did NOT confirm, or places the tiers disagree.
Flag them; don't resolve silently.]

### Decisions waiting on you
[Open decisions from the roadmap/tasks, each framed: the choice, the tradeoff,
a recommendation.]

### Recommended next action
[A concrete recommendation WITH reasoning — what to do first, what it unblocks,
what it costs. If two options are close, give both with the tradeoff.
End with: "Confirm and I'll proceed, or redirect me."]

Then wait for confirmation or redirection. Recommend actively — the user expects a reasoned proposal, not a menu — but the user decides.

Rules

  • Descend memory → canonical files → ground truth; the higher tier always wins.
  • One targeted past-chat search, not a fishing expedition.
  • Verify load-bearing facts BEFORE acting; tag what you could not verify.
  • Surface desyncs between tiers; never resolve them silently.
  • Translate for the user; frame decisions as decisions.
  • End with a reasoned recommendation, then wait for confirmation or redirection.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.