Pre-Release Security Audit (Between Any Two Git Refs)

This skill compares any two git refs (tag/branch/commit SHA) and audits:

Source-code diffs for security regressions
Dependency changes (direct + transitive) and lockfile determinism
Newly introduced package behaviors inside
```
node_modules
```
CI/CD workflow risks in
```
.github/workflows
```
and build configs (Expo/EAS)

The output is a Chinese Markdown report, with a unique title and filename containing the refs to avoid overwrites.

0) Mandatory: confirm audit range (BASE_REF, TARGET_REF)

Ref rules

Accepted: tag / branch / commit SHA
```
BASE_REF
```
= starting point,
```
TARGET_REF
```
= ending point (release candidate)

If refs are not explicitly provided by the user

Ask exactly once before doing any work:

Which two git refs should I compare? (e.g.
v5.19.0
→
release/v5.20.0
, or
main
→
feature/xxx
)

If only one ref is provided

Ask for the missing ref. Do not assume defaults unless the user explicitly says:

“latest tag → HEAD”
or provides an equivalent instruction.

1) Output requirements (hard constraints)

Report language: Chinese
Report filename must include refs to avoid collisions:
- ```
security-audit__${BASE_REF_SAFE}__to__${TARGET_REF_SAFE}.md
```
- ```
BASE_REF_SAFE
```
  /
```
TARGET_REF_SAFE
```
  must replace
```
/
```
  with
```
__
```
  (or
```
-
```
  ) for filesystem safety.

Report title must include refs:

# 安全预审报告（${BASE_REF} → ${TARGET_REF}）

Evidence must be traceable: file path + line numbers (when possible) + short snippet.

2) Safety rules (must follow)

Never print or paste secrets: mnemonics/seed phrases, private keys, signing payloads, API keys, tokens, cookies, session IDs.
If command outputs may contain secrets (env dumps, logs), redact before writing to the report.
Prefer short excerpts; do not paste large bundles.

3) Execution checklist

Step A — Verify refs and collect context

Verify both refs exist:

git rev-parse --verify "${BASE_REF}^{commit}"

git rev-parse --verify "${TARGET_REF}^{commit}"

Record:
- BASE_SHA, TARGET_SHA
- Working tree clean?
```
git status --porcelain
```

List changed files:

git diff --name-status "${BASE_REF}..${TARGET_REF}"

Step B — Collect key diffs

Focus on:

Source:
```
**/*.{js,ts,tsx}
```
Dependencies:
```
**/package.json
```
,
```
yarn.lock
```
CI:
```
.github/workflows/**
```
Expo/EAS configs:
```
eas.json
```
,
```
app.json
```
,
```
app.config.*
```
, build scripts

Step C — Dependency delta (direct deps)

For each changed
```
package.json
```
, compute:
- Added / removed / updated deps (include workspace path)
Version range policy checks:
- Flag
```
*
```
  /
```
latest
```
  as High risk
- Flag
```
^
```
  /
```
~
```
  as Medium risk (explain why this matters for release determinism)
If deps changed but
```
yarn.lock
```
did not, flag as High risk.

Step D — Lockfile determinism (best-effort)

Detect Yarn flavor:
```
yarn -v
```

Try one:

Yarn Berry:
```
yarn install --immutable
```
Yarn Classic:
```
yarn install --frozen-lockfile
```

Record anomalies:
```
resolutions
```
,
```
patches
```
, non-registry sources, unexpected downloads.

Step E — Known vulnerability scanning (best-effort)

```
yarn audit
```
(if available)
```
osv-scanner
```
against
```
yarn.lock
```
(if available)
If missing tools, note “not run + reason”.

Step F — New dependency deep inspection (node_modules)

For each newly added direct dependency:

Inspect

<pkg>/package.json

```
preinstall
```
,
```
install
```
,
```
postinstall
```
scripts
entry points (
```
main
```
,
```
module
```
,
```
exports
```
)
binary/native artifacts (
```
bin/
```
,
```
.node
```
)

Keyword scan (case-insensitive) in its installed code:

Sensitive:

privateKey|mnemonic|seed|keystore|passphrase

Storage:

localStorage|indexedDB|AsyncStorage|keychain|keystore

Network:

fetch|axios|XMLHttpRequest|http|https|WebSocket|ws

Dynamic exec:

eval|new Function|child_process|spawn|exec

Install hooks:
```
preinstall|install|postinstall
```

If hits exist: include path + line + short snippet and explain expected vs suspicious behavior.
Assign risk rating: Low / Medium / High.

Step G — Source diff security review (AI reasoning step)

Within

${BASE_REF}..${TARGET_REF}

diffs, prioritize:

signing flows / key handling / mnemonic
network layer / RPC / telemetry
storage layer (local/secure storage)
logging / analytics / error reporting Output: suspicious changes list (each with summary, impact, evidence excerpt).

Step H — CI/CD & build pipeline risks