Hire an AI developer experience reviewer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A ranked friction report with where, what goes wrong, a fix, effort and impact for each item
• Rewritten error messages that say what happened, why and what to do next
• Notes on sample code and method names that hide the correct use
• A first 30 minutes path for a new developer, with the shortest route to a real result
• A plan to measure the change, with what to record before you start
• A way to sort support tickets into feedback for the right team

How it does the job well

• Say clearly that you read the material and did not watch developers or run the product. If you cannot run the code, say so, and do not claim a sample works.
• No sample that requires an account before showing value. If the first code a developer runs needs sign-up, authentication, and API key configuration before returning anything interesting — that's a DX failure. Find the shortest path to a real result.
• Treat error messages as product copy. Every error message is a conversation with a frustrated developer. Write it like one.
• Don't optimize the happy path at the expense of the failure path. The developer who hits an error needs more help than the one who doesn't.
• Never ship a friction report without a proposed fix. Identifying that something is broken is the minimum. Pair every observation with a concrete, implementable recommendation.
• Start from the user problem and the evidence for it, then the solution.
• Write decisions down with the reason and the options you rejected.

Mistakes it avoids

• Treating opinions or one loud request as proven demand.
• Specs that skip edge cases, error states or dependencies.
• Roadmaps with dates but no owners or confidence levels.

What a good result looks like

An example, not your task: New developers sign up for your API or SDK and few of them make a first working call.

• First 30 minutes path. Each step from first visit to a working call, marking steps that need setup before any result.
• Friction report. Ranked problems, each with where it happens, a fix, the effort and the expected effect.
• Error message rewrites. Each weak error rewritten to say what happened, why and what to do next.
• Sample code and method notes. Where the correct way to use a method is unclear, and how to make it obvious.
• Feedback sorting. Support ticket themes sorted to the team that can fix each one.
• Measuring plan. The numbers to record before and after, and how to record them.

How the work is checked

• Every requirement can be tested.
• Assumptions and risks are listed with how each will be checked.
• Dependencies and owners are named.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

A second opinion

Before it hands back, your AI reviews the draft the way Clayton Christensen and Jakob Nielsen would. This is a way of reviewing the work. It does not mean they wrote or endorse it.

Capabilities

• Map the path. It lists every step from first visit to a working call, and marks steps that need sign-up, keys or setup before any result shows.
• Find the friction. It looks for confusing auth steps, examples that do more than they say, and gaps between docs and code. It rates each by how bad and how often.
• Rewrite the errors. It turns each weak error into what happened, why, and what to do next, with a link to the fix when you give one.
• Review the samples. It checks that the correct way to use each method is obvious, and that examples cover real use and the failure case, not just a hello world.
• Propose a fix for each item. Every problem gets a fix that can be built, with the effort and the expected effect.
• Plan the measuring. It names the numbers to take before and after, and how to sort support tickets so the right team sees them.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id product-dx-engineer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/product-dx-engineer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• Your getting-started guide or onboarding steps, pasted or linked
• Your sample code and SDK method names or signatures
• The error messages new developers see most, with the status codes
• Support tickets, forum posts or GitHub issues from new developers (optional)
• Numbers you track now, such as time to first call (optional)

Helpful context (optional)

• A recording or notes from someone new trying your guide.
• Your analytics for each sign-up step.
• The questions your support team answers most.

Tools and access

• Claude, ChatGPT or Gemini with file upload: You can attach the docs export and the SDK source so it checks docs against real code.
• Claude Code or another AI that can read your repo: It can read the SDK and test the sample code instead of relying on pasted snippets.

Functions and deliverables

• Developer experience reviewer: Get a developer onboarding friction report. See the steps where new developers get stuck, rewritten error messages and fixes ranked by effort.
  • A ranked friction report with where, what goes wrong, a fix, effort and impact for each item
  • Rewritten error messages that say what happened, why and what to do next
  • Notes on sample code and method names that hide the correct use
  • A first 30 minutes path for a new developer, with the shortest route to a real result
  • A plan to measure the change, with what to record before you start
  • A way to sort support tickets into feedback for the right team
  Source: Michael Sitarzewski and Agency Agents contributors.
• New customer experience reviewer: Find where buyers stall before first use. Paste your returns, tickets and reviews to get ranked gaps, a fix for each and a score out of 100.
  • A first-use timeline from delivery to repeat use, with drop-off points marked
  • Ranked gaps, each with evidence quotes, the barrier type and one fix
  • A first-use score out of 100, with what it measures and the sum shown
  • Three measures to track in your own store, in place of "shipped" and "sold"
• Error message rewriter: Paste your error messages. Get each one rewritten in plain words, with what went wrong and what to do next, costliest first.
  • Each message rewritten in plain words
  • What went wrong in one sentence and the next step
  • Where the error could be prevented before it shows
  • The messages ranked by the cost of the mistake
• Gorgias weekly support reporter: Review a week of Gorgias tickets. Get ticket counts, recurring problems, notable cases and proposed fixes, with an optional approved Slack post.
  • Counts of new, resolved and open tickets for the week.
  • Average first response and resolution times, plus CSAT if your data has it.
  • The top issue groups with ticket counts.
  • Three notable tickets: the biggest fire, the longest open, and the best resolution.
  • Trends and recommended fixes you can act on.
  • A Slack post of the report, only after you approve it.
  Source: Composio.
• Product context file writer: Share product facts, audience and positioning. Get a reviewed context file that other marketing skills can reference.
  • A product marketing context file
  • A summary of what the file already holds
  • A change log of updates
  • Gaps you still need to fill
  Source: Corey Haines.
• Clayton Christensen: Explore why customers buy using Clayton Christensen’s recorded approach. Start with a real situation, the struggle and what the buyer used before.
  • Your problem worked on the way Clayton Christensen would: their questions, their method, their push-back
  • The answer or the work, in Clayton Christensen's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step
• Jakob Nielsen: Review a website, app or form through Jakob Nielsen’s recorded approach. Find likely usability problems and plan small rounds of realistic user tasks.
  • Your problem worked on the way Jakob Nielsen would: their questions, their method, their push-back
  • The answer or the work, in Jakob Nielsen's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step

Tasks you can use it for

• New developers sign up for your API or SDK and few of them make a first working call.
• Your support inbox is full of the same setup questions.
• Your error messages say "invalid input" or "401" and nothing else.
• You are about to launch a new SDK or docs site and want a fresh read first.

Limits to check before starting

• You have no docs, SDK or API yet. Use the Product requirements writer first to plan it.
• You only want a few error messages rewritten. Use the Error message rewriter.
• You want a plan to cut the time to a first API call from a sign-up path. Use the API first-call experience reviewer.
• You want a guide for new teammates joining a codebase. Use the Codebase onboarding guide writer.
• You want proof from real developers. Watch five or more people try the guide and take notes. This agent reads, it does not observe.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack from this page and add it to your AI as a skill. Or paste SKILL.md into a new chat, then paste references/source-agent.md after it.
• Paste your getting-started guide, a few code samples and your most common error messages. Add support tickets if you have them.
• Your AI asks once for anything missing. Anything still unknown is marked as an assumption you can change.
• Read the top friction items first. Check each against the real product, since the AI has only seen what you pasted.
• Ship the error message rewrites and the small doc fixes first. Test each one yourself in a fresh account or a clean machine.
• Record the baseline numbers before you change anything, then watch new developers or your analytics to see if the fixes help.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/product-dx-engineer for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.