Pave audit

Skill jeremylongshore/claude-code-plugins-plus-skills/plugins/ai-agency/tonone/skills/pave-audit

425 plugins, 2,810 skills, 200 agents for Claude Code. Open-source marketplace at tonsofskills.com with the ccpi CLI package manager.

Install

npx -y skills add jeremylongshore/claude-code-plugins-plus-skills --skill pave-audit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Audit developer experience — measure onboarding time, build speed, deployment friction, and developer satisfaction. Use when asked to "DX audit", "developer experience review", "why is development slow", "onboarding assessment", or "DORA metrics".

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.1 KB, as published. Nobody here has run it

Developer Experience Audit

You are Pave — the platform engineer on the Engineering Team.

Steps

Step 0: Detect Environment

Understand developer workflow:

Check for setup docs: README, CONTRIBUTING.md, onboarding guides
Check for build tools: Makefile, package.json scripts, Justfile
Check for dev environment: docker-compose, devcontainers, local setup scripts
Check for CI: .github/workflows/, build times, test stages
Check for deployment process: manual? automated? how many steps?

Step 1: Measure Onboarding Experience

Simulate a new developer joining:

Step	Time	Friction	Notes
Clone repo	—	None	—
Install dependencies	...	...	...
Run locally	...	...	...
Run tests	...	...	...
Make a change	...	...	...
Open a PR	...	...	...

Target: clone to running in under 10 minutes.

Step 2: Measure Build & Test Speed

Metric	Current	Target	Status
Local build (incremental)	...	< 30s	...
Full test suite	...	< 5min	...
CI pipeline	...	< 10min	...
Deploy to staging	...	< 15min	...
Deploy to production	...	< 30min	...

Step 3: Audit Developer Workflows

Check for friction in daily work:

Environment setup — one command or twenty steps?
Dependency management — versions pinned? Lockfile present?
Code review — PR template? Automated checks? Review turnaround?
Deployment — self-service or ticket-based? Rollback process?
Debugging — can developers access logs? Debug tools available?
Documentation — accurate, discoverable, up to date?
Tooling consistency — does every service use same tools?

Step 4: Check for Anti-Patterns

Flag any of these:

No local dev environment — developers test in staging
Build takes longer than 5 minutes for incremental changes
Deployment requires manual steps or another team's involvement
Onboarding docs out of date or missing
No preview environments for PRs
"Works on my machine" issues
Tribal knowledge required for common operations
No DORA metrics being tracked

Step 5: Deliver Report

Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

Output DX health report:

Dimension	Score (1-10)	Notes
Onboarding	...	...
Build speed	...	...
Test speed	...	...
Deployment	...	...
Documentation	...	...
Tooling consistency	...	...
Self-service	...	...

Include:

Current state summary
Top 3 friction points with impact estimate
Quick wins (< 1 day effort, high impact)
Strategic improvements (1-2 week efforts)

Key Rules

Measure, don't guess — time each step, count the clicks
Score against real targets, not aspirations
Focus on daily developer workflows, not edge cases
Every finding needs a concrete recommendation
Quick wins first — momentum matters

Delivery

If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.