DevEx Review
Use this skill to test the implemented developer experience from the perspective of a new developer. This is a live audit, not a plan review.
Core Rule
Measure actual friction. Prefer running the quickstart, CLI help, examples, API requests, docs navigation, and error paths over judging intent from prose.
Scope
Use this for developer-facing products:
- API onboarding and reference docs.
- CLI install, help text, commands, flags, and errors.
- SDK install/import/example flows.
- MCP servers, plugins, agent skills, templates, or integration guides.
- "Try the onboarding", "test the DX", "measure time to hello world", or "audit developer docs" requests.
Do not use this for end-user web UX, landing-page copy alone, or implementation-plan review before anything exists. Use plan-devex-review for plan-stage API/CLI/docs design.
Workflow
Define the developer persona.
- First-time evaluator, integrating engineer, internal maintainer, API customer, plugin author, or open-source contributor.
Measure TTHW.
- TTHW means time to a credible first successful result.
- Count steps, commands, accounts, tokens, config files, and decision points.
- Note where a real developer would abandon.
Test the core path.
- Install or setup.
- Authentication or configuration.
- Minimal example.
- First useful output.
- Next likely task after success.
Test failure paths.
- Missing credential.
- Invalid input.
- Network/provider failure.
- Permission error.
- Version mismatch.
- Rate limit or quota issue if relevant.
Score the experience.
- TTHW.
- Setup clarity.
- Error quality.
- Example correctness.
- API/CLI surface coherence.
- Troubleshooting path.
- Trust and production readiness.
Scorecard
| Dimension |
Score |
Evidence |
| Time to hello world |
0-10 |
|
| Setup clarity |
0-10 |
|
| Error quality |
0-10 |
|
| Examples and docs |
0-10 |
|
| API/CLI coherence |
0-10 |
|
| Troubleshooting |
0-10 |
|
| Production trust |
0-10 |
|
Report Contract
## Developer Experience Review
### Target
Product:
Surface: API / CLI / SDK / docs / MCP / plugin / template
Persona:
### Summary
Overall score: __/10
TTHW measured:
Status: Ready / Usable with friction / Not ready
### Journey Tested
- <journey>
### Findings
#### DX-001: <title>
Severity:
Evidence:
Developer impact:
Recommended fix:
### Scorecard
<table>
### Not Tested
- <area>
### Recommended Next Step
- <next step>
Quality Bar
- Distinguish tested behavior from inferred judgment.
- Include exact commands, URLs, docs pages, or error text when available.
- Do not optimize for aesthetic docs alone; measure whether a developer can succeed.
- Call out boomerang gaps: where the intended plan says "easy" but the actual path is longer or unclear.
1---2name: devex-review-23description: Use when auditing a live or implemented developer experience for APIs, CLIs, SDKs, MCP servers, plugins, integration guides, getting-started docs, or developer onboarding flows.4---56# DevEx Review78Use this skill to test the implemented developer experience from the perspective of a new developer. This is a live audit, not a plan review.910## Core Rule1112Measure actual friction. Prefer running the quickstart, CLI help, examples, API requests, docs navigation, and error paths over judging intent from prose.1314## Scope1516Use this for developer-facing products:1718- API onboarding and reference docs.19- CLI install, help text, commands, flags, and errors.20- SDK install/import/example flows.21- MCP servers, plugins, agent skills, templates, or integration guides.22- "Try the onboarding", "test the DX", "measure time to hello world", or "audit developer docs" requests.2324Do not use this for end-user web UX, landing-page copy alone, or implementation-plan review before anything exists. Use `plan-devex-review` for plan-stage API/CLI/docs design.2526## Workflow27281. Define the developer persona.29 - First-time evaluator, integrating engineer, internal maintainer, API customer, plugin author, or open-source contributor.30312. Measure TTHW.32 - TTHW means time to a credible first successful result.33 - Count steps, commands, accounts, tokens, config files, and decision points.34 - Note where a real developer would abandon.35363. Test the core path.37 - Install or setup.38 - Authentication or configuration.39 - Minimal example.40 - First useful output.41 - Next likely task after success.42434. Test failure paths.44 - Missing credential.45 - Invalid input.46 - Network/provider failure.47 - Permission error.48 - Version mismatch.49 - Rate limit or quota issue if relevant.50515. Score the experience.52 - TTHW.53 - Setup clarity.54 - Error quality.55 - Example correctness.56 - API/CLI surface coherence.57 - Troubleshooting path.58 - Trust and production readiness.5960## Scorecard6162| Dimension | Score | Evidence |63|---|---:|---|64| Time to hello world | 0-10 | |65| Setup clarity | 0-10 | |66| Error quality | 0-10 | |67| Examples and docs | 0-10 | |68| API/CLI coherence | 0-10 | |69| Troubleshooting | 0-10 | |70| Production trust | 0-10 | |7172## Report Contract7374```markdown75## Developer Experience Review7677### Target78Product:79Surface: API / CLI / SDK / docs / MCP / plugin / template80Persona:8182### Summary83Overall score: __/1084TTHW measured:85Status: Ready / Usable with friction / Not ready8687### Journey Tested88- <journey>8990### Findings9192#### DX-001: <title>93Severity:94Evidence:95Developer impact:96Recommended fix:9798### Scorecard99<table>100101### Not Tested102- <area>103104### Recommended Next Step105- <next step>106```107108## Quality Bar109110- Distinguish tested behavior from inferred judgment.111- Include exact commands, URLs, docs pages, or error text when available.112- Do not optimize for aesthetic docs alone; measure whether a developer can succeed.113- Call out boomerang gaps: where the intended plan says "easy" but the actual path is longer or unclear.
cogine-ai