Pave Audit Agent Skill

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.