repo-worktree's hook step installs into the git hooks dir every worktree shares #1816

repo-worktree "Preparing Git Hooks" tells a session to run the hook installer from a new worktree's root. For Husky.Net that is safe, since core.hooksPath is the relative .husky and its generated runtime lives in each tree. For a repository using git's own hooks directory, such as the pre-commit framework or prek, a linked worktree has no hooks directory of its own: git rev-parse --git-path hooks resolves to the common .git/hooks. So the install rewrites the hook for every checkout of the repository, which is a mutation of the base clone that the same skill forbids.

Observed 2026-09-25 in Financial-Modeling: uvx prek install, run from a linked worktree, replaced the shared pre-commit-framework hook with a prek hook and moved the original to pre-commit.legacy in migration mode. From then on every commit in every checkout failed, when the chained legacy script exited with its migration-mode error. The auto-mode classifier correctly denied the agent's attempt to restore the shared file, so the repair falls to the maintainer.

A related hazard: git -c core.hooksPath=<path> commit in a linked worktree can point at a directory that does not resolve there, which skips every hook silently. That is --no-verify by another name, and gh-write-guard does not deny it.

Done looks like:

• "Preparing Git Hooks" checks the common directory first, test -x "$(git rev-parse --path-format=absolute --git-common-dir)/hooks/pre-commit", and skips the install where a hook is already present.
• It never installs or switches a hook installer from inside a linked worktree, since that changes the hook for every checkout, and it routes a missing or wrong shared hook to the maintainer.
• It states that a commit-time core.hooksPath override is a hook bypass.
• gh-write-guard denies the -c core.hooksPath= commit form as it denies --no-verify.

Reported by the Financial-Modeling session.