Website permissions — fewer prompts, same guardrails

A build is a tight loop of npm/astro/playwright/git calls. Approving each one by hand is friction with little safety benefit for the exact commands the skills run every day. This skill gets the repo to "quiet for the safe stuff, blocked for the dangerous stuff", and keeps it that way as the project grows.

1. Install the bundled allowlist (the 90% fix)

The new-website kit ships a curated .claude/settings.json. Copy it into the repo (this is also scaffold step 3.2 — do it here if it was skipped). This skill carries its own copy of the two files, in its templates/claude/ folder, so the step works from the copy of the skill inside a site too. In the commands below, the name in braces stands for the folder this SKILL.md is in: Claude Code fills it in; with another assistant, put that folder's path in its place.

: "${CLAUDE_SKILL_DIR:=}"
mkdir -p .claude/hooks
cp "${CLAUDE_SKILL_DIR}/templates/claude/settings.json" .claude/settings.json
cp "${CLAUDE_SKILL_DIR}/templates/claude/hooks/git-stand.mjs" .claude/hooks/

The settings also register a sync hook (.claude/hooks/git-stand.mjs, AGENTS.md §1): copy the script with them, or every session start reports a missing file. A repo whose .claude/settings.json already has its own rules: merge the template's hooks block in instead of overwriting the file.

When merging, also delete the broad rules older sites carry, which this list dropped in 2026-11. Delete these from the site's allow if they are there: Bash(node:*), Bash(npm exec:*), Bash(rg:*), Bash(find:*), Bash(tree:*), Bash(mv:*), Bash(open:*), the image tools (cwebp, dwebp, avifenc, magick, convert, oxipng, jpegoptim, svgo, exiftool, each :*), and git commit, branch, checkout, switch, init, merge, restore, stash, remote, fetch, pull and push, each Bash(git <verb>:*). Then add the template's exact git rules, Bash(node --version) and its three new deny rules.

.claude/settings.json is per-project and committed, so it travels with the repo — the handoff party inherits the same quiet loop. Restart Claude Code (or reload the project) after editing so the new rules take effect.

2. The model — what's pre-approved vs always gated

Pre-approved (allow) — the build loop and read-only inspection: npm install/ci/run/test, astro, playwright, node --version, git's read verbs and add (status, diff, log, show, rev-parse, add), the exact git commands the skills give (git init, git checkout main, git checkout -b production, git checkout -- .gitignore, git switch main, git switch -, git fetch, git fetch origin, git pull, git pull --ff-only, git pull --no-rebase, git push, git push -u origin main, git push -u origin production, git push --dry-run origin HEAD:main), gh read verbs (auth status, repo view, pr view/list) plus one write, gh repo create, wrangler pages dev / whoami, file inspection (ls/cat/head/tail/wc/grep, plus mkdir/cp/touch/echo), and bash scripts/check_external_links.sh (the outgoing-link sweep). Everything else asks: git commit, a new working branch and its first push (only production is made without asking, and only main and production get their first push without asking), other node commands, and the image tools among them.

Blocked (deny) — irreversible or destructive. Claude Code refuses these outright, it does not ask; the owner runs one by hand in a terminal if they really mean it: rm -rf, the usual force pushes (--force, --force-with-lease, -f or a +branch, wherever it stands in the command), git reset --hard, gh repo delete, wrangler pages delete, wrangler delete, any git command with a word starting --output (git log/diff/show writing a file), and git add reading its paths from a file (--pathspec-from-file). Do not move these to allow. A rule only matches text, so these catch the usual spellings; a push with options the list does not name, a bundled force flag (git push -uf) among them, asks rather than runs. Where website-team-setup could set GitHub's branch rules (§5-A: a public repo, or a private one on a paid plan), its rule against force pushes (non_fast_forward) makes GitHub refuse a force push to main whatever the command looks like (GitHub's Block force pushes rule; not tested by this kit). A free private repo gets only the local pre-push guard (§5-B), which --no-verify skips.

3. Extend it safely when a new prompt recurs

When you keep approving the same command, add it — but narrowly:

• Add the exact command you keep approving, e.g. Bash(git remote -v), not Bash(git remote:*), not Bash(*) and never a bare Bash. A :* rule allows whatever follows the command, options that write files or run programs included. A command whose words change each time, such as the first push of a new branch, cannot be approved ahead this way: approve it when it comes up.
• Never re-add a rule the 2026-11 change removed (the list in §1), however often its command comes up.
• Let the built-in do the scan. /fewer-permission-prompts reads your recent transcripts and proposes a prioritized allowlist from what you actually approved — run it, then keep only the exact rules that fit the rules above. Use /update-config (or hand-edit .claude/settings.json) to apply changes.
• Never add Bash(curl:*) or other broad network/exec wildcards to the project allowlist. The link sweep already runs curl inside its allowed script, so no separate curl grant is needed.
• Keep secrets out of settings. Tokens/keys belong in env or a gitignored file, never in .claude/settings.json (it's committed).

4. Where rules live (precedence)

• .claude/settings.json — project, committed, travels with the repo (use this).
• .claude/settings.local.json — project, gitignored, for personal-only rules.
• ~/.claude/settings.json — your global default across every project.

Project rules layer on top of global. Put repo-specific build grants in the project file so the handoff party gets them; keep machine-specific paths in the .local file.

Scope note

This skill manages the permission allowlist, not what the commands do. For automated behaviours (run X after Y) you need hooks via /update-config, not an allowlist entry.