/session-context-rebuild

name: session-context-rebuild
description: "Merge multiple sessions into one working context and detect conflicts between parallel sessions. Dispatches subagent swarm to read files touched, extract log history, and resolve contradictory state. Use when resuming after days away or when parallel sessions may have written conflicting decisions. For browsing or reviving individual sessions, use alive:session-history instead."
user-invocable: true

Session Context Rebuild

You're returning to work that spans multiple sessions — possibly conflicting ones. The context window is empty but the walnut isn't. This skill dispatches subagents to deeply reconstruct what happened, what changed, where conflicts exist, and what the merged state should be. Then you resume with full context as if you never left.

---

When to Use

• Returning to a walnut after days/weeks away
• Context was lost to compaction mid-session
• Multiple sessions touched the same walnut in parallel and need merging
• Picking up someone else's work in a shared walnut
• "What was I doing here?" moments

---

Process

Phase 1: Scout (single agent)

Dispatch one `general-purpose` subagent to map the territory. It reads the `session-history/SKILL.md` file and applies its browse logic against `.alive/_squirrels/`, then reports back:

• Which sessions touched this walnut, when, by whom (engine)
• Which files each session worked on (`working:` field in squirrel YAML)
• Which bundles were active
• Whether sessions overlap (parallel/conflicting work)
• Unsaved stash items from crashed sessions

**Cross-walnut detection:** the scout performs two queries, not one: 1. **Walnut-tagged match** — squirrel YAMLs where `walnut: {target}` (the obvious set) 2. **Routed-stash match** — squirrel YAMLs where any stash item's `routed:` field contains the target walnut name (catches maintenance sessions with `walnut: null` that routed work to this walnut)

Merge-deduplicate by session_id. Report both counts so the user sees "5 walnut-tagged + 1 cross-walnut routed" instead of just "5 sessions."

> **🐿️ context rebuild — scouting**
> Found 5 sessions on this walnut (last 2 weeks)
> 3 sequential, 2 overlapping (possible conflicts)
> 12 files touched, 2 bundles active
>
> ▸ Rebuild scope?
> 1. All 5 sessions (full rebuild)
> 2. Last 3 only
> 3. Just the 2 conflicting sessions

Phase 2: Deep Read (agent swarm)

Based on scope, dispatch parallel subagents — one per session or one per domain:

**Agent assignments:**

| Role | `subagent_type` | Purpose | |------|----------------|---------| | **Log agent** | `Explore` | reads `_kernel/log.md`, extracts all entries from sessions in scope. Returns decisions, rationale, timestamps. | | **File agents** (1 per bundle/area) | `Explore` | reads the actual files listed in `working:` fields. Returns current state, what changed, any draft versions. | | **Task agent** | `general-purpose` | uses `tasks.py list` to query task state. Returns what's done, what's in progress, what's blocked. | | **People agent** | `Explore` | extracts all person mentions from log entries and stash items. Cross-references with people walnuts if they exist. | | **Conflict agent** | `general-purpose` | reads both sessions' log entries and file changes side by side. Identifies contradictions: different decisions on the same topic, competing task states, divergent draft versions. |

Use `Explore` for pure-read roles (fast, no permission issues). Use `general-purpose` for roles that need Bash (tasks.py) or Write access (conflict resolution output).

Each agent returns structured findings. They don't summarise — they return the actual context with file paths, timestamps, and quotes.

Phase 3: Merge & Present

Combine all agent findings into a single reconstructed context:

> **🐿️ rebuilt context (5 sessions, 2 conflicts resolved)**
> Timeline:
> +-- 2026-03-10 (session:a8c) — Started competitor research bundle
> +-- 2026-03-12 (session:b4f) — Shortlisted 3 vendors, shared draft-01 with Sue
> +-- 2026-03-14 (session:c7d) — CONFLICT with session:d9e (same day)
> │   c7d: Changed pricing to per-seat model
> │   d9e: Kept usage-based pricing, added enterprise tier
> │   -> Recommended merge: per-seat with enterprise tier override
> +-- 2026-03-18 (session:e2f) — Final draft-03 written
>
> Current state:
> Bundle: competitor-research (draft-03)
> Key file: competitor-research/competitor-research-draft-03.md
>
> Open tasks (4):
> - [ ] Vendor site visits
> - [ ] Final pricing comparison
> - [ ] Sue's feedback on draft-03 (shared 2026-03-12, no response logged)
> - [ ] Enterprise tier pricing model (from conflict resolution)
>
> People: Sue Chen (shared draft), Ryn Okata (mentioned in vendor shortlist)
>
> Unresolved conflicts (1):
> - Pricing model: per-seat vs usage-based (sessions c7d/d9e)
>
> ▸ How to proceed?
> 1. Accept merged context, resume working
> 2. Resolve conflicts first
> 3. Show me the raw findings from each agent

Phase 4: Resume

On confirmation:

• The squirrel now holds full reconstructed context
• Unresolved conflicts are stashed as decisions-needed
• Any conflict resolutions are logged as decisions
• Work continues normally — stash, save, the whole flow

---

Conflict Detection

Two sessions conflict when:

• Both wrote to the same file (different versions)
• Both logged decisions on the same topic (contradicting)
• Both updated the same task (different states)
• Both modified `_kernel/now.json` with different `bundles.active`, `phase`, or recent-session entries (path: `_kernel/now.json`)

The conflict agent presents each side with evidence and recommends a merge. The human decides.

---

Agent Dispatch Strategy

Don't over-swarm. Scale agents to the rebuild scope:

| Scope | Agents | |---|---| | 1 session | 2 — log agent + file agent (no conflict possible) | | 2-3 sessions, no overlap | 3 — log + files + tasks | | 2+ sessions with overlap | 4-5 — log + files + tasks + people + confl