You send an agent off to rework authentication. It goes into the current branch - the very one holding your half-finished layout edit. Half an hour later you can no longer tell which changes are yours and which are its, or what of this is worth committing.
The remedy is well known and older than most agents: one repository can have several working trees. A separate directory, a separate branch, a shared object store. No second clone.
The using-git-worktrees skill from the Superpowers collection is interesting for something else - the Git mechanism has existed and been documented for years. What is interesting is the protocol built around it: how to tell that isolation already exists, who to yield to, what to check before creating anything, and what proves the workspace is clean. The difference between "the agent knows the command" and "the agent works safely with a repository" lives in exactly those details.
What git worktree actually does
Start with the mechanism, because without it the protocol does not read.
A repository can have one main working tree and any number of linked ones. The official documentation names them exactly so: the main worktree, made by git init or git clone, and linked worktrees, everything else. Linked trees share the repository's object store and refs, but each has its own working files, its own HEAD and its own index.
In its simplest form the command creates the branch for you:
The branch takes the name of the final path component - hotfix. To check out an existing branch, name it as the second argument. For throwaway experiments there is -d: a tree with a detached HEAD and no branch at all.
One constraint is worth knowing up front: the same branch cannot be checked out in two trees at once. The command refuses, and rightly so - otherwise two trees would be moving the same pointer.