К основному содержанию
скилл CX Codex

dx-audit — скилл для Claude Code: аудит CLI, SDK и библиотек

Проверяет публичные API, ошибки, вывод CLI и экспортируемые типы по 38 правилам. Полезен перед релизом библиотеки или SDK.

Установить в Claude Code · Через Skills CLI (Vercel) Все способы и платформы ↓
npx skills add mblode/agent-skills --skill dx-audit -a claude-code
Открыть на GitHub

Что делает dx-audit

Скилл разбирает то, с чем сталкивается разработчик: что импортируется из пакета, что происходит при запуске команды, как выглядит ошибка и как читается конфиг. Работает в трёх режимах. По умолчанию — точечный аудит названной или изменённой публичной поверхности, только чтение. Режим Fix включается, когда вы просите исправить, и тогда правки остаются внутри заранее записанной области. Exhaustive нужен, если явно просите пройти весь пакет.

Перед чтением кода скилл фиксирует область работ одной строкой: режим, поверхности, префиксы правил, исключения. Дальше собирает доказательства — манифест, диф, ближайшие тесты — и запускает безопасные пробы: --help, --version, успешный путь, путь с неверным вводом и тот же вызов с выводом в | cat, чтобы увидеть поведение вне TTY. Для пакетов есть pnpm dlx publint и pnpm dlx @arethetypeswrong/cli --pack . после сборки. Вот тут стоит быть внимательным: упаковка может запустить lifecycle-скрипты, поэтому сначала просмотрите их или возьмите одноразовый чекаут. Реальные мутации скилл не трогает, для этого есть --dry-run.

Правила разложены по префиксам: api-, err-, cli-, types-, onboard-, config-. Приоритет у api- и err-, но применимость важнее приоритета — аудит только CLI не подтянет правила API. Находки группируются по корневым причинам, а не по каждой функции отдельно: отсутствие кодов ошибок или --json по всей поверхности — это одна находка. В отчёте сначала идут CRITICAL, потом остальное до пяти пунктов.

Какие задачи решает

  • проверить публичные экспорты пакета перед публикацией в npm
  • найти команды CLI, которые возвращают код 0 при ошибке и ломают CI
  • увидеть, как команда ведёт себя, когда stdout уходит в пайп
  • собрать разрозненные проблемы с кодами ошибок в одну находку
  • оценить, что происходит при первом запуске после установки

Примеры запросов агенту

  • проведи аудит моей CLI-команды tool status
  • сделай ревью публичного API этого SDK
  • исправь найденные проблемы с кодами ошибок в CLI

Как установить dx-audit

1Через Skills CLI (Vercel)

npx skills add mblode/agent-skills --skill dx-audit -a claude-code

2Вручную: положить файлы

~/.claude/skills/dx-audit/SKILL.md

Папка скилла целиком; для одного проекта — .claude/skills/dx-audit/

По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов

Из того же набора15

scaffold-nextjs Разворачивает монорепозиторий Next.js на Turborepo с Blode UI, Ultracite, хуками Lefthook и настройкой для GitHub и Vercel. Пригодится при старте нового веб-приложения. CX Codex +1 720установок scaffold-cli Разворачивает новый TypeScript CLI и npm-пакет по готовым шаблонам: конфиги, исходники, CI и публикация. Пригодится, когда начинаешь инструмент с нуля. CX Codex +1 690установок autoship Ведёт релиз npm-пакета от changeset до проверки версии в реестре. Полезен, когда CI версионирует, но не публикует. CX Codex +1 623установок ax-audit Проверяет интерфейсы и логику работы агентов по 24 правилам архитектуры и доверия. Помогает найти пробелы в подтверждении действий до релиза. CX Codex +1 523установок pr-creator Пишет заголовок и тело GitHub PR в стиле разработчика, а не пересказа диффа. Пригодится, когда надо открыть PR или переписать его описание. CX Codex +1 519установок planning Собирает исполнимый план фичи по фактам из репозитория: вертикальные срезы, явные решения, критерии проверки. Пригодится перед крупной правкой. CX Codex +1 446установок codebase-architecture Проектирует структуру TypeScript-кода, укрупняет мелкие модули и ставит проверки, которые держат репозиторий в форме. CX Codex +1 441установок eli5 Скилл выбирает форму объяснения: обычный текст, упрощённый английский, схема, интерактивная HTML-страница или видео. Пригодится, когда ответ агента утонул в жаргоне. CX Codex +1 309установок

Похожие

audit-verify-explain-grade-5 MengTo Скилл заставляет агента проверить работу по фактам, а потом объяснить результат простыми словами. Пригодится, когда нужно разобрать чужой фикс или отчёт о тестах. CX Codex +1 1 400установок security-audit cloudflare Проверяет кодовую базу на уязвимости и ищет нарушения границ доверия. Пригодится перед релизом или для точечного разбора опасных участков кода. CX Codex +1 54 800установок ponytail-audit DietrichGebert Проверяет репозиторий и ранжирует ошибки, риски и лишний код. Подойдёт, если нужен разовый разбор без автоматических правок. CX Codex +1 45 400установок deep-audit pedrohcgs Разбирает теорию, доказательство, статью или кодовую базу на части, гоняет по ним независимых скептиков и чинит всё подтверждённое. Нужен, когда одного прохода ревью мало. CX Codex +1 ★ 1 668звёзд репо audit-prep-assistant trailofbits Скилл готовит репозиторий к внешнему аудиту безопасности по чеклисту Trail of Bits. Помогает сформулировать цели проверки, прогнать статический анализ и собрать документацию. CX Codex +1 5 700установок production-audit affaan-m Проверяет приложение перед релизом: что сломается в проде, что починить до запуска. Работает на локальных данных, без отправки кода наружу. CX Codex +1 4 700установок

Рядом в теме «Настройка агента: память, контекст, субагенты»

Все скиллы по теме «Настройка агента: память, контекст, субагенты» →

Вопросы о dx-audit

Как установить dx-audit в Claude?

Выполните npx skills add mblode/agent-skills --skill dx-audit -a claude-code. Скилл окажется в ~/.claude/skills/dx-audit/SKILL.md.

Что делает dx-audit?

Проверяет публичные контракты, экспорты пакета, вывод в пайпах, ошибки и конфигурацию по 38 правилам. По умолчанию только читает код и выдаёт отчёт с находками.

Чем точечный режим отличается от exhaustive?

Точечный разбирает одну названную или изменённую публичную поверхность, exhaustive — весь пакет. Фразы вроде «review holistically» сами по себе не расширяют точечный аудит.

Исходный текст

SKILL.md · MIT
---
name: dx-audit
description: Audits libraries, CLIs, and SDKs using 38 rules for public contracts, package exports, piped output, errors, and configuration. Use when asked to "audit my CLI", "review my SDK", or diagnose package type resolution.
---

# DX Audit

Audit or improve what developers import, run, configure, or read when something fails.

- **IS:** a bounded review of public APIs, developer-facing errors, CLI commands, exported types, install and first-run behavior, and config, with fixes only when asked.
- **IS NOT:** a repo-wide quality sweep (`tidy`), end-user UI (`ui-design` Audit mode), agent trust review (`ax-audit`), public site or docs agent scores (`agent-ready`), docs prose or a README (`ghostwriter`), repository architecture (`codebase-architecture`), or building a new CLI (`scaffold-cli`).

## Modes

Pick the narrowest mode the request supports, and write a one-line scope receipt before reading code:

| Mode | When | Output |
|------|------|--------|
| Targeted (default) | a named or changed public surface | findings report, read-only |
| Fix | the user says fix, improve, simplify, or implement | localized edits inside the receipt, then verification |
| Exhaustive | the user explicitly asks for the whole package or every public surface | every material finding, partitioned by surface |

```text
Scope: <mode>; surfaces: <commands/exports/config>; prefixes: <err-, cli->; excludes: <UI, docs, architecture, private internals>
```

"DX", "gold standard", and "review holistically" do not by themselves widen a targeted audit into exhaustive. When several skills are invoked together, this one owns only the surfaces above.

## Audit progress

```text
DX audit progress:
- [ ] 1. Lock the public surface and write the scope receipt
- [ ] 2. Gather local evidence and run the safe probes
- [ ] 3. Select prefixes, then open candidate rules
- [ ] 4. Rank root causes
- [ ] 5. Report, or fix when asked
- [ ] 6. Verify on the same scope
```

### 1. Lock the public surface

Start from `git diff` against the normal base and keep only changed files reachable from a public entry point: `package.json` `exports` or `bin`, a command registry, an exported type, a documented config loader, or an observed error path. With no useful diff, use the command, export, error, or config the user named. A private helper enters scope only through a public caller.

### 2. Gather evidence, then stop

1. Local instructions, the manifest, and the diff or named entry point.
2. Direct public dependencies and the nearest tests that pin behavior.
3. Safe probes against the local build:
   - CLI: `--help`, `--version`, one success path, one invalid-input path, and the same command with stdout piped (`| cat`) to see non-TTY behavior. Never trigger a real mutation to test DX; use `--dry-run` where it exists.
   - Package: `pnpm dlx publint` and `pnpm dlx @arethetypeswrong/cli --pack .` after a build. These inspect packaging, but packing may invoke lifecycle scripts. Inspect those scripts first or use a disposable checkout before calling `--pack`.
4. The prior release contract, only when the diff changes a public export, signature, or return shape.

Stop when the behavior is proven, disproven, private, or out of scope. External research is for an explicit comparison request or a named uncertainty local evidence cannot resolve; `references/standards-map.md` carries the standards this skill already leans on.

### 3. Dispatch rules candidate-first

Read `rules/_sections.md`, then select prefixes by surface:

| Priority | Prefix | Category | Default impact | Rules |
|----------|--------|----------|----------------|-------|
| 1 | `api-` | Public API and SDK | CRITICAL | 7 |
| 2 | `err-` | Developer-facing errors | CRITICAL | 5 |
| 3 | `cli-` | CLI UX for humans and agents | HIGH | 13 |
| 4 | `types-` | Exported type ergonomics | HIGH | 5 |
| 5 | `onboard-` | Install and first run | HIGH | 5 |
| 6 | `config-` | Config ergonomics | MEDIUM | 3 |

| Surface | Prefixes |
|---------|----------|
| Public API entry point | `api-`, `types-`, reached `err-` paths |
| CLI command | `cli-`, reached `err-` paths |
| Exported declarations | `types-`, plus `api-` when behavior changed |
| Install, `package.json`, first run | `onboard-` |
| Config loader | `config-`, reached `err-` paths |

Applicability outranks priority: a CLI-only audit never loads `api-` because API rules rank higher.

Targeted mode: list the filenames for the selected prefixes (the names are the checklist), look for concrete evidence, then open only the rule files a finding needs. Exhaustive mode: read every rule in the selected prefixes.

Capability gates, applied inside a selected prefix:

- Structured JSON input, schema introspection, and compact polling snapshots apply when automation or agent use is promised, requested, or already supported.
- Dry-run and confirmation apply to destructive, expensive, or hard-to-reverse mutations.
- Progress and resume apply to operations that can block, outlive one command, or be retried after ambiguous output.
- `stdin` applies when the command semantically accepts file or stream data.
- Stable-contract comparison applies only when a public contract changed.

### 4. Rank root causes, not instances

- Order CRITICAL, HIGH, MEDIUM by each cited rule's frontmatter `impact`, copied exactly. Impact is the rule's declared consequence, not a confidence score: exit 0 on failure in one subcommand is still HIGH, because the CI gate it defeats is the same. Open the rule file before citing it, since an id cited from memory drifts from the file, and drop the citation if no such file exists.
- Merge repeated instances of one root cause into one finding with up to three representative locations. Missing JSDoc, error codes, or `--json` across a surface is one finding, not one per symbol.
- A missing feature with no current consumer path is not a defect.
- Targeted mode: every CRITICAL finding, then the highest-value remainder up to five total; summarize the rest by category.

### 5. Report or fix

Audit requests are read-only. A fix request authorizes localized changes inside the receipt, not a redesign of adjacent docs, UI, or architecture.

```markdown
## DX Audit

Scope: `tool status` CLI; `err-`, `cli-`; 4 files inspected.

### Findings
- [HIGH] `cli-idempotent-resume` at `src/start.ts:42`: retrying the same target creates a second job.
  Fix: return the existing job id and state unless the caller passes `--fresh`.

### Deferred
- 2 lower-impact config candidates were outside the locked CLI scope.
```

List only files with findings; a clean surface gets one pass line naming the surfaces and rule files checked. In fix mode, replace `Deferred` with `Changed` and `Verification` (the exact commands or probes that passed). Length follows findings, not the template.

### 6. Verify on the same scope

Re-open every touched or cited location, rerun the same probes and focused project checks, and reapply the same candidate rules. Match the evidence to the claim: a clean build does not prove CLI behavior, a runtime probe does not prove exported types, and only `attw` or a consumer-style `tsc` import proves a types resolution.

## Reference files

| File | Read when |
|------|-----------|
| `rules/_sections.md` | Every audit, for prefix applicability and priority |
| `rules/<prefix>-*.md` | A candidate has evidence, or exhaustive mode |
| `references/standards-map.md` | A finding needs an external citation, the user asks why something is a rule, or a borderline call needs a tie-break |
| `rules/_template.md` | Adding or editing a rule |

## Gotchas

- **`pnpm dlx <pkg>` (or `npx`) and a global install probe the registry copy, not the working tree.** `--help`, exit codes, and error strings then describe a released version. Build, then invoke the local entry point (`node ./dist/cli.js`).
- **`process.stdout.isTTY` is `undefined` under a pipe, not `false`.** A guard written as `isTTY === false` never disables color or spinners when piped, so ANSI codes reach the redirected file. Probe with `| cat` rather than trusting the guard.
- **`process.exit(1)` right after `console.log` can truncate the output it was meant to explain.** stdout writes are asynchronous when piped, so a CLI that prints usage and calls `exit()` can emit nothing under `| cat`. The fix is `process.exitCode = 1` and a natural return (`cli-exit-codes`).
- **An `exports` map that reads correctly can still resolve wrong.** `"require"` pointing at a `.js` file under `"type": "module"` masquerades as CJS, and a `types` condition listed after `import` is never reached. `publint` and `attw` catch both; reading the map does not (`onboard-exports-resolve-typed`).

## Related skills

- `ui-design` Audit mode: rendered end-user frontend quality and accessibility
- `ax-audit`: same files, different reader; asks whether an agent can operate and recover, where this skill asks whether a developer finds the surface ergonomic
- `scaffold-cli`: builds a new CLI with these patterns already in place; this skill audits what exists
- `tidy`: general correctness and structure of a diff
- `agent-ready`: public HTTP/docs agent scores (AFDocs, Is Agentic, Is It Agent Ready); this skill audits the package once it exists
- `ghostwriter`: documentation prose, README structure, and the first-reader narrative
- `agents-md`: AGENTS.md and CLAUDE.md instruction files
- `codebase-architecture`: repository structure and module contracts inside the repo, rather than the surface a package ships outward

Maintenance only: `evals/evals.json` and `evals/evaluation-scenarios.md` hold regression scenarios for changes to this skill; neither loads during a user task.

© mblode · MIT · mblode/agent-skills

Смотрите также

Спонсоры проекта

Компании, которые помогают держать аналитику открытой