resume

Resumes an approved swarm plan from current state after reconciling stale worktrees and context.

Updated Sep 14, 2026
One-click install
npx skills add https://github.com/pandejesal/drone-nav-sar --skill resume-pandejesal
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: resume
Source: https://github.com/pandejesal/drone-nav-sar/tree/main/.swarm/bundled-skills/resume
Command: npx skills add https://github.com/pandejesal/drone-nav-sar --skill resume-pandejesal

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When returning to an interrupted swarm project, stale worktrees, orphaned git branches, and mismatched swarm identities can corrupt the resumed run. This protocol safely continues an existing approved plan from its current state by cleaning up leftover session artifacts before execution. ## Core Features & Use Cases - Plan State Detection: Reads .swarm/plan.md to determine whether to resume an existing project or start a new one via MODE: SPECIFY. - Swarm Identity Reconciliation: Detects when the plan's Swarm field differs from the active swarm id, updates plan.md and context.md, and purges stale memory blocks and SME cache entries. - Stale Worktree Cleanup: Prunes or adopts orphaned .swarm-worktrees/ lane directories and swarm-lane/* git branches via the /swarm reset-session recovery command. - New Project Bootstrap: For new projects, runs complexity_hotspots, todo_extract, and sbom_generate to build a risk map and dependency baseline. - Use Case: You return to a project after a session crash and find leftover lane branches; the protocol cleans them up and resumes at the current task without manual intervention. ## Quick Start Resume my existing swarm project from where the plan left off, cleaning up any stale worktree state first.

Frequently Asked Questions about resume

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I resume an interrupted swarm project plan?

Resume by loading the RESUME protocol, which reads .swarm/plan.md, verifies the Swarm field matches the active swarm id, cleans stale worktree state, and continues at the current task. If no plan exists, it proceeds to MODE: SPECIFY for a new project.

What happens when the plan's swarm id differs from the active swarm?

The protocol updates the plan's Swarm field via save_plan, purges memory blocks referencing the other swarm's identity, deletes the stale SME Cache from context.md, and informs the user that stale context was cleared before resuming.

How are stale git worktrees and branches cleaned up before resuming?

Cleanup is driven by the /swarm reset-session recovery command, which internally runs cleanupOrphanedBranches to prune or adopt stale .swarm-worktrees/ lane directories and swarm-lane/* branches left from the prior session.

What happens if no plan.md exists when resuming?

The protocol treats it as a new project and proceeds to MODE: SPECIFY. It then runs complexity_hotspots for a 90-day risk map, optionally todo_extract for technical debt, and sbom_generate to capture a baseline dependency inventory.

Should I edit plan.md manually when switching swarms?

No. plan.md is a derived projection and must not be hand-edited. The protocol updates the Swarm field through the save_plan tool so the plan stays consistent with the active swarm identity.