## Description Adds `--ignore-scripts` to every `pnpm install` invocation run in automated environments — CI workflows (`build-status.yml`, `pr-format.yml`, `pr-pnpm-conflicts.yml`, `add-contributor.yml`), the devcontainer post-create script, and the Claude hook scripts in `.claude/`. The `--lockfile-only` call in `pr-pnpm-conflicts.yml` also receives the flag for consistency, even though that command does not execute lifecycle scripts in practice. End-user impact: no behavioral change for fast-check consumers — published packages are untouched. The change hardens the project's own build/CI surface by preventing arbitrary lifecycle scripts from third-party dependencies from running during dependency installation, reducing exposure to supply-chain attacks. Why this design: `--ignore-scripts` is the canonical pnpm flag for skipping `preinstall` / `install` / `postinstall` / `prepare` hooks during install. It's safe to combine with `--frozen-lockfile` (and with `--lockfile-only`, where it is a no-op). The `CONTRIBUTING.md` snippet documenting local setup was intentionally left untouched: local contributors may legitimately depend on lifecycle scripts running during their first install, and the security benefit is targeted at automated environments where we control the input. Trade-off: if any current or future dependency genuinely needs a lifecycle script to function (e.g. native module compilation), CI will fail until that dependency is allow-listed via pnpm's `onlyBuiltDependencies` (or similar). No such failure is currently observed. Impact: patch — CI/devtool configuration only, no published-code change, no changeset needed. ## Checklist — _Don't delete this checklist and make sure you do the following before opening the PR_ - [ ] I have a full understanding of every line in this PR — whether the code was hand-written, AI-generated, copied from external sources or produced by any other tool - [ ] I flagged the impact of my change (minor / patch / major) either by running `pnpm run bump` or by following the instructions from the changeset bot - [ ] I kept this PR focused on a single concern and did not bundle unrelated changes - [ ] I followed the [gitmoji](https://gitmoji.dev/) specification for the name of the PR, including the package scope (e.g. `🐛(vitest) Something...`) when the change targets a package other than `fast-check` - [ ] I added relevant tests and they would have failed without my PR (when applicable) <!-- PRs not checking all the boxes may take longer before being reviewed --> <!-- More about contributing at https://github.com/dubzzz/fast-check/blob/main/CONTRIBUTING.md --> --------- Co-authored-by: Claude <noreply@anthropic.com>