Best for
- Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK".
mblode/agent-skills/skills/dx-audit/SKILL.md
Audits the smallest relevant developer-facing surface of a library, CLI, SDK, or npm package across API contracts, errors, CLI behavior, public types, onboarding, and config. Uses candidate-first rule loading, bounded local evidence, and compact root-cause findings. Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK". For end-user UI use ui-design Audit mode,
Decision brief
Audit or improve what developers import, run, configure, or read when something fails.
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/mblode/agent-skills --skill "skills/dx-audit"Inspect the Agent Skill "dx-audit" from https://github.com/mblode/agent-skills/blob/e97a3b383f5944f90d41eb92b24b4fb3b917a7f9/skills/dx-audit/SKILL.md at commit e97a3b383f5944f90d41eb92b24b4fb3b917a7f9. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
Choose the narrowest mode supported by the request:
Default to git diff against the repository's normal base, then keep only changed files reachable through a public entry point. With no useful diff, use the command, export, package, error, or config named by the user.
Default to git diff against the repository's normal base, then keep only changed files reachable through a public entry point. With no useful diff, use the command, export, package, error, or config named by the user.
Take these rungs in order:
Read rules/sections.md, then select only prefixes applicable to the locked surface:
Permission review
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 93/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 82 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Audit or improve what developers import, run, configure, or read when something fails.
ui-design Audit mode), agent trust review
(ax-audit), prose rewrite (docs-writing), README rewrite (readme-creator), or repository
architecture review (codebase-architecture).Choose the narrowest mode supported by the request:
Before exploration, write a one-line scope receipt:
Scope: <mode>; surfaces: <commands/exports/config>; prefixes: <err-, cli->; excludes: <UI/docs/architecture/private internals>
If several skills are invoked, keep only the developer-facing surfaces above. Let sibling skills own their areas without duplicating their search or findings. "DX", "gold standard", and "review holistically" do not by themselves authorize a multi-repo or whole-package sweep.
DX audit progress:
- [ ] 1. Lock intent, public surfaces, and exclusions
- [ ] 2. Trace the minimum local evidence path
- [ ] 3. Select prefixes and candidate rule files
- [ ] 4. Confirm and rank material findings
- [ ] 5. Report, or fix only when requested
- [ ] 6. Re-run the same checks and record evidence
Default to git diff against the repository's normal base, then keep only changed files reachable
through a public entry point. With no useful diff, use the command, export, package, error, or config
named by the user.
Public reachability comes from evidence such as package.json exports/bin, a command registry,
an exported type, a documented config loader, or an observed error path. Do not audit a private
helper unless a public caller exposes its behavior.
Take these rungs in order:
--help, --version, one success path, and
one invalid-input path. Do not trigger a real mutation merely to test DX.Stop when the behavior is proven, disproven, private, or outside scope. Do not browse general best practice articles, inventory unrelated apps, build static repo maps, or spawn overlapping scouts. External research is for an explicit comparison request or a named uncertainty local evidence cannot resolve. In an explicit exhaustive audit, parallel work may partition disjoint public surfaces; it must not run several generic whole-repo reviews.
Read rules/_sections.md, then select only prefixes applicable to the locked 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 | HIGH | 13 |
| 4 | types- | Exported type ergonomics | HIGH | 5 |
| 5 | onboard- | Install and first run | HIGH | 4 |
| 6 | config- | Config ergonomics | MEDIUM | 3 |
Map surfaces to prefixes: a public API entry point uses api-, types-, and reached err-
paths; a CLI uses cli- and reached err- paths; exported declarations use types-, plus
api- only when behavior changes; install and first run use onboard-; config loaders use
config- and reached err- paths.
Applicability outranks global priority. A CLI-only audit runs applicable err- rules before
cli-; it does not load api- merely because API rules have higher impact.
For a targeted audit:
For an explicit exhaustive audit, read every rule in the selected prefixes. Read
references/dx-principles.md only when the user asks for rationale or a borderline finding needs a
tie-breaker. Read rules/_template.md only when adding or editing a rule.
Capability-gate candidate rules even inside a selected prefix:
stdin applies when the command semantically accepts file or stream data.Audit-only requests are read-only. A request to improve or fix authorizes localized changes inside the scope receipt, not a redesign of adjacent docs, UI, or architecture.
Use this compact output:
## 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.
Only list files with findings. If none are material, return one pass line naming the surfaces and
rule files checked. Do not emit a ✓ pass entry for every clean file or repeat a DX principle under
every finding. In exhaustive mode, include every material finding; list clean files only when the
user requests compliance-style evidence.
For fix mode, replace Deferred with Changed and Verification, including the exact commands or
runtime probes that passed.
Before sending the report, check:
Report preflight:
- every cited rule file was opened
- every [IMPACT] exactly matches that file's frontmatter
- the inspected-file count matches the unique files named
- no out-of-scope or per-clean-file filler entered the report
Re-open every touched or cited location, rerun the same safe probes and focused project checks, and reapply the same candidate rules. A clean build alone does not prove CLI behavior; a runtime probe alone does not prove exported types. Verification evidence must match the finding.
| File | Read when |
|---|---|
rules/_sections.md | Every audit, for prefix applicability and priority |
rules/<prefix>-*.md | A targeted candidate exists, or the user requests exhaustive coverage |
references/dx-principles.md | Rationale is requested or a finding is borderline |
references/evaluation-scenarios.md | Evaluating or changing this skill's workflow |
rules/_template.md | Adding or editing a rule |
npx <pkg> and an existing global install
both resolve the registry copy, so --help, exit codes, and error strings describe a release the
working tree has not changed. Build, then invoke the local entry point (node ./dist/cli.js).ui-design Audit mode: rendered end-user frontend quality and accessibilityax-audit: agentic application architecture and trustdocs-writing: documentation prose and information qualityreadme-creator: README structure and first-reader narrativeagents-md: AGENTS.md and CLAUDE.md instruction filescodebase-architecture: repository structure, module contracts, and the guardrails inside the repo, rather than the surface a package ships outwardFrequently asked questions
Audit or improve what developers import, run, configure, or read when something fails.
The source record exposes this install command: npx skills add https://github.com/mblode/agent-skills --skill "skills/dx-audit". Inspect the command and pinned source before running it.
Alternatives
NintendaDev/unikit-ai
Generate and maintain the project's TECHNICAL documentation from its codebase — scans the project structure, tech stack, and module boundaries, then writes a lean README landing page plus detailed topic pages (architecture, modules, setup, build, APIs), only the docs that are relevant. Use whenever the user wants to create, update, or validate documentation of the CODE or the project itself, e.g. "generate documentation", "create docs", "write the README", "update the project docs", "document th
eugenelim/agent-ready-repo
Use when implementing or resuming a non-trivial repository change: a feature, behavior-changing fix, refactor, migration, framework or dependency upgrade, schema or API change, performance work, infrastructure or build-system change, reversion, or an existing build spec under `docs/specs/`. Also use for bare continuation commands ('resume', 'continue', 'keep going', 'pick up where I left off', 'let's get going') when conversation or workspace context identifies active build work. Do not use for
mgiovani/cc-arsenal
Multi-agent review team: architecture, security, performance, testing, style, docs/UX, plus an adversary that cross-examines the other 6, for security-sensitive, architectural, or large PRs (15+ files) where a single-agent pass risks missing cross-cutting issues. Use for auth/payments/PII changes, schema/pattern changes, compliance sign-off, or when asked to 'get the review team on this' / 'multi-agent review' / 'thorough review before merge'. For a standard PR or a quick pre-merge check, use /r
th3vib3coder/vibe-science
Scientific research engine for hypothesis testing, literature gap analysis, experimental validation, and data-driven discovery. Enforces adversarial review (Reviewer 2), 32 quality gates, tree search over hypotheses, confounder harness for quantitative claims, and serendipity detection. TRIGGER when: user asks to analyze scientific data, test hypotheses, validate findings, search for research gaps, design experiments, or investigate results. DO NOT TRIGGER when: pure code review, documentation w