Scaffold the /x-wt-teams worktree-development setup into the current repo: a pre-push git hook that blocks pushes from worktrees/, an installer wired into pnpm/npm install, lefthook for pre-commit hooks, and a root CLAUDE.md section documenting the policy. Use when: (1) User says 'scaffold wt-dev', 'install worktree push guard', 'set up x-wt-teams here', 'add wt-dev to this repo', 'block worktree pushes', (2) Preparing a new repo for /x-wt-teams multi-topic development, (3) The user wants child agents in worktrees to be mechanically prevented from pushing instead of relying on prompt instructions.
Scaffold the /x-wt-teams worktree-development setup into the current repo: a pre-push git hook that blocks pushes from worktrees/, an installer wired into pnpm/npm install, lefthook for pre-commit hooks, and a root CLAUDE.md section documenting the policy. Use when: (1) User says 'scaffold wt-dev', 'install worktree push guard', 'set up x-wt-teams here', 'add wt-dev to this repo', 'block worktree pushes', (2) Preparing a new repo for /x-wt-teams multi-topic development, (3) The user wants child agents in worktrees to be mechanically prevented from pushing instead of relying on prompt instructions.
user-invocable
true
allowed-tools
["Bash","Read","Write","Edit","Glob","Grep"]
Scaffold worktree-development setup (wt-dev)
Install the repo-scoped pieces that make /x-wt-teams reliable:
lefthook manages pre-commit hooks via lefthook.yml (lint-staged wired in only if the repo already uses it)
A direct pre-push guard in .git/hooks/pre-push blocks pushes from worktrees — deliberately NOT in lefthook.yml because lefthook reads config from the worktree's toplevel and would silently skip the guard when invoked from inside a worktree
scripts/install-git-hooks.sh installs the pre-push guard idempotently; wired into prepare and init-worktree
Root CLAUDE.md section documents the policy for agents
All four pieces are tightly coupled — install all of them, not a subset.
No package.json: the prepare lifecycle hook doesn't apply. Install lefthook globally or document manual steps. Continue with the scaffold but skip Step 4.
Pre-existing .git/hooks/pre-push without our marker: tell the user; if they confirm, move it aside (mv .git/hooks/pre-push .git/hooks/pre-push.bak) before running the installer.
core.hooksPath is set (e.g. to .husky/_): must be unset first. Edit .git/config to remove the hooksPath line under [core]. Without this, neither lefthook's hooks nor the pre-push guard will fire.
lefthook.yml already exists: merge the pre-commit block into it rather than overwriting (Step 3).
worktrees/ not in .gitignore: add it as part of Step 5.
Step 2: Copy the scripts
Copy these two files from the skill assets to the target repo. Preserve executable bits.
Both files are repo-agnostic — no patching needed.
Step 3: Create or update lefthook.yml
First, detect whether this repo already uses lint-staged. Any of these is a signal that lint-staged is configured:
# Config files at the repo rootls .lintstagedrc .lintstagedrc.{js,cjs,mjs,json,yaml,yml} lint-staged.config.{js,cjs,mjs} 2>/dev/null
# Top-level "lint-staged" key OR lint-staged listed as a (dev)dependency in package.json
[ -f package.json ] && python3 -c "import json; p=json.load(open('package.json')); print('yes' if 'lint-staged' in p or 'lint-staged' in (p.get('dependencies') or {}) or 'lint-staged' in (p.get('devDependencies') or {}) else 'no')"
If lint-staged is configured — create lefthook.yml with the lint-staged command:
If lint-staged is NOT configured (the common case for new repos) — create lefthook.yml with an empty slot. Do NOT default-include lint-staged: pnpm dlx lint-staged; without a config it fails every commit:
# lefthook manages pre-commit hooks here. Add commands under# `pre-commit.commands` when this repo needs them, e.g. lint-staged.## The pre-push worktree guard is intentionally NOT managed by lefthook —# it lives in scripts/hooks/pre-push and is installed directly to# .git/hooks/pre-push by scripts/install-git-hooks.sh (run by `pnpm install`# via the `prepare` script). See CLAUDE.md "Worktree push policy" for the# rationale.pre-commit:commands: {}
If lefthook.yml already exists, leave its existing pre-commit block alone (do not overwrite, do not inject lint-staged). Add a pre-commit block only if one isn't there. Do NOT add a pre-push block — the guard runs outside lefthook for the reason stated above.
That the verification worktree push was blocked as expected.
That nothing was committed — they should git add and commit when they're ready.
Idempotency
Re-running this skill on a repo that already has it scaffolded is safe:
cp overwrites script files with identical content (no diff on first re-run; pulls updates if the skill has been updated upstream).
package.json changes are idempotent — Edit tool will be a no-op if the keys are already present with the right values.
CLAUDE.md detection (Step 7) skips when the section is already present.
The installer is idempotent.
When NOT to use this skill
The repo doesn't use /x-wt-teams at all. The hook is harmless but the CLAUDE.md section talks about a workflow that's not in play.
The repo has a non-standard worktrees/ layout (e.g., worktrees elsewhere on disk). The hook's detection uses GIT_DIR != GIT_COMMON_DIR (any linked worktree), so path naming doesn't matter for detection — but the CLAUDE.md section references worktrees/ as the convention.
