| name | developer-experience-auditor |
| author | JM Labs (Javier Montaño) |
| description | Developer experience friction analysis, onboarding quality, and tooling assessment. Trigger: "audit DX", "developer experience", "onboarding quality", "developer friction".
|
| allowed-tools | ["Read","Glob","Grep","Bash","Agent"] |
Developer Experience Auditor
Evaluate the developer experience across setup, development workflow, testing, debugging, and deployment for friction points that slow teams down.
Guiding Principle
"Developer productivity is a multiplier. Every minute of friction compounds across every developer, every day."
Procedure
Step 1 — Setup & Onboarding Assessment
- Test the README setup instructions for completeness and accuracy.
- Measure "time to first green build" from a clean clone.
- Check for setup automation:
make setup, docker compose up, devcontainer config.
- Identify undocumented prerequisites (tools, versions, environment variables).
- Assess
.env.example completeness and variable documentation [HECHO].
Step 2 — Development Workflow Analysis
- Evaluate hot reload / watch mode configuration for fast feedback loops.
- Check linting and formatting configuration: are they consistent and automated?
- Assess debugging support: source maps, debug configs, logging infrastructure.
- Verify IDE support: TypeScript configs, editor settings (
.editorconfig), recommended extensions.
- Check for local development parity with production (Docker, seed data)
[HECHO].
Step 3 — Testing & CI Friction
- Measure time to run the test suite locally.
- Check if tests can run independently (no shared state, no order dependency).
- Assess test data setup: factories, fixtures, seed scripts.
- Evaluate CI feedback time from push to result.
- Check for flaky tests that erode trust in the test suite
[INFERENCIA].
Step 4 — DX Score & Recommendations
- Score each category: setup (25%), workflow (25%), testing (25%), documentation (25%).
- Identify the top 3 friction points by developer impact.
- Recommend quick wins vs. structural improvements.
- Benchmark against DX best practices.
Quality Criteria
- Setup instructions tested against actual project state
[HECHO]
- Friction points quantified with time estimates
- Recommendations prioritized by developer impact
- Both new developer and experienced developer perspectives considered
Anti-Patterns
- Assuming the README is accurate without actually following the steps
- Ignoring IDE and editor configuration as "not important"
- Measuring only CI time while ignoring local development speed
- Treating DX as a nice-to-have instead of a productivity multiplier
