skills/dev-scaffold-wt-dev/SKILL.md
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.
npx skillsauth add takazudo/claude-resources dev-scaffold-wt-devInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
wt-dev)Install the repo-scoped pieces that make /x-wt-teams reliable:
lefthook.yml (lint-staged wired in only if the repo already uses it).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 worktreescripts/install-git-hooks.sh installs the pre-push guard idempotently; wired into prepare and init-worktreeCLAUDE.md section documents the policy for agentsAll four pieces are tightly coupled — install all of them, not a subset.
Run from the target repo root:
git rev-parse --show-toplevel >/dev/null 2>&1 || { echo "Not a git repo"; exit 1; }
ls package.json 2>/dev/null
ls .git/hooks/pre-push 2>/dev/null
grep -q "^worktrees/" .gitignore 2>/dev/null && echo "(worktrees/ already gitignored)"
ls lefthook.yml 2>/dev/null && echo "(lefthook.yml already exists)"
cat package.json | python3 -c "import json,sys; p=json.load(sys.stdin); print(p.get('scripts',{}).get('prepare','(no prepare)'))"
Decide:
package.json: the prepare lifecycle hook doesn't apply. Install lefthook globally or document manual steps. Continue with the scaffold but skip Step 4..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.Copy these two files from the skill assets to the target repo. Preserve executable bits.
SKILL_DIR="$HOME/.claude/skills/dev-scaffold-wt-dev"
mkdir -p scripts/hooks
cp "$SKILL_DIR/assets/scripts/hooks/pre-push" scripts/hooks/pre-push
cp "$SKILL_DIR/assets/scripts/install-git-hooks.sh" scripts/install-git-hooks.sh
chmod +x scripts/hooks/pre-push scripts/install-git-hooks.sh
Both files are repo-agnostic — no patching needed.
lefthook.ymlFirst, detect whether this repo already uses lint-staged. Any of these is a signal that lint-staged is configured:
# Config files at the repo root
ls .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:
pre-commit:
commands:
lint-staged:
run: pnpm dlx lint-staged
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.
For repos with package.json:
[ -f pnpm-lock.yaml ] && PM=pnpm
[ -f package-lock.json ] && PM=npm
[ -f yarn.lock ] && PM=yarn
[ -f bun.lockb ] && PM=bun
PM=${PM:-pnpm}
Set:
INSTALL_COMMAND → ${PM} installINIT_WORKTREE_COMMAND → ${PM} run init-worktree (npm/yarn/bun) or pnpm init-worktree (pnpm shorthand)package.json scripts (skip if no package.json)Add two scripts. Use the Edit tool — preserve key order, do not rewrite the whole file:
{
"scripts": {
"prepare": "lefthook install && bash scripts/install-git-hooks.sh",
"init-worktree": "bash scripts/install-git-hooks.sh"
}
}
If the repo already has a prepare script:
pnpm dlx husky (Husky): replace it entirely (migrate to lefthook). Remove .husky/ directory. Tell the user.&&: "prepare": "<existing> && lefthook install && bash scripts/install-git-hooks.sh". Tell the user.# pnpm
pnpm add -Dw lefthook
# npm
npm install -D lefthook
# yarn
yarn add -D lefthook
CLAUDE.mdRead $HOME/.claude/skills/dev-scaffold-wt-dev/assets/claude-md-section.md. Substitute the placeholders:
<INSTALL_COMMAND> → from Step 4<INIT_WORKTREE_COMMAND> → from Step 4Then:
CLAUDE.md at repo root: create it. Add a one-line top heading (# <repo-name> — repo rules) before the worktree section.CLAUDE.md exists but has no worktree section (grep for Worktree push policy): append the section to the end with a blank line before it.Also add worktrees/ to .gitignore if not already present:
grep -q "^worktrees/" .gitignore 2>/dev/null || echo "worktrees/" >> .gitignore
bash scripts/install-git-hooks.sh
Expected: install-git-hooks: installed <path>/.git/hooks/pre-push.
Verify the guard works. Create a throwaway worktree, attempt a push, confirm it's blocked, then clean up:
git worktree add worktrees/_pushguard-poc -b _pushguard-poc 2>&1 | tail -2
cd worktrees/_pushguard-poc
git commit --allow-empty -m "test"
git push origin _pushguard-poc 2>&1 | head -5
# Expected: 'Push blocked — you are in a /x-wt-teams worktree.' and exit non-zero.
cd ../..
git worktree prune
git branch -D _pushguard-poc
If the push isn't blocked, diagnose:
.git/hooks/pre-push exists and is executable?core.hooksPath is unset (check cat .git/config | grep hooksPath)?git rev-parse --git-dir and --git-common-dir differ inside the worktree?Tell the user concisely:
scripts/install-git-hooks.sh, scripts/hooks/pre-push, lefthook.yml, package.json (if applicable), root CLAUDE.md, .gitignore.git add and commit when they're ready.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./x-wt-teams at all. The hook is harmless but the CLAUDE.md section talks about a workflow that's not in play.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.development
Link Claude Code skill names mentioned in a CodeGrid article (data/{series}/{n}.md) to the author's public claude-resources repo, pinned to the latest commit hash so links don't rot. Use when: (1) user says 'linkify cc resources', 'link the skills', 'link skill names', or invokes /dev-linkify-cc-resources; (2) editing a CodeGrid article that mentions `/commits`, `/pr-complete`, `/skill-creator` or other Claude Code skills and they should point to claude-resources. Only links skills that actually exist in the public repo; skips hypothetical examples and code blocks.
development
Second opinion from Claude Opus on a plan or approach. Use when: (1) Planning phase of /big-plan needs a higher-quality review than /codex-2nd / /gco-2nd, (2) User says 'opus 2nd' or 'opus opinion', (3) Wanting Anthropic's larger model to critique a plan. Spawns a general-purpose Agent with model: opus that reads the plan file and returns structured feedback. Anthropic quota — not free.
tools
AI-based testing via subagent + a per-task test-flow skill. Use when the user wants to verify something that mechanical assertions can't fully capture — image recognition, visual size/position comparison, animation smoothness, multi-step manual flows that need AI judgment. Triggers: 'AI-based test', 'AI test', 'visual verify', 'image recognition test', 'manual operation test', 'human-eye check', 'verify visually', 'compare screenshots', 'looks the same', 'looks correct'. The skill's job is to (1) author a focused test-flow skill that captures the exact procedure + verdict criteria, then (2) dispatch a verification subagent via the Agent tool that loads BOTH the test-flow skill AND a browser-driving skill (/verify-ui primary, /headless-browser fallback) so the subagent has clear context and consistent verdicts. NEVER uses `claude -p` — subagent dispatch goes through the Agent tool exclusively.
development
End-of-workflow audit of touched GitHub issues, PRs, and branches via a Sonnet subagent. Use when: (1) /big-plan, /x-as-pr, or /x-wt-teams finishes its main work and needs to verify every touched resource is in the right state (closed when done, kept when ongoing, deleted when dead), (2) User says 'cleanup resources', 'audit cleanup', or 'check what should be closed', (3) A long workflow ends and the manager wants a structured paper trail of what it closed/kept/deleted. Auto-execute by default — the Sonnet agent proposes, the manager (you) executes safe actions and prints a final report.