New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Audit

by ploxc in ploxc/modbux

Audit one area of Modbux against the eight criteria and write the findings to tmp/AUDIT-<area.md, changing no code.

MITAuto-check passedDevelopment

Install Audit

skills CLI
$ npx skills add ploxc/modbux --skill audit -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install ploxc/modbux audit --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/ploxc/modbux.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/audit .claude/skills/audit && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
audit
GitHub stars
109
Token cost
~2.9k tokens
SKILL.md length
1,409 words
Files
4 (incl. references)
Skills in repo
5
Repo updated
First seen
Licence
MIT

At a glance

Audit one area of Modbux against the eight criteria and write the findings to tmp/AUDIT-<area.md, changing no code.

  • Works in 8 steps: What the conformance suite cannot see.… → Duplication. Search for the shape, not… → Dead code. Unused exports, unreachable… → …
  • The user asks to audit
  • SKILL.md covers The areas, Before you start, The eight criteria and Reproduce, do not reason, plus 6 more sections
  • Calls npx

What it does

Audit is an agent skill from ploxc/modbux. Audit one area of Modbux against the eight criteria and write the findings to tmp/AUDIT-<area.md, changing no code. Use when the user asks to audit or assess an area, or to re-check one after changes. Do NOT use to review a branch or your own diff — that is /code-review; and do NOT use to execute a finished audit, which is a separate session with fresh context.

Its SKILL.md is about 2.9k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `references/a-meter-is-a-claim.md`, `references/one-bug-three-reports.md` and `references/read-the-library.md`).

It sits in Development. The repository describes itself as: Free open-source Modbus client (master) GUI and server simulator for Windows, macOS and Linux. Desktop tool for Modbus TCP, RTU and RTU over TCP. A modern alternative to Modbus… The licence is MIT.

When your agent uses it

  • The user asks to audit
  • Re-check one after changes
  • Review a branch
  • Your own diff — that is /code-review

Example prompts

  • “/audit”

Requirements

  • Node.js

Workflow steps

8 steps, taken from the first numbered list in SKILL.md.

  1. What the conformance suite cannot see. The store-versus-component IPC
  2. Duplication. Search for the shape, not the name. Two functions doing one
  3. Dead code. Unused exports, unreachable branches, config entries pointing
  4. Deferred comments. Every TODO, FIXME, for now, later, until we,
  5. Test coverage. What is not covered. Think like someone with a field
  6. File size and module shape. Four files stand clear of the rest, and the
  7. Architecture fit. Does this block RTU over TCP, a second client, the
  8. What modbus-serial actually does. For modbus, boundary and shared

What it can do on your machine

Read from SKILL.md and the folder at commit 3313c0f. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npx

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npx, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Audit loads about 2.9k tokens when it runs, and up to ~4.4k if it reads all its reference files. Until then it costs about 93 tokens; SKILL.md has 1,409 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~93
When it runs · the whole SKILL.md, loaded when a task matches
~2.9k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.4k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from ploxc/modbux at commit 3313c0f, republished under its MIT licence (© ploxc). 1,409 words, ~2,914 tokens.

Download SKILL.mdSave it as .claude/skills/audit/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
audit
description
Audit one area of Modbux against the eight criteria and write the findings to tmp/AUDIT-<area>.md, changing no code. Use when the user asks to audit or assess an area, or to re-check one after changes. Do NOT use to review a branch or your own diff — that is /code-review; and do NOT use to execute a finished audit, which is a separate session with fresh context.

Audit one area

Read-only with respect to code. The only file this writes is tmp/AUDIT-<area>.md, which is gitignored. Every improvement you spot becomes a finding, including the one-line obvious ones.

The areas

Split by what the code shares, not by directory size. One area per run.

areawhat it is
modbusmain/modules/modbusClient.ts, modbusServer.ts and modbusServer/
boundarymain/ipc.ts, preload/, shared/types/ipc.ts, main/state.ts, main/windows.ts
sharedshared/ minus types/ipc.ts: schemas, migrations, pure helpers
storesrenderer/src/context/
client-uirenderer/src/components/client/
server-uirenderer/src/components/server/, components/shared/, containers/

Before you start

Read CLAUDE.md, CONTRIBUTING.md and src/__tests__/conformance.test.ts.

The suite already asserts thirteen conventions. Do not report what it asserts — it is green, so those are closed. Audit what a test cannot see.

The eight criteria

Apply all eight. Do not merge them and do not skip the cosmetic ones.

  1. What the conformance suite cannot see. The store-versus-component IPC rule, the folder-per-component judgement, and anything else CONTRIBUTING states as prose under The rules no test can see.

  2. Duplication. Search for the shape, not the name. Two functions doing one job often share no word, so a search for what one is called returns neither. Report identical copies too, because they diverge later. A duplication claim carries its own burden of proof, under Verification. → WHY: a meter is a claim too

  3. Dead code. Unused exports, unreachable branches, config entries pointing at deleted paths, comments naming files that are gone.

  4. Deferred comments. Every TODO, FIXME, for now, later, until we, with its exact location and text.

  5. Test coverage. What is not covered. Think like someone with a field device, not like the author: a unit id of 0 and of 248, an address at 65535 with a data type needing four registers, a serial port that disappears mid-read, a config file from two versions ago.

  6. File size and module shape. Four files stand clear of the rest, and the distribution is the argument rather than any number you pick:

    sh
    find src -name '*.ts' -o -name '*.tsx' | grep -v __tests__ | xargs wc -l | sort -rn | head

    Propose a split only along a real responsibility boundary, never on length alone. Count code lines and test lines separately: a file that looks like the worst offender is sometimes a thin one with a large test block bolted on, and the two call for opposite conclusions.

  7. Architecture fit. Does this block RTU over TCP, a second client, the gateway idea, or anything CHANGELOG.md says is coming?

  8. What modbus-serial actually does. For modbus, boundary and shared: every assumption this code makes about the library is checked against node_modules/modbus-serial/, not against its README. Two of this project's sharper findings came from that gap. → WHY: read the library, not its README

Reproduce, do not reason

Build first. A reproduction against a stale bundle looks like a measurement and is not one:

sh
npx electron-vite build

Then drive it. The e2e fixtures already stand up a server, a client and a socat serial pair:

sh
npx playwright test e2e/specs/01-main/<nn>-<name>.spec.ts

For a claim about the wire, a scratch spec beats reading. For a claim about a schema or a pure helper, npx vitest run <file> in a scratch test is faster than either.

A reproduced defect beats ten lines of reading. Delete your scratch files when you are done.

Recording a finding

Every finding is a heading in this exact form, and then the fields under it:

### <ID> · `<file> <symbol>` · criterion <1-8> · <severity> · size <S|M|L> · reproduced

The ID is the area's initial and a number: F1, CU-01, B-04. Drop reproduced when you did not run it.

The heading is the form, not a suggestion. Six agents were given the field list and five wrote the same heading; the sixth used numbered titles with the fields as bullets, and a grep for severity across the six documents found nothing in that one. The document was fine and the count was wrong.

Under the heading: claim (one sentence) · evidence (the code, or the command and its output) · proposal · recipe if reproduced.

severity — what the app does to a user decides it, not how much it annoys you.

blockingA user gets a wrong answer, a crash, or lost configuration. A malformed frame reaching the socket. A register read as the wrong type. Also: dead code that makes something look covered when it is not.
annoyingRight behaviour, wrong construction. Duplication, a rule enforced in one of two places, untested logic. Nothing a user sees today; the next change here is where it bites.
cosmeticNeither. A stale comment, an unused export, a name that misleads.

size — how much work the proposal is, not how large the defect is. S is one file and no decision. M touches several call sites or needs a small decision you can make from the area alone. L needs a decision that is not yours: a protocol question, a persisted shape, or anything crossing two areas.

Give the exact recipe if you reproduced it — the file contents and the command, complete enough to paste. A recipe that does not work as written is worse than none, because the next person dismisses a real defect.

Anchor on the symbol, not the line. modbusClient.ts readRegisters, not modbusClient.ts:412. A line number is right for one commit; the symbol keeps working. The exception is inside a finding's evidence, where the line is what makes it checkable.

Do not record a file's size as a number. A size is worth writing only as an argument: past the threshold, and here is why it is still one file.

Show full SKILL.md (524 more words)Show less

Also record what you checked and found sound

A document listing only defects leaves the reader unable to tell "examined and correct" from "not looked at". Say what you read and what held, briefly.

A claim you could not settle is an open question, labelled as one. Not a finding.

Verification

Every finding goes to a second agent whose job is to break it. That is not a reviewer looking for problems; it is handed a claim and asked to demonstrate it wrong.

  • refuted — you can demonstrate it is wrong. Give the demonstration.
  • unconfirmed — neither proved nor disproved. Keep it. Say what you checked and what would settle it.
  • confirmed — independently verified.

The bar for rejection is high. A wrong finding costs one look; a dropped correct one costs a defect in a released build. When in doubt: unconfirmed. No verdict returned counts as kept, never as rejected.

Two exceptions, where the burden runs the other way:

  • A duplication claim must be actively substantiated. If you cannot show the two are equivalent in behaviour, refute it and say how they differ.
  • A claim marked reproduced must actually reproduce. Finding one that does not is the most valuable single outcome available to you.

What a finding is worth once it is written

parttrust
the file, the symbol, the evidencehigh, and verifiable
the claim, if reproducedhigh
the claim, if only readgood
the recipelow — the most common defect in an audit is a recipe describing an input that does not trigger the behaviour
the proposallow — a guess by someone who did not read the rest of the file
any summary or statelow — a compression, and compressions interpret

Open the file, reproduce, then decide. Being written down is not evidence.

When more than one area is done

Group the blocking findings by cause before anyone fixes them. Six areas audited in parallel produced 28 blocking findings that turned out to be thirteen causes, and three of those thirteen were invisible from any single document. → WHY: the same bug from three directions

Write tmp/AUDIT-clusters.md: one section per cause, naming the findings it holds, what they share, and what a fix has to settle. Keep the per-finding evidence where it is; the cluster document points, it does not copy.

Check every blocking finding reaches the document:

sh
for a in <areas>; do
  grep -E '^#{3,4} .*· blocking' tmp/AUDIT-$a.md | sed 's/^#*  *//;s/ ·.*//' | while read id; do
    grep -q "$a/$id" tmp/AUDIT-clusters.md || echo "missing: $a/$id"
  done
done

A wrong grouping is a new way to be wrong. A cluster that is really two causes gets fixed as one and half of it survives, so the refutation reviewer is asked to break the grouping as well as the claims.

A cluster's size is not the largest size inside it. Each finding was sized inside one area by someone who could not see the others. Four of the thirteen here needed a decision that fits in no single area, which is size L whatever the findings said.

Finish by reporting

The document path, then one line per finding: severity, symbol, claim. Then stop. Proposing is the whole job, and the session that proved a defect is the worst one to fix it: it is invested in the finding and has read past everything it already dismissed.

© ploxc, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 3 other files (references) in .claude/skills/audit of ploxc/modbux.

  • SKILL.md
  • references/a-meter-is-a-claim.md
  • references/one-bug-three-reports.md
  • references/read-the-library.md

Open the folder on GitHubat commit 3313c0f

Compare with similar skills

Audit next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Audit compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Audit this skillploxc/modbux109—~2.9kAutomated safety check: PassMIT
Vercel Composition Patternssupabase/supabase111k59 repos~726Automated safety check: PassMIT
Finishing a Development Branchobra/superpowers296k5 repos~1.9kAutomated safety check: PassMIT
Typescript Advanced Typesrolling-scopes/rsschool-app10k25 repos~4.2kAutomated safety check: PassMPL-2.0
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Code Review ChecklistshareAI-lab/learn-claude-code78k5 repos~1.1kAutomated safety check: PassMIT

Similar skills

  • Vercel Composition Patterns

    supabase/supabase

    Official

    React composition patterns that scale. An agent skill from supabase/supabase.

    111k GitHub starsUsed in 59 repos~726 tokens
    DevelopmentAuto-check passed

  • Finishing a Development Branch

    obra/superpowers

    Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    296k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed

  • Typescript Advanced Types

    rolling-scopes/rsschool-app

    Master TypeScript's advanced type system including generics, conditional types, mapped types, template literals, and utility types for building type-safe applications.

    10k GitHub starsUsed in 25 repos~4.2k tokens
    DevelopmentAuto-check passed

  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed

  • Code Review Checklist

    shareAI-lab/learn-claude-code

    Reviews code against a five-part checklist covering security, correctness, performance, maintainability and testing, and reports findings in a fixed format.

    78k GitHub starsUsed in 5 repos~1.1k tokens
    DevelopmentAuto-check passed

  • Greploop

    onyx-dot-app/onyx

    Iteratively improves a PR (GitHub), MR (GitLab), or shelved changelist (Perforce) until Greptile gives it a 5/5 confidence score with zero unresolved comments.

    32k GitHub starsUsed in 4 repos~3.3k tokens
    DevelopmentAuto-check passed

More from ploxc/modbux

  • Precommit

    ploxc/modbux

    Run the checklist before committing or merging — read the diff, lint, typecheck, the unit suite, the e2e specs the change touches, then report and commit.

    109 GitHub stars~1.5k tokensUpdated yesterday
    Auto-check passed

  • Handover

    ploxc/modbux

    Empty a session into files before its context goes — decide with the user what gets written down, write it, and only then say what the next session needs.

    109 GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed

  • Prose

    ploxc/modbux

    Measure a sentence you just wrote against the thing it describes, then prune the block it lands in.

    109 GitHub stars~2.1k tokensUpdated yesterday
    Auto-check passed

  • Todo

    ploxc/modbux

    Route something you want to record to the place that holds it — TODO.md, a GitHub issue, the memory directory, or the plan in flight.

    109 GitHub stars~898 tokensUpdated yesterday
    Auto-check passed

Categories

Questions about Audit

What does Audit do?

Audit one area of Modbux against the eight criteria and write the findings to tmp/AUDIT-<area.md, changing no code. Audit is an agent skill from ploxc/modbux.md, changing no code.

When should I use Audit?

Audit fits situations like: the user asks to audit; re-check one after changes; review a branch; your own diff — that is /code-review.

How do I install Audit in Claude Code?

Run `npx skills add ploxc/modbux --skill audit -a claude-code`. Or copy the skill folder (.claude/skills/audit in ploxc/modbux) into .claude/skills/audit in your project. Claude Code loads it when a task matches its description.

How do I install Audit in Codex?

Run `npx skills add ploxc/modbux --skill audit -a codex`. Or copy the skill folder (.claude/skills/audit in ploxc/modbux) into .agents/skills/audit in your project. Codex loads it when a task matches its description.

Can I use Audit in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add ploxc/modbux --skill audit -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/audit, .gemini/skills/audit, .github/skills/audit and .opencode/skills/audit in your project.

What does Audit need to run?

Going by SKILL.md and its folder, Audit needs the command-line tools its instructions call (npx). Our summary lists: Node.js.

Does Audit access the network?

SKILL.md contains no URLs. Its commands use npx, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Audit safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Audit use?

Audit is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Audit use?

About 2.9k tokens (SKILL.md is roughly 12k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 1.5k tokens, read only when the agent opens those files.

What are the alternatives to Audit?

Skills that share tags, products or a category with Audit: Vercel Composition Patterns (supabase/supabase, 111k stars), Finishing a Development Branch (obra/superpowers, 296k stars), Typescript Advanced Types (rolling-scopes/rsschool-app, 10k stars) and PR Babysitter (openinterpreter/openinterpreter, 69k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Audit?

ploxc (a GitHub organization) maintains it in ploxc/modbux, which has 109 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 7, 2026.

Source: ploxc/modbux on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.