pr — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pr (Agent Skill) and scored it 87/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 3 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 3 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Drive an uncommitted change to an open PR (GitHub) or MR (GitLab) with the user's review-gating workflow baked in. Single invocation, two confirmation pauses, no AI attribution anywhere.
main/master/develop or whatever git remote show origin reports) directly. Always branch.Run in parallel:
git remote get-url origin — detect platform from the host: a gitlab.-prefixed or otherwise GitLab host → GitLab; github.com (or a GitHub Enterprise host) → GitHub. If neither pattern matches (self-hosted, unknown host, or no remote), AskUserQuestion which platform to target — do not guess.git remote show origin — read the default branch ("HEAD branch:" line) rather than assuming main/master/develop. Cache it as <default> for step 5 (and step 1's own "already on <default>" check). If the remote can't be reached, fall back to git symbolic-ref --short refs/remotes/origin/HEAD then to main.git status --porcelain and git branch --show-current — see what's changed and where we are. Parse ?? entries: untracked files are part of the change and must be included in step-2 grouping and the step-6 description (they're easy to miss because they don't show in git diff HEAD).git diff --stat HEAD and git diff HEAD — full picture of the tracked changes (staged + unstaged).git log -5 --oneline — match the repo's commit message style.If we're already on <default> with uncommitted changes, that's expected — we'll branch in step 5. If we're on a feature branch with prior commits, treat those as part of this PR/MR (ask the user if unsure).
If there are no changes (git status clean — no tracked diff, no ?? untracked entries — and no unpushed commits), stop and tell the user.
Before proposing groups, read the actual diff — not just the file list. For non-trivial hunks, open the changed files at the relevant line ranges to understand intent. The goal is to write a meaningful PR/MR description, not a file enumeration.
Then propose grouping. Most of the time there is one logical group and the answer is "ship it all together" — consolidate related changes into a single PR/MR unless the project's CLAUDE.md says otherwise. Only propose splitting when the diff genuinely spans unrelated concerns (e.g., a feature change plus an unrelated config tweak).
Present grouping via AskUserQuestion:
Wait for the answer before staging anything.
glab auth status --hostname <host>, where <host> is the derived GitLab host — take the ABC_GITLAB_HOST env var if set, otherwise parse the host out of git remote get-url origin (the <host> in git@<host>:… or https://<host>/…). If no GitLab remote resolves, fall back to bare glab auth status. Never hardcode a specific GitLab hostname. For GitHub: gh auth status..env files. Flag and stop if any line matches:ghp_…, github_pat_…glpat-…AKIA…sk-…xox[bpars]-…-----BEGIN … PRIVATE KEY-----*_KEY, *_TOKEN, *_SECRET (a long opaque literal on the RHS)Exemption: a 1Password reference (op://…) or other documented secret-manager placeholder is not a literal secret — don't flag it. When a match looks like a real secret, stop and surface the file + line so the user can scrub it before the PR/MR is opened.
Detect the project's commands from package.json scripts (in priority order): typecheck, type-check, tsc, lint, test. Use the package manager indicated by lockfile (pnpm-lock.yaml → pnpm, yarn.lock → yarn, else npm).
Monorepo awareness. If a workspace manifest is present (pnpm-workspace.yaml, a workspaces field in the root package.json, turbo.json, nx.json, or similar), don't assume the root scripts apply to the change. Locate the nearest `package.json` at or above the changed files and run its scripts, scoping to that package (pnpm --filter <pkg> <script>, or yarn workspace <pkg> <script>). Fall back to the root manifest's scripts when the changed files sit above any package boundary or no nearer manifest defines the script.
Run type-check first (fastest signal), then tests. If either fails:
For non-JS repos or repos without these scripts, skip with a one-line note ("no typecheck/test scripts found — skipping").
<default> (from step 1), run git fetch origin and create the branch from origin/<default> — not from a possibly-stale local <default> — so the PR/MR diffs against current upstream. (This is why the git fetch grant is retained.) When already on a feature branch with prior commits, branch in place; don't reset onto upstream.fix-srcset-w-descriptor, add-pause-on-mr-confirmation). Match the repo's branch-naming style if visible in git branch -a. Avoid generic names like claude/fix, update, wip.git log -5 --oneline. Body explains motivation, not a file-by-file enumeration. No AI footers, no Co-Authored-By trailers. Use a HEREDOC for the message body.git add . or git add -A) so accidental untracked files don't slip in — but do stage the new untracked files identified in step 1 that belong to this change.-u origin <branch>.Concise. Focused on why and what changed at a high level, not a file enumeration. Use this skeleton:
## Summary
<1–3 sentences on the user-visible or system-visible change and the motivation>
## Changes
- <bullet per logical change, not per file>
## Test plan
- [ ] <verification steps the reviewer can run or check>No "Generated with Claude Code" link. No "🤖" emoji. No Co-Authored-By trailer. If the repo has a PR/MR template (.github/pull_request_template.md or .gitlab/merge_request_templates/), follow its structure but still omit AI attribution.
Show the user:
Use AskUserQuestion with options:
Wait for the answer. Do not open the PR/MR until the user confirms.
gh pr create --title "..." --body "$(cat <<'EOF' ... EOF)"glab mr create --title "..." --description "$(cat <<'EOF' ... EOF)" --remove-source-branchPass the body via HEREDOC to preserve formatting.
Print the PR/MR URL prominently. Do not start a watch/loop unless the user asks — /abc:pr is a one-shot. If the user wants reviewer-comment iteration, point them at /abc:ship-issue (or /abc:review-sweep to triage existing review threads) or a follow-up /abc:pr invocation after they push fixes.
gh pr edit / glab mr update.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.