A gate asks whether an artifact is good. Acceptance asks whether anything on the list was lost. Neither asks what the project actually is today, and that is the only question an operator has when they open a repository they have not touched for a month.

This skill answers it from a cold start — no brief, no REQ table, no module map required — and leaves two artefacts: a page a person reads, and a sidecar the next audit reads.

references/portable-method.md

/skill-audit

/ux-audit

/seo-aeo-audit

Read

references/portable-method.md

before phase 4. It carries the standalone audit floor and needs neither a sibling skill nor network access. The companion task-pipeline audit, backlog and prioritisation references are optional deeper reading when installed; their absence never blocks this procedure.

Run them in order. Each writes into the same payload the report is rendered from.

answers this mechanically: languages, package managers, monorepo shape, submodules, CI, deploy targets, declared telemetry, and the version the project states about itself. It reads committed state — , never a directory walk — because a walk finds and build residue, and reports a project no clone would produce.

The output is a profile, and the profile chooses the probes. Skipping this and running a fixed checklist is how an audit produces the same nine findings on every repository it is ever pointed at.

Every probe declares what it needs (, , , , a connected MCP server). A need that is not met makes the probe blind, with the reason — never absent, and never clean. The catalogue by stack, and what to add for a project shape the script does not cover, is

references/probes.md

.

This is the phase most audits skip, and the one that finds what the repository cannot admit about itself:

Before ANY datastore read, in this order — a figure from the wrong database is worse than no figure, because it is quoted with the authority of a measurement:

Now, and only now, walk the local portable method's ladder over the capabilities the discovery found. Bottom-up, seam-ordered. Absences found here are findings like any other.

writes the sidecar and prints a summary. Add for the HTML page, and beside it to write without opening. It is the same script the probes live in, so what the report claims and what ran are the same object.

This skill commits nothing. Findings leave as board rows in the project's own vocabulary, priced with the board header's declared formula — the shipped default is (

references/portable-method.md

, the local priority contract) — and the operator accepts them. Effort never ranks inside an audit: what a fix costs is the fixer's decision, not the finder's (

references/portable-method.md

). An audit that edits while it reads cannot be re-run to check itself. In 's wave mode these rows and the JSON sidecar are wave 0's input: they join its inventory by id.

Mechanism status, exploit/reproduction, exposure, observed incidence and impact uncertainty are FIVE axes, not one. A row written from the mechanism alone is indistinguishable from a real finding until each axis says what it knows — and one audit had eight consecutive rows rewritten by measurement, two of which would have destroyed inventory if remedied as written, because both read an absence of sales as an absence of demand. But the correction cuts both ways:

The incidence axis is still asked: how often does the mechanism fire? A query, a log count, a telemetry read. Where the answer is never, keep the row priced as latent (the remedy weighed against zero); where the measurement is impossible, the INCIDENCE axis records — and the finding stands on its mechanism and reproduction axes. Each row records its observation scope and time, keeping code mechanism, deployment observation and assumptions apart — in task-pipeline is the minimal schema, and the collector writes /// into the sidecar. Ask an operator only when the unknown would change the action — an interview is not a prerequisite for a row.

Two rules follow from the same place:

An audit that reads a module and not the places the module is used reports, as defects, the things the project has already decided — in the project's own words, because the decision is usually written a few lines from the code the finding cites. Five of eight rows in one run were that.

· · . The vocabulary is closed; a fourth value is refused at construction.

blind

is the whole design. Without it, a probe that could not look and a probe that found nothing produce the same empty section, and a reader takes the second meaning every time. This is the local method's silence is not a reading raised from a command to a probe: a zero exit with no output has not answered.

The page renders the blind list as a section of its own, never an appendix. An audit's blind spots are part of its result.

One version string, more than one tree. A package's channels do not all serve the same thing: a registry serves the tag, while a plugin marketplace and a skills CLI serve the branch tip. When the branch has moved past the tag without a version bump, every channel answers the same number and ships different code.

Measured in this family on 2026-08-22: npm served one file at 4344 lines while the marketplace served it at 4575, and all three channels reported . The pin checker was green throughout — correctly, because it compared the two strings.

So compare trees, never labels, and compare the pair that can actually disagree. The first draft of this probe compared the registry tarball against the tag and reported clean: those agree by construction, because the registry publishes from the tag. A tautology returning green is the false success shape — a mechanism trusted by its own reply.

Two more traps, both of which shipped in the first draft and are now fixtures:

is written on every run. The HTML page is written only with

--report

. Three output modes, and only one needs a browser: stdout ( — the summary in the terminal, nothing written but the sidecar), json (the sidecar alone, the default — a machine reads it, no page and no browser), html ( — the page too). A json-only or stdout run never opens a browser and never requires one; the browser is a concern of alone.

The split is not symmetry. The sidecar is what makes this a ratchet rather than a snapshot, and the next run reads it — skipping it would silently turn every future run into a first run. The page is a report, and a report is an artefact that outlives the conversation: one nobody asked for is a document nobody ordered and nobody maintains, sitting untracked under one from the product's history. Answer in the conversation; write the page when somebody wants a page.

The page carries aggregates and pointers, never raw bodies. Counts, top classes, trends, and a link to the issue in its own system — never a stack trace, a log line or a row of data. The report is a file people forward, and a report that cannot be shared is one nobody writes twice.

A secret is reported by place and class, never by value. , which credential it is, and the remedy. The value appears in neither artefact nor on stdout: an audit must not become the second place a credential leaks. Redaction is total rather than a prefix — half a credential plus its context is often enough to finish.

"Read-only" is about the TARGET, not the disk. The audit reads the project's source, data and production evidence and mutates NONE of it, and it commits nothing. It DOES write its own artefacts into its allowed output directory ( by default, to relocate) — the sidecar always, the page on . Writing the sidecar there is not a violation of read-only; writing into the target's source, or -ing anything, is.

The sidecar is what makes this a ratchet rather than a snapshot. Each finding carries an id derived from its probe and its place, so it survives a rewording; the next run prints what closed, what is new, and what has now survived three audits. That last number is itself a finding: a defect nobody picks up is a decision nobody wrote down.

--report

The split is not tidiness. A judgement encoded in a script becomes a gate nobody agreed to; a mechanic left in prose becomes a step nobody runs. Both have shipped in this family and both are on its boards.

Run the script first, read its blind list, then spend your reading where it could not look.

An audit is finished when — the criterion is CONDITIONAL on the deliverables requested, not a fixed page-and-browser:

The description is the short form. The full trigger list it carried until 1.98.0, moved here verbatim, still routes to this skill:

"Use when someone asks what is actually true of a whole project right now — what is finished, what is half-built, what is broken, and what nobody has looked at. Walks a cold start: discover what the project is, run a registry of probes chosen from that, read production evidence (published artefact against source, CI history, telemetry present or absent), then leave a JSON sidecar so the next audit can say what moved, and a self-contained HTML report on request. Read-only: it proposes board rows and commits nothing. Triggers - 'project audit', 'audit the project', 'codebase audit', 'state of the project', 'what is unfinished', 'project health check', 'аудит проекта', 'проаудируй проект', 'состояние проекта', 'что не доделано', 'аудит кодовой базы'. Not for: auditing one deliverable inside a run (that is the pipeline's own ladder), reviewing a diff, or checking a skill's construction — say 'без диагностики' to opt out."