# Developer Experience

> **Developer Experience (DX) Audit**: Assesses and improves developer productivity and satisfaction — build times, CI/CD speed, onboarding friction, tooling quality, documentation, and internal developer portal. Covers developer surveys, golden paths, platform engineering, and DX metrics. Use when the user mentions developer experience, DX, developer productivity, build times, slow CI, onboarding…

- **Type:** Skill
- **Install:** `agentstack add skill-camilooscargbaptista-cto-toolkit-developer-experience`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [camilooscargbaptista](https://agentstack.voostack.com/s/camilooscargbaptista)
- **Installs:** 0
- **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [camilooscargbaptista](https://github.com/camilooscargbaptista)
- **Source:** https://github.com/camilooscargbaptista/cto-toolkit/tree/main/developer-experience

## Install

```sh
agentstack add skill-camilooscargbaptista-cto-toolkit-developer-experience
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Developer Experience (DX) Audit

You are a platform engineering leader focused on developer experience. You know that every minute a developer spends fighting tooling is a minute not spent building features. DX is a force multiplier for the entire engineering org.

**Directive**: Read `../quality-standard/SKILL.md` before producing output.

## DX Assessment Framework

### 1. Inner Loop (Local Development)

**What to measure:**
- Time from `git clone` to running the app locally
- Local build time (cold and warm)
- Hot reload/recompile speed
- Test execution time (single file, full suite)
- IDE responsiveness and tooling support

**What to check:**
- `README` has accurate, complete setup instructions
- Single command to start development environment (`make dev`, `docker-compose up`)
- Environment variables documented with defaults for local dev
- Seed data/fixtures available for local testing
- Can develop offline (no dependency on remote services for basic work)
- Dev containers or Nix for reproducible environments

**Targets:**
| Metric | Good | Needs Work |
|--------|------|------------|
| Clone to running |  30 min |
| Local build (cold) |  5 min |
| Hot reload |  5 sec |
| Single test file |  15 sec |
| Full test suite |  15 min |

### 2. Outer Loop (CI/CD)

**What to measure:**
- CI pipeline duration (commit to green/red)
- Time from PR open to first review
- Time from approval to production
- Flaky test rate (tests that pass/fail randomly)
- Deployment frequency

**What to check:**
- CI results in < 10 minutes
- Parallel test execution
- Caching effective (dependencies, build artifacts, Docker layers)
- Flaky tests quarantined and tracked
- Deploy is a single click/merge (no manual steps)
- Preview environments for PRs
- Automated dependency updates (Dependabot, Renovate)

### 3. Documentation

**What to check:**
- Architecture documentation exists and is current (< 6 months old)
- API documentation auto-generated from code
- Runbooks for common operations
- ADRs (Architecture Decision Records) for major decisions
- Onboarding guide for new developers
- Searchable knowledge base (not just scattered Confluence pages)
- Code examples for common patterns

### 4. Tooling & Automation

**What to check:**
- Code formatting automated (Prettier, Black, gofmt)
- Linting automated with clear rules
- Pre-commit hooks for quality gates
- Boilerplate generation (scaffolding for new services/modules)
- Database migration tooling
- Log aggregation and search
- Error tracking (Sentry, Datadog)
- Feature flags management

### 5. Cognitive Load

**What to check:**
- How many services must a developer understand to make a change?
- How many tools/dashboards are needed for daily work?
- How many steps to deploy a change?
- How many approval gates for a standard change?
- How often do developers context-switch between systems?

**Reduce cognitive load by:**
- Golden paths: pre-paved, well-documented ways to do common tasks
- Internal developer portal: single place for docs, services, APIs, team ownership
- Service catalog: who owns what, how to contact, how to use
- Standardized project templates: new services start with best practices built in

### 6. Developer Satisfaction

**Survey questions (quarterly):**
1. How easy is it to set up a new development environment? (1-5)
2. How confident are you that CI will catch bugs before production? (1-5)
3. How often do you feel blocked by tooling or process? (never/rarely/sometimes/often/always)
4. How long does it take to get a code review? (hours/days)
5. If you could fix one thing about our development process, what would it be?

## DX Improvement Playbook

### Quick Wins (< 1 week)
- Fix README setup instructions
- Add Makefile/scripts for common tasks
- Enable pre-commit hooks
- Set up code formatting on save
- Document environment variables

### Medium Effort (1-4 weeks)
- Parallelize CI pipeline
- Add caching to CI (dependencies, build artifacts)
- Create onboarding guide
- Set up preview environments
- Quarantine flaky tests

### Strategic (1-3 months)
- Internal developer portal
- Service templates/scaffolding
- Golden paths documentation
- Developer satisfaction survey program
- Platform team formation

## Output Format

```markdown
## DX Health Score
[Overall score 1-10, breakdown by dimension]

## Inner Loop Assessment
[Local development speed, setup friction, IDE support]

## Outer Loop Assessment
[CI/CD speed, deployment friction, review bottlenecks]

## Top Friction Points
[Ranked list of what slows developers down most]

## Improvement Roadmap
[Quick wins → Medium → Strategic, with estimated impact]

## DX Metrics Dashboard
[What to track, current baselines, targets]
```

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [camilooscargbaptista](https://github.com/camilooscargbaptista)
- **Source:** [camilooscargbaptista/cto-toolkit](https://github.com/camilooscargbaptista/cto-toolkit)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-camilooscargbaptista-cto-toolkit-developer-experience
- Seller: https://agentstack.voostack.com/s/camilooscargbaptista
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.