Summary
The skill already has a clean handoff pattern for state it doesn't own: "For state owned by a package
manager, plugin manager, browser, IDE, cloud-sync client... research its documented dry-run/prune/GC
command and report the handoff."
Encountered live during an audit session: a repos root containing .worktrees/ with multiple git
worktree checkouts — clearly VCS-tracked, clearly out of scope for a generic junk engine (VCS metadata
protection already keeps the engine from touching it), but nothing in the skill actively points the
operator at /source-control:worktree cleanup/status, the plugin that actually owns worktree
lifecycle. Not a safety issue — just a discoverability gap that leaves an operator staring at an
unexplained truncated-path entry with no next step.
Suggested direction
Extend the same "managed state → named handoff" pattern already used for package managers to VCS
worktree directories, pointing at /source-control:worktree.
Summary
The skill already has a clean handoff pattern for state it doesn't own: "For state owned by a package
manager, plugin manager, browser, IDE, cloud-sync client... research its documented dry-run/prune/GC
command and report the handoff."
Encountered live during an audit session: a repos root containing
.worktrees/with multiple gitworktree checkouts — clearly VCS-tracked, clearly out of scope for a generic junk engine (VCS metadata
protection already keeps the engine from touching it), but nothing in the skill actively points the
operator at
/source-control:worktree cleanup/status, the plugin that actually owns worktreelifecycle. Not a safety issue — just a discoverability gap that leaves an operator staring at an
unexplained truncated-path entry with no next step.
Suggested direction
Extend the same "managed state → named handoff" pattern already used for package managers to VCS
worktree directories, pointing at
/source-control:worktree.