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

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

developer-experience-auditor