code-complexity-stats-pr — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited code-complexity-stats-pr (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
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.
A GitHub Actions workflow that runs scc (Sloc, Cloc and Code) over the repo on each pull request and posts the results — including a COCOMO estimated cost/effort to build the codebase — as a single sticky comment that updates in place on every push. Drop-in workflow: templates/code-complexity.yml.
scc prints a per-language table (files, lines, code, comments, blanks, complexity) plus, with --avg-wage, a COCOMO block: estimated person-months, schedule, people, and a dollar cost to develop. The workflow wraps that in a fenced block and posts it as a PR comment titled 📊 Code Complexity Analysis.
It reports the whole codebase at the PR's head, not the diff — it's a "what's this project worth / how big it is" signal, not a per-PR delta.
Copy templates/code-complexity.yml to .github/workflows/code-complexity.yml. It works as-is on ubuntu-latest; the only thing you'll likely change is --avg-wage (and the currency note).
pull_request: [opened, synchronize, reopened] — runs on open andevery push. Kept as its own workflow so it always runs even when other workflows honour a [skip ci]-style marker; these stats are informational.
pull-requests: write is what actually authorises the create/update; issues: write is included belt-and-suspenders. (Both are in the template.)
<!-- code-complexity -->. The script lists existing comments, finds the one with that marker, and updates it (else creates one) — so a PR keeps exactly one stats comment that refreshes instead of stacking new ones each push.
cancel-in-progress: true keyed on the PR — a new push killsthe in-flight run so you don't race two comment updates.
scc --avg-wage <annual> drives the cost figure. The number isunitless to scc — it's read in your currency. The template uses 360000 (HKD 30,000/month) and labels the comment HKD; change both together.
| Want to… | Change |
|---|---|
| Use a different currency / salary | --avg-wage <annual-number> and the HKD label in the comment body |
| Exclude more build/generated dirs | --exclude-dir list (comma-separated). scc honours .gitignore by default; this is for output that isn't ignored |
| Pin / upgrade scc | SCC_VERSION in the install step |
| Run on ARM runners | swap the tarball to scc_Linux_arm64.tar.gz and use an ARM runner (e.g. ubuntu-24.04-arm) |
| Count only part of a monorepo | add a path arg to scc (e.g. scc apps/web) |
pull_request runswith a read-only token and no repo secrets, so the comment step fails (403). Declaring pull-requests: write does not override this — GitHub enforces read-only on the token itself for fork-triggered runs. Options: (a) accept that stats only post for same-repo branches (fine for solo/team repos — the common case); or (b) split into two workflows — compute on pull_request (no secrets, untrusted code), upload scc-output.txt as an artifact, then comment from a separate workflow_run job that has write access. Do not just switch this workflow to pull_request_target: that runs with a write token in the base repo context, and checking out + running fork code there is a token-exfiltration footgun.
characters. Default scc output (a per-language table) is tiny, but --by-file on a big repo could blow past it, which would 422 the step — so the template trims to ~64k with a "truncated" note and the comment still posts.
latest download can change scc's outputformat and silently reshape every PR comment. The template pins SCC_VERSION.
(scc_Linux_x86_64.tar.gz vs _arm64). The wrong one fails to run.
than one API page; without pagination, the marker comment on a later page is missed, and you get duplicates. The template uses github.paginate(...).
GH_TOKEN secret(a PAT/bot you already use) and falls back to `github.token` — the canonical reference to the built-in GITHUB_TOKEN. Prefer github.token over secrets.GITHUB_TOKEN; the built-in token is enough for same-repo comments given the permissions above.
on LOC — a fun, relative signal of size/effort, not a real valuation. Don't quote it as the literal worth of the code.
Generalised from the working code-complexity.yml used in production repos (cphk, piaf-monorepo): same scc + COCOMO + sticky-comment approach, hardened here with version pinning, comment pagination, a portable ubuntu-latest runner, and the fork-PR security note.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.