VibeSafe Starter — Minimum Security for Vibe Coders
ReviewAudited by ClawScan on May 10, 2026.
Overview
The included scripts mostly match a security-auditing purpose, but the setup instructions tell users to copy an unreviewed, unpinned GitHub Actions workflow that is not included in the provided artifacts and will run automatically on every push.
Before installing, review and pin the external GitHub repository, especially the missing .github/workflows/security.yml file. The included shell scripts appear aligned with dependency and secret scanning, but run them in a clean project and review any lockfile changes or external API queries.
Findings (3)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A user could install CI automation whose actual contents were not reviewed here, and it would run automatically in their repository after setup.
The instructions fetch the install source from an unpinned external GitHub repo and copy a workflow file that is not included in the provided manifest. That workflow is described as persistent automation that runs on every push.
### 1. `.github/workflows/security.yml` Drop this into any repo. Runs on every push. ... git clone https://github.com/nerua1/vibe-safe-starter.git cp vibe-safe-starter/.github/workflows/security.yml .github/workflows/
Inspect the GitHub workflow before copying it, pin the repository to a specific trusted commit, and verify the workflow's permissions and commands before enabling it.
Running the audit may make local dependency-lock changes or trigger package-manager behavior in the target project.
The audit script invokes npm install behavior as part of an audit. This is purpose-aligned, but users should know it may contact npm and update package-lock data rather than only reading files.
npm install --package-lock-only --silent 2>/dev/null || true if npm audit --json 2>/dev/null > /tmp/vibe-npm-audit.json; then
Run it in a clean working tree, review any package-lock changes, and consider adding package-manager hardening such as --ignore-scripts if auditing untrusted projects.
Package names checked with the script are shared with external package/security services.
The package-checking script sends package names to public registry and vulnerability APIs, which is expected for this purpose but should be visible to users.
curl -s "https://registry.npmjs.org/$PKG/latest"
...
curl -s "https://api.osv.dev/v1/query" -d "{\"package\":{\"name\":\"$PKG\",\"ecosystem\":\"npm\"}}"
...
curl -s "https://pypi.org/pypi/$PKG/json"Avoid using it for private or sensitive internal package names unless sharing those names with the public APIs is acceptable.