ASSAY assesses an unfamiliar codebase for security, code quality, and long‑term supportability, then ships a defensible verdict. Every finding is source‑verified before it ships, and your code never has to leave your infrastructure.
--offline runs air‑gapped and makes provably zero network callsASSAY pairs an assessment engine with a history dashboard. They share one report format and stay in sync — but neither depends on the other to run.
.docx with a live table of contents, index and page numbersA depth flag scales the scope — --light, --thorough or --full —
but step two is never skipped. Agents are used for reach; a human adjudicates.
Map the stack, domain, data sensitivity and existing gates into a recon map every lens reads first.
you · ~10 minUp to nine specialist lenses run in parallel, each narrowed to the surfaces recon actually found.
3–9 lensesEvery high‑severity finding is confirmed in the primary source. This is the step that makes it worth reading.
you · requiredAn executive summary that leads with the answer, plus a technical appendix — every finding evidence‑labelled.
youA self‑verifying build to .docx, PDF, HTML or SARIF — the format the reader already uses.
Scanners and agents are excellent at locating candidate issues across a large codebase, and unreliable at adjudicating them. ASSAY uses them for reach, then makes a human confirm each high‑severity finding in the source before it ships.
The output is a defensible verdict, not raw scanner output. Every finding carries its evidence tier, and retractions stay in the report — because a report with no retractions either got lucky or didn't verify.
Every finding is source‑verified before it ships and labelled with its evidence tier. The report is a defensible verdict, retractions and all.
Repo age, velocity, application LOC, bus factor, churn hotspots, cyclomatic complexity, coverage, mutation, vulnerable deps and an AI‑authorship signal — all from git and your toolchain.
Node, Python, .NET and Go out of the box; any language via lizard complexity. Anything it can't run, you pass in — LCOV, SARIF, npm/pip/dotnet audit JSON.
Builds a .docx with a cover page, live clickable TOC, index and page numbers — no pandoc, no LaTeX. Export the same layout to PDF, or a print‑ready standalone HTML on any platform.
Brand at the shell: pour the report into your own .docx template and its theme, cover, header and footer genuinely drive the document — no fragile post‑hoc template swap.
secscan normalises Semgrep, gitleaks, Trivy and OWASP ZAP into one severity‑sorted worklist — every row pending until a human adjudicates it. Refuses any non‑local target.
Emit findings as SARIF 2.1.0 for GitHub code scanning or Defender, evidence tiers preserved. A weighted readiness score with derived stoplights rolls the verdict into one number.
A scheduled CI workflow runs the deterministic checks every week and gates on only two objective, severe signals — a runtime past end‑of‑life and critical/high vulnerable deps — reporting the rest.
Install the /audit skill and run the whole method end to end from any repo, or scaffold a workspace with audit-kit new and run the prompts by hand or from CI. No lock‑in.
The build compares every heading against the generated TOC and throws if one is missing. Counts don't prove correctness — so the kit checks against the source, the same thing its reports do.
Requires Node 24+. The .docx build additionally uses Microsoft Word on Windows;
every metric and the print‑ready HTML run on macOS and Linux too.
| Command | What it does |
|---|---|
audit-kit new | Scaffold an engagement workspace — prompts, template and config. |
audit-kit scan | Measure the whole supportability table deterministically → paste‑ready report rows. |
audit-kit secscan | Run SAST / secrets / dependency / DAST scanners in containers against a local target → a candidate worklist. |
audit-kit readiness | The verdict table with derived stoplights and the weighted readiness score rolled up from it. |
audit-kit attest | A verification attestation — evidence tiers, critical/high coverage and retractions, counted from the findings. |
audit-kit build | Markdown → |
audit-kit html | Markdown → self‑contained, print‑ready HTML — no Word required. |
audit-kit sarif | Findings as SARIF 2.1.0 for GitHub code scanning or Defender, evidence tiers preserved. |
audit-kit tokens | What each lens pass consumed, counted from the run's own transcripts — the AI‑assist cost, measured. |
audit-kit skill | Install the |
audit-kit doctor | Check prerequisites — Node, Word, Docker and the dashboard. |
One self‑contained HTML file that computes every chart in the browser from an embedded data block. Open it anywhere — no server, no build, nothing to install. It themes light and dark, and it prints.
Findings across how many lenses, critical/high, the verification ratio, and the median age of a finding's code at the pinned commit.
Every finding placed at the commit that first wrote its line, banded by severity — with an accumulation plot showing how long the risk has been latent.
Severity, evidence, location, a stable check id, and an Introduced column — the date and author of the commit that first wrote the line.
Two directions of the file ↔ issue relationship: where issues land by file, and the issues grouped lens → file → finding.
Commits touching each file up to the assessed commit — high churn × complexity made visible as the next likely defect site.
The judged supply‑chain worklist and the measured dependency‑integrity check each get their own card — never merged.
Line numbers mean something only at the commit the report names. The dashboard pins to it and stops if the checkout doesn't contain it — rather than blaming HEAD and inventing a plausible, wrong answer.
A location git can't resolve gets git's own reason — "there is no path X in the commit" — shown in the row and counted in a banner. That's a finding about the report, and more useful than a blank.
Filter by severity, evidence, lens or churn hotspot and the KPIs, both plots, the table, treemap, icicle and churn chart all re‑render together. The frame never moves, so the numbers always agree.
It recomputes the verification ratio from the findings table and raises a banner when the report's prose disagrees with its own numbers. Counts don't prove correctness.
Severity rides the position, not the colour. Every plotted value is repeated in the findings table — a report whose whole purpose is not to mislead can't ship a chart that does.
Rebrand by editing the design tokens; ships a light/dark toggle. No CDN, no fonts, no fetch — the same no‑egress guarantee as the page it reports on.
The kit's own code calls no LLM. The mechanical half — scan, secscan, readiness, attest, build, the dashboard — is pure, deterministic Node. The intelligent half is done by an agent driving a model you choose, and it's deliberately not locked to one provider.
| Tier | You run it with | What leaves your network |
|---|---|---|
| Turnkey | The /audit skill | Prompts + code excerpts to your model provider |
| BYO key | A thin runner on an agent SDK | Prompts + code excerpts to your provider |
| BYO any model | Any agent runtime, or by hand | Nothing — on a self‑hosted model |
No dependencies to install. Clone it, put audit-kit on your PATH, and check your prerequisites.