@linchpinagency/skills 0.1.0

package/skills/project-context/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: project-context
+description: Orient before acting on a Linchpin project — identify the repo and branch, the local environment (Studio, wp-env, LocalWP), the host (Pressable or Cloudflare), the ClickUp space, and the release model, from .linchpin.json, composer.json, package.json, and the git remote. Use when starting work on an unfamiliar repo, before running commands that assume an environment, when a skill's Preflight needs the project's shape, or when something behaves differently than expected. Not for running the checks themselves.
+version: 1.0.0
+---
+
+# Project context
+
+Our projects are not uniform: WordPress plugin repos, `wp-content`-shaped site repos, and
+Cloudflare Workers services all live under the same conventions but expose different tools,
+environments, and hosts. **Guessing wrong is the most common way an agent wastes a session** —
+running `wp-env` on a Studio project, or looking for `phpcs.xml.dist` in a Workers repo.
+
+This is the one place that answers "what am I working in?". Other skills reference it from
+their Preflight instead of each re-deriving it.
+
+## When to use
+
+- Starting work on a repo you haven't touched this session.
+- Before any command that assumes an environment, host, or toolchain.
+- A skill's Preflight needs the project's shape.
+- Something behaves unexpectedly and the environment is a suspect.
+
+**Not this skill:** running lint or tests — [`quality-gates`](../quality-gates/SKILL.md).
+Operating the local site — [`wp-studio-cli`](../wp-studio-cli/SKILL.md). Operating the
+server — [`wp-pressable`](../wp-pressable/SKILL.md).
+
+## Owns
+
+Canonical for: what to read to identify a project, and what each signal means. Every other
+skill's Preflight should link here rather than restate the detection table.
+
+## The orientation pass
+
+Cheap, read-only, and worth doing once per session rather than per command:
+
+```bash
+git rev-parse --show-toplevel && git branch --show-current && git remote get-url origin
+ls .linchpin.json composer.json package.json phpcs.xml.dist .wp-env.json wrangler.toml 2>/dev/null
+```
+
+Then read what exists:
+
+| Signal | What it tells you |
+| --- | --- |
+| `.linchpin.json` | House metadata — plugin slug, declared local environments and their paths, preferred agent |
+| Repo root has `themes/` + `plugins/` and no core | A **site repo** — the repo *is* `wp-content` ([`wp-local-setup`](../wp-local-setup/SKILL.md)) |
+| A single plugin bootstrap file + `includes/` | A **plugin/product repo** (Mantle, linchpin-blocks) |
+| `wrangler.toml` | A **Cloudflare Workers** service — no PHP toolchain at all |
+| Site registered in Studio | Local env is **Studio** — the default ([`wp-studio-cli`](../wp-studio-cli/SKILL.md)) |
+| `.wp-env.json` / `.linchpin.json` environments | Legacy wp-env or LocalWP; predates the Studio switch — confirm before using |
+| `composer.json` scripts, `phpcs.xml.dist`, `phpstan.neon` | Which PHP gates exist ([`quality-gates`](../quality-gates/SKILL.md)) |
+| Nested `blocks/package.json`, `themes/*/package.json` | Builds run **in that workspace**, not the root |
+| `release-please-config.json` | Versions and `CHANGELOG.md` are machine-owned ([`commit-and-release`](../commit-and-release/SKILL.md)) |
+| `commitlint.config.js` | This repo's allowed commit types — they differ between repos |
+| Deploy workflows referencing Pressable | Hosted on Pressable ([`wp-pressable`](../wp-pressable/SKILL.md)) |
+| Git remote name | Infers the ClickUp space ([`task-tracking`](../task-tracking/SKILL.md)) |
+
+## What to report
+
+State the shape in one or two lines before doing the work, so the user can correct a wrong
+assumption before it costs anything:
+
+> `linchpin.com` on `issue/LINCHPIN-5210` — site repo (repo is `wp-content`), Studio local,
+> Pressable hosted, release-please. PHP gates: phpcs + phpstan. Nested builds under
+> `themes/linchpin` and `plugins/linchpin-functionality`.
+
+Then carry it for the session. Re-check only when the branch changes or something surprises
+you — this is orientation, not a per-command ritual.
+
+## Guardrails
+
+- **Never assume the environment from a config file's presence alone.** A leftover
+  `.wp-env.json` in a Studio project is history, not intent — when two exist, ask.
+- **Never infer the host from the repo name.** Read the deploy workflows.
+- **Never run an environment-changing command** (starting containers, creating sites) as part
+  of orientation. This pass is read-only.
+- **Never carry stale context across a branch switch** — base branch, gates, and task key can
+  all change.
+- If a signal is missing and the answer matters, say what's missing rather than picking the
+  most likely option silently.
+
+## Done
+
+- [ ] Repo root, branch, and remote identified.
+- [ ] Project shape known: site repo, plugin/product repo, or Workers service.
+- [ ] Local environment identified, and ambiguity resolved with the user rather than guessed.
+- [ ] Host and release model known before anything is shipped or deployed.
+- [ ] The shape was stated back to the user in a line or two.

package/skills/quality-gates/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: quality-gates
+description: Run a Linchpin project's own lint, coding-standards, static-analysis, and test gates before committing or opening a PR — detecting the toolchain from composer.json, package.json, phpcs.xml.dist and lint-staged rather than assuming it. Use when preparing to commit, when asked "is this ready to commit/ship", when CI lint or PHPCS is failing, when a pre-commit hook blocks you, or when a repo is missing the standard lint scripts. Not for writing the commit message — use `commit-and-release`.
+version: 1.0.0
+---
+
+# Quality gates
+
+Every Linchpin repo already declares how it wants to be checked — in `composer.json`
+scripts, `package.json` scripts, `phpcs.xml.dist`, `lint-staged.config.js`. Your job is to
+**find those declarations and run them**, not to invent commands. Getting this right is
+what makes the difference between a clean PR and a red CI run.
+
+The gates are the same ones CI runs, so passing here means passing there.
+
+## When to use
+
+- About to commit or open a PR.
+- The user asks whether a change is ready to ship.
+- CI lint / PHPCS / PHPStan failed and you need to reproduce and fix it locally.
+- A husky pre-commit hook is blocking a commit.
+- A repo is missing the house lint scripts and should get them.
+
+**Not this skill:** the commit message, branch, or release — [`commit-and-release`](../commit-and-release/SKILL.md).
+Upgrading packages — [`dependency-updates`](../dependency-updates/SKILL.md).
+
+## Owns
+
+Canonical for: which gates exist, how to detect them, the order they run in, and how to fix
+failures without suppressing them. Skills that end in a commit defer here for verification.
+
+## Preflight — detect, never assume
+
+Read these before running anything. Our repos genuinely differ: PHP-heavy plugin repos,
+`wp-content`-shaped site repos with nested builds, and JS/TS Workers projects all live under
+the same conventions but expose different gates.
+
+| Look for | Tells you | If missing |
+| --- | --- | --- |
+| `composer.json` → `scripts.lint` | The canonical PHP gate: `composer run lint` | Run the individual tools below that do exist |
+| `phpcs.xml.dist` or `phpcs.xml` | Coding standards are configured → PHPCS applies | **Skip PHPCS and say so** — never invent a standard |
+| `phpstan.neon(.dist)` | Static analysis applies | Skip; don't add it unprompted |
+| `.php-cs-fixer.dist.php` | PHP-CS-Fixer applies (`composer run fixer`) | Skip |
+| `package.json` → `scripts` | JS/CSS gates (`lint:js`, `lint:css`, `format`, `lint:check`) | Fall back to `eslint`/`prettier` only if configured |
+| `lint-staged.config.js` + `.husky/` | Pre-commit is already wired — **mirror those exact commands** | Run the scripts directly |
+| Nested `package.json` (e.g. `themes/*`, `plugins/*`, `src/`) | Gates run **in that workspace**, not the root | Root only |
+| `.linchpin.json` | Project metadata and local environments | Not every repo has one |
+
+Full command matrix: [`references/toolchain.md`](references/toolchain.md).
+
+## Procedure
+
+1. **Scope to what changed.** Staged: `git diff --name-only --cached --diff-filter=ACMR`.
+   Whole branch: diff against the merge base with `main`. Split into PHP, JS/TS, CSS/SCSS,
+   and config buckets. → You can name every changed file and which gate covers it.
+2. **PHP gate** (any `.php` changed). Prefer `composer run lint`. If absent, run only the
+   tools whose config exists: `composer run phpcs`, `composer run phpstan`,
+   `composer run fixer:test`. → Each command exits 0, or you have the exact violations.
+3. **JS / CSS gate** (any `.js`/`.ts`/`.css`/`.scss` changed). Prefer `npm run lint:check`
+   when defined; otherwise `npm run lint:js` and `npm run lint:css`. Run them in the
+   workspace that owns the file. → Exit 0 or a concrete rule violation list.
+4. **Tests** when the change touches covered code: `composer run phpunit`, `npm run test:unit`.
+   E2E (`npm run test:e2e`) only when asked or when the change is UI-facing — it needs a
+   running environment. → Green, or a named failing test.
+5. **Fix, don't silence.** Auto-fixers first (`composer run phpcbf`, `composer run fixer`,
+   `npm run format`), then re-run the gate; hand-fix what remains. → Gate passes with the
+   fix in the code, not in the config.
+6. **Report gaps, then hand off.** State which gates ran, which were skipped and why. If the
+   repo lacks a house script, propose it (see `references/toolchain.md`) and add it **only
+   with approval**. → Then go to [`commit-and-release`](../commit-and-release/SKILL.md).
+
+## Guardrails
+
+- **Never** commit with `--no-verify`. The hook is the gate; if it blocks you, fix the code.
+- **Never** silence a violation to make a gate pass — no widening `phpcs.xml.dist` excludes,
+  no new `phpcs:ignore` / `phpcs:disable` / `eslint-disable` / `@phpstan-ignore` without a
+  stated reason the user accepted, no editing a PHPStan baseline to hide a new error.
+- **Never** reformat files the change didn't touch. A formatting-only diff across the repo
+  buries the actual change and blows up review.
+- **Never** run `composer update` or `npm update` to fix a lint failure — that's a
+  dependency change ([`dependency-updates`](../dependency-updates/SKILL.md)), not a fix.
+- **Never** commit `vendor/`, `node_modules/`, or build output unless the repo already
+  tracks it — check `.gitignore` and `.distignore` first.
+- If a tool can't run (not installed, no config, requires Docker that isn't up), **say so
+  explicitly**. A silently skipped gate reads as a passing gate.
+
+## Done
+
+- [ ] Every changed file is covered by a gate that ran, or is explicitly reported as uncovered.
+- [ ] PHP gate passed (or is correctly not applicable — no `phpcs.xml.dist`, no PHP changed).
+- [ ] JS/CSS gate passed in the owning workspace (or correctly not applicable).
+- [ ] Tests run for touched, covered code.
+- [ ] No suppressions, config widenings, or `--no-verify` were used to get green.
+- [ ] Skipped gates and missing house scripts are named in the report.

package/skills/quality-gates/references/toolchain.md

@@ -0,0 +1,104 @@
+# Toolchain reference
+
+The commands Linchpin projects actually expose, and what to do when they're missing.
+**Run what the repo declares.** This file is a lookup table, not a script to run top to
+bottom.
+
+## PHP
+
+| Intent | Command | Requires |
+| --- | --- | --- |
+| Everything | `composer run lint` | `scripts.lint` in `composer.json` |
+| Syntax only | `composer run php-lint` | `php-parallel-lint` |
+| Coding standards | `composer run phpcs` (or `phpcs --standard=phpcs.xml.dist`) | `phpcs.xml.dist` |
+| Auto-fix standards | `composer run phpcbf` | same |
+| Formatting check | `composer run fixer:test` | `.php-cs-fixer.dist.php` |
+| Auto-fix formatting | `composer run fixer` | same |
+| Static analysis | `composer run phpstan` | `phpstan.neon(.dist)` |
+| Unit tests | `composer run phpunit` | `phpunit.xml(.dist)` |
+| Lint + tests | `composer run test` | both |
+
+The house `scripts.lint` composes `php-lint` → `phpcs` → `fixer:test` → `phpstan`, in that
+order — cheapest failure first. Reproduce that order when running tools individually.
+
+**PHPCS with no `phpcs.xml.dist`:** skip it and report it. Do not fall back to a global
+standard — the result won't match CI, and a WordPress-standard run against a non-WordPress
+codebase produces hundreds of meaningless violations.
+
+**PHPStan baselines:** `phpstan-baseline.neon` records accepted debt. New errors go in the
+code's fix, never in the baseline, unless the user explicitly asks to re-baseline.
+
+## JavaScript / CSS
+
+| Intent | Command | Notes |
+| --- | --- | --- |
+| Pre-commit equivalent | `npm run lint:check` | Where defined, this is `format` + `lint:js` |
+| JS/TS | `npm run lint:js` | `wp-scripts lint-js` on WordPress projects |
+| CSS/SCSS | `npm run lint:css` | `wp-scripts lint-style` |
+| Format | `npm run format` | Prettier via `wp-scripts format` |
+| Unit tests | `npm run test:unit` | |
+| E2E | `npm run test:e2e` | Playwright; needs a running environment |
+| Build | `npm run build` | Verify the change compiles before pushing |
+
+**Nested workspaces.** Site repos build per package — e.g. a theme and a functionality
+plugin each with their own `package.json`, sometimes an inner `src/`. Root scripts often
+delegate (`npm run build --prefix themes/<theme>`). Lint a file in the workspace that owns
+it; running the root script may silently skip it.
+
+**Non-WordPress projects** (Workers, Astro, API services) use `eslint.config.mjs` +
+`.prettierrc` directly. Same rule: run the declared `package.json` script.
+
+## Pre-commit hooks
+
+`husky` + `lint-staged` are the house pre-commit setup (`"prepare": "husky"`).
+
+- `lint-staged.config.js` is the source of truth for what runs on commit. When it exists,
+  **run the same commands it would run** — that's exactly what the hook will do.
+- Config files are often excluded from linting there. Don't "fix" a config file the
+  lint-staged rules deliberately skip.
+- A blocked commit means the gate found something real. Fix the code; never `--no-verify`.
+
+## The house script set
+
+When a repo is missing these, propose adding them — matching the repo's existing tooling,
+and only with the user's approval:
+
+```jsonc
+// package.json
+"scripts": {
+  "format":     "wp-scripts format",
+  "lint:js":    "wp-scripts lint-js",
+  "lint:css":   "wp-scripts lint-style",
+  "lint:check": "npm run format && npm run lint:js",
+  "prepare":    "husky"
+}
+```
+
+```jsonc
+// composer.json
+"scripts": {
+  "lint":    ["@php-lint", "@phpcs", "@fixer:test", "@phpstan"],
+  "phpcs":   "phpcs --standard=phpcs.xml.dist",
+  "phpcbf":  "phpcbf --standard=phpcs.xml.dist",
+  "phpstan": "phpstan analyse"
+}
+```
+
+Adding a script that references a tool the repo doesn't require is worse than having no
+script — it fails for everyone. Check `require-dev` first, and add the dependency in the
+same change or not at all.
+
+## Local environments
+
+**WordPress Studio is the default** for new Linchpin work. Repos still carrying wp-env or
+LocalWP config predate that switch — those files are not evidence that the project is being
+run that way today. Detect, and when both exist, ask which the user is on:
+
+| Signal | Environment | Start |
+| --- | --- | --- |
+| Site registered in Studio | **WordPress Studio** (default) | [`wp-studio-cli`](../../wp-studio-cli/SKILL.md) — MCP `site_start`, else `studio site start` |
+| `.wp-env.json` | wp-env (Docker) — legacy | `npx @wordpress/env start` |
+| `.linchpin.json` → `wordpress.environments` | LocalWP or a declared path — legacy | Already running; use the path |
+
+Unit tests and lint don't need any of this. Only reach for an environment when running E2E
+or a check that boots WordPress.

package/skills/safety-hooks/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: safety-hooks
+description: Turn on enforced guardrails for risky work — a PreToolUse hook that makes destructive commands (wp db drop, search-replace without --dry-run, DROP TABLE, git push --force, rm -rf) require confirmation, and an optional edit boundary that blocks writes outside one directory. Use when touching production or a client database, debugging a live site, working in an unfamiliar repo, or when asked for careful mode, safety mode, or to lock down edits. Claude Code only.
+version: 1.0.0
+---
+
+# Safety hooks
+
+Every other skill in this library *asks* an agent not to do something dangerous. This one
+**enforces it**, by registering a `PreToolUse` hook that inspects each command before it runs
+and makes the destructive ones require confirmation.
+
+That matters most where our work is riskiest: client databases, production WordPress, and
+`wp search-replace` — a single command that rewrites a live database in place.
+
+## When to use
+
+- About to touch production or staging, or any client database.
+- Debugging a live site, or working in a repo you don't know well.
+- Handing a session to someone less familiar with the project.
+- Asked for "careful mode", "safety mode", or "only edit this folder".
+
+**Not this skill:** the prose rules about what's safe on a server —
+[`wp-pressable`](../wp-pressable/SKILL.md). Pre-commit checks —
+[`quality-gates`](../quality-gates/SKILL.md).
+
+## Owns
+
+Canonical for: the enforced guardrail mechanism, the destructive-command list, and the edit
+boundary. Other skills state judgment rules; this one blocks actions.
+
+## Portability exception
+
+This is the **one deliberately Claude-Code-only skill** in the library. Hooks are a Claude
+Code feature; Copilot, Codex, and Cursor ignore the `hooks` frontmatter and the skill
+degrades to documentation. That trade is worth making because the protection is real, and
+because nothing else here depends on it — see
+[`write-a-linchpin-skill`](../write-a-linchpin-skill/SKILL.md).
+
+## Turning it on
+
+**For the session** — invoking this skill registers the hooks below; they last until the
+conversation ends.
+
+**Permanently** — copy the same entries into `~/.claude/settings.json` (global) or the
+project's `.claude/settings.json`:
+
+```jsonc
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [{
+          "type": "command",
+          "command": "bash -c 'f=.claude/skills/safety-hooks/scripts/check-destructive.sh; [ -f \"$f\" ] || f=$HOME/.claude/skills/safety-hooks/scripts/check-destructive.sh; bash \"$f\"'"
+        }]
+      },
+      {
+        "matcher": "Edit|Write",
+        "hooks": [{
+          "type": "command",
+          "command": "bash -c 'f=.claude/skills/safety-hooks/scripts/check-edit-boundary.sh; [ -f \"$f\" ] || f=$HOME/.claude/skills/safety-hooks/scripts/check-edit-boundary.sh; bash \"$f\"'"
+        }]
+      }
+    ]
+  }
+}
+```
+
+## Setting an edit boundary
+
+The boundary is opt-in and off by default. To scope edits to one directory — useful while
+debugging, so unrelated code can't be "helpfully" fixed:
+
+```bash
+mkdir -p "${LINCHPIN_SAFETY_DIR:-$HOME/.claude/.linchpin-safety}"
+cd <directory-to-restrict-to> && pwd > "${LINCHPIN_SAFETY_DIR:-$HOME/.claude/.linchpin-safety}/edit-boundary.txt"
+```
+
+To clear it:
+
+```bash
+rm -f "${LINCHPIN_SAFETY_DIR:-$HOME/.claude/.linchpin-safety}/edit-boundary.txt"
+```
+
+Ask the user which directory rather than guessing, and confirm the resolved absolute path
+back to them.
+
+## What triggers a confirmation
+
+| Area | Patterns |
+| --- | --- |
+| WordPress | `wp db drop`/`reset`/`import`, `wp search-replace` without `--dry-run`, `wp site empty`, `wp post/user/term/comment delete`, `wp plugin uninstall`, changing `home`/`siteurl` |
+| Databases | `DROP TABLE`/`DATABASE`, `TRUNCATE`, `DELETE FROM` with no `WHERE` |
+| Git | `push --force`, `reset --hard`, `checkout .`/`restore .`, `clean -fd`, `branch -D` |
+| Filesystem & infra | `rm -rf`, `kubectl delete`, `docker rm -f`, `docker system prune`, `ssh` running `wp`/`mysql` remotely |
+
+Allowed without prompting: removing `node_modules`, `vendor`, `dist`, `build`, `.next`,
+`.turbo`, `.cache`, `coverage`, `__pycache__`, and any `search-replace` carrying `--dry-run`.
+
+## Guardrails
+
+- **This is a speed bump, not a sandbox.** It fails *open* — if `python3` is missing or
+  parsing fails, commands proceed. Bash can still write anywhere via `sed` or redirects.
+  Never describe it to a client or teammate as a security control.
+- **Never disable the hook to get a command through.** Confirm the command deliberately, or
+  change the command.
+- **Never widen the safe-exception list to silence a prompt** you found annoying — that list
+  is why the prompts stay meaningful.
+- **Never set an edit boundary without telling the user** what it is; a blocked edit is
+  confusing when the reason is invisible.
+- A confirmation prompt is a moment to re-read the command, especially the environment it
+  points at. Approving reflexively is the failure this exists to prevent.
+
+## Done
+
+- [ ] Hooks registered — session-scoped, or written into settings for permanence.
+- [ ] The user knows which protections are active and how to clear them.
+- [ ] Edit boundary, if set, was chosen by the user and echoed back as an absolute path.
+- [ ] No hook was bypassed or weakened to let a specific command through.

package/skills/safety-hooks/scripts/check-destructive.sh

@@ -0,0 +1,80 @@
+#!/usr/bin/env bash
+# PreToolUse hook for Bash: warn before destructive commands.
+#
+# Reads the tool-call JSON on stdin and, when the command matches a destructive
+# pattern, returns permissionDecision "ask" so the user confirms before it runs.
+# Anything else produces no output, which lets the command proceed normally.
+#
+# Fails OPEN by design: this is a safety net, not a security boundary. If parsing
+# breaks or python3 is missing, work continues rather than the session wedging.
+# Bash can always modify files another way (sed, redirects), so treat this as a
+# speed bump on autopilot, not a sandbox.
+
+set -uo pipefail
+
+INPUT=$(cat 2>/dev/null || true)
+[ -z "$INPUT" ] && exit 0
+command -v python3 >/dev/null 2>&1 || exit 0
+
+CMD=$(printf '%s' "$INPUT" | python3 -c '
+import json, sys
+try:
+    data = json.load(sys.stdin)
+except Exception:
+    sys.exit(0)
+print((data.get("tool_input") or {}).get("command", ""))
+' 2>/dev/null || true)
+
+[ -z "$CMD" ] && exit 0
+
+# Build artifacts and dependency directories are safe to blow away.
+if printf '%s' "$CMD" | grep -qE 'rm +(-[a-zA-Z]+ +)*(node_modules|vendor|dist|build|build-tools|\.next|\.turbo|\.cache|coverage|__pycache__)/?( |$)'; then
+  exit 0
+fi
+# An explicit dry run is the safe form of search-replace.
+if printf '%s' "$CMD" | grep -q 'search-replace' && printf '%s' "$CMD" | grep -q -- '--dry-run'; then
+  exit 0
+fi
+
+REASON=""
+match() { printf '%s' "$CMD" | grep -qiE "$1"; }
+
+# --- WordPress / WP-CLI ------------------------------------------------------
+if   match 'wp +db +(drop|reset)';            then REASON="\`wp db drop/reset\` destroys the entire database."
+elif match 'wp +db +import';                  then REASON="\`wp db import\` overwrites the current database."
+elif match 'wp +search-replace';              then REASON="\`wp search-replace\` rewrites the database in place. Run it with --dry-run first."
+elif match 'wp +site +empty';                 then REASON="\`wp site empty\` deletes all site content."
+elif match 'wp +(post|user|term|comment) +delete'; then REASON="This deletes content permanently, especially with --force."
+elif match 'wp +plugin +uninstall';           then REASON="\`wp plugin uninstall\` removes the plugin and its data."
+elif match 'wp +option +(delete|update) +(home|siteurl)'; then REASON="Changing home/siteurl can take the site offline."
+# --- Databases ---------------------------------------------------------------
+elif match 'drop +(table|database)';          then REASON="DROP removes the table or database and its data."
+elif match 'truncate +(table +)?[a-z_]';      then REASON="TRUNCATE empties the table irreversibly."
+elif match 'delete +from +[a-z_]+ *(;|$)';    then REASON="DELETE FROM with no WHERE clause removes every row."
+# --- Git ---------------------------------------------------------------------
+elif match 'git +push +.*(--force|-f)( |$)';  then REASON="Force-push rewrites remote history and can destroy others' commits. Prefer --force-with-lease."
+elif match 'git +reset +--hard';              then REASON="\`git reset --hard\` discards uncommitted work permanently."
+elif match 'git +(checkout|restore) +\.( |$)';then REASON="This discards all uncommitted changes in the working tree."
+elif match 'git +clean +-[a-z]*[fd]';         then REASON="\`git clean\` deletes untracked files, including ones never committed."
+elif match 'git +branch +-D';                 then REASON="Force-deleting a branch can lose unmerged commits."
+# --- Filesystem / infra ------------------------------------------------------
+elif match 'rm +(-[a-zA-Z]+ +)*-?[a-zA-Z]*r[a-zA-Z]*f|rm +-rf|rm +-fr'; then REASON="Recursive force delete."
+elif match 'kubectl +delete';                 then REASON="This removes live Kubernetes resources."
+elif match 'docker +(rm +-f|system +prune)';  then REASON="This removes containers, images, or volumes."
+elif match 'ssh .*(wp |mysql )';              then REASON="This runs a data-affecting command on a remote server."
+fi
+
+[ -z "$REASON" ] && exit 0
+
+python3 -c '
+import json, sys
+reason = sys.argv[1]
+print(json.dumps({
+    "hookSpecificOutput": {
+        "hookEventName": "PreToolUse",
+        "permissionDecision": "ask",
+        "permissionDecisionReason": "Destructive command: " + reason + " Confirm you intend to run this, and that it is pointed at the environment you think it is."
+    }
+}))
+' "$REASON"
+exit 0

package/skills/safety-hooks/scripts/check-edit-boundary.sh

@@ -0,0 +1,65 @@
+#!/usr/bin/env bash
+# PreToolUse hook for Edit/Write: block edits outside an allowed directory.
+#
+# Reads the tool-call JSON on stdin and denies the operation when the target file
+# is outside the boundary recorded in the state file. With no state file, every
+# edit is allowed — the boundary is opt-in per session.
+#
+# State file: $LINCHPIN_SAFETY_DIR/edit-boundary.txt (default ~/.claude/.linchpin-safety/)
+#
+# Fails OPEN: if parsing breaks, the edit proceeds. This prevents accidental edits
+# to unrelated code; it is not a security boundary, since Bash can still write
+# anywhere.
+
+set -uo pipefail
+
+STATE_DIR="${LINCHPIN_SAFETY_DIR:-$HOME/.claude/.linchpin-safety}"
+BOUNDARY_FILE="$STATE_DIR/edit-boundary.txt"
+
+[ -f "$BOUNDARY_FILE" ] || exit 0
+BOUNDARY=$(cat "$BOUNDARY_FILE" 2>/dev/null || true)
+[ -z "$BOUNDARY" ] && exit 0
+# Trailing slash keeps /src from matching /src-old.
+BOUNDARY="${BOUNDARY%/}/"
+
+INPUT=$(cat 2>/dev/null || true)
+[ -z "$INPUT" ] && exit 0
+command -v python3 >/dev/null 2>&1 || exit 0
+
+FILE_PATH=$(printf '%s' "$INPUT" | python3 -c '
+import json, sys
+try:
+    data = json.load(sys.stdin)
+except Exception:
+    sys.exit(0)
+print((data.get("tool_input") or {}).get("file_path", ""))
+' 2>/dev/null || true)
+
+[ -z "$FILE_PATH" ] && exit 0
+
+# Resolve relative paths against the working directory so the comparison is fair.
+case "$FILE_PATH" in
+  /*) ABS="$FILE_PATH" ;;
+  *)  ABS="$PWD/$FILE_PATH" ;;
+esac
+
+case "$ABS" in
+  "$BOUNDARY"*) exit 0 ;;
+esac
+
+python3 -c '
+import json, sys
+path, boundary = sys.argv[1], sys.argv[2]
+print(json.dumps({
+    "hookSpecificOutput": {
+        "hookEventName": "PreToolUse",
+        "permissionDecision": "deny",
+        "permissionDecisionReason": (
+            "Edit boundary active: edits are restricted to " + boundary +
+            " but this targets " + path +
+            ". Run /safety-hooks to change or clear the boundary if this edit is intended."
+        )
+    }
+}))
+' "$ABS" "$BOUNDARY"
+exit 0

package/skills/support-triage/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: support-triage
+description: Run a client support request end to end — clarify what was actually asked, reproduce it, judge urgency and whether it fits the support agreement, fix and verify it, then close the loop with the requester in their language. Use when handling a support ticket, when a client reports something broken, when triaging a support queue, or when a request might be out of scope. Baseline workflow, refined with the team over time.
+version: 0.1.0
+---
+
+# Support triage
+
+Support work is judged on two things clients actually notice: **was it understood, and were
+they told what happened.** The technical fix is usually the easy part.
+
+The two failure modes to design against: fixing the wrong thing because the report was taken
+literally, and doing three hours of unscoped work because nobody stopped to ask whether it
+was covered.
+
+## When to use
+
+- A client support request needs handling.
+- Something broke on a live client site.
+- Triaging a queue of open support requests.
+- A request looks like it might exceed the support agreement.
+
+**Not this skill:** deciding what kind of engagement the work belongs to —
+[`engagement-types`](../engagement-types/SKILL.md). Root-causing a stubborn bug —
+[`investigate`](../investigate/SKILL.md). Server operations —
+[`wp-pressable`](../wp-pressable/SKILL.md).
+
+## Owns
+
+Canonical for: support intake, urgency assessment, the in-scope decision, and closing the
+loop with the requester.
+
+## Procedure
+
+1. **Read the request for the underlying need.** Clients describe symptoms and often propose
+   solutions ("can you make the button bigger" may mean "nobody is finding the form"). Restate
+   what you think they want and what outcome would count as fixed.
+   → You can state the actual problem, not just the requested change.
+2. **Identify the site and environment.** On multi-site accounts this is required, never
+   inferred ([`engagement-types`](../engagement-types/SKILL.md)). Confirm production URL
+   versus staging. → The exact target is named in the task.
+3. **Reproduce it** before theorizing — same page, same role, same browser where it matters.
+   If it doesn't reproduce, that's information: ask for a screenshot, the URL, the browser,
+   or the account used. → Confirmed reproduction, or a specific question back to the client.
+4. **Assess urgency honestly**, from user impact rather than from the tone of the request:
+
+   | Level | Means | Response |
+   | --- | --- | --- |
+   | **Site down / data at risk** | Nobody can use it, or something is leaking | Drop other work, tell the client you're on it now |
+   | **Blocking** | A core task is impossible, no workaround | Same or next business day |
+   | **Degraded** | Works with a workaround, or affects some users | Scheduled into the queue |
+   | **Request** | Change, addition, or question | Queued and estimated |
+
+   → A stated level the client would recognize as fair.
+5. **Decide in-scope or not — before doing the work.** If it fits the agreement, proceed. If
+   it's really a small project, say so *now*, with a rough estimate, and let the client decide.
+   → Either work has started, or a scoping question is with the client.
+6. **Fix it properly.** Code changes go through the repo and the deploy pipeline; content and
+   template overrides are server-side database work
+   ([`wp-pressable`](../wp-pressable/SKILL.md)). Never patch files directly on a server —
+   the next deploy erases it and the bug returns looking like a regression.
+   → Fix is in the right layer and will survive a deploy.
+7. **Verify on the environment the client saw it on**, flushing caches first. Screenshot the
+   result. → Evidence the specific reported case now works.
+8. **Close the loop in the client's language.** What was wrong, what you did, anything they
+   should know or do. No jargon, no commit hashes. Then update the task
+   ([`task-tracking`](../task-tracking/SKILL.md)) with the technical detail for the team.
+   → The client knows it's resolved; the task carries the internal record.
+
+## Recurring symptoms
+
+| Report | Check first |
+| --- | --- |
+| "The site is down" | Is it actually down, or slow, or DNS/SSL? Confirm before escalating |
+| "My change didn't save" or "isn't showing" | Caching first — object, page, browser — then the edit itself |
+| "It broke and we didn't change anything" | Recent deploy, plugin auto-update, or an expiring credential or certificate |
+| "It looks wrong" | Get a screenshot and their browser; often browser-specific or a stale cache |
+| "Emails aren't arriving" | Deliverability and the sending service before the form code |
+| "Can you just quickly…" | Scope check — quick to describe is not quick to build |
+
+## Guardrails
+
+- **Never work outside the agreement without approval.** Doing unbilled work "to be nice"
+  sets an expectation the whole team inherits.
+- **Never make an undiscussed change while you're in there.** Unrequested improvements on a
+  client site are unreviewed changes.
+- **Never edit files directly on the server** — it's overwritten by the next deploy.
+- **Never change production data without a backup** and explicit confirmation
+  ([`safety-hooks`](../safety-hooks/SKILL.md) will prompt on the dangerous commands).
+- **Never guess at what a client meant** on anything ambiguous and destructive — ask.
+- **Never report it fixed without verifying on their environment**, cache cleared.
+- **Never leave a request silent.** Even "I'm looking at it, here's what I know" is a
+  response; silence is the complaint clients actually make.
+
+## Done
+
+- [ ] Underlying need restated and confirmed, not just the literal request.
+- [ ] Site and environment identified explicitly.
+- [ ] Reproduced, or a specific clarifying question sent.
+- [ ] Urgency assessed on impact, and scope decided before the work began.
+- [ ] Fix in the correct layer, surviving the next deploy.
+- [ ] Verified on the client's environment with caches cleared, with evidence.
+- [ ] Client told what happened in plain language; task updated with the technical record.