Agent Experience
Audit the developer experience of a product, SDK, docs site, or SKILL.md by dropping...
Install
npx skills add browserbase/skills --skill agent-experience -g -a claude-code -y- Repository
- browserbase/skills3.7k
- Category
- Testing
- Updated
- 8d ago
- License
- MIT
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Audit the developer experience of a product, SDK, docs site, or SKILL.md by dropping multiple Claude subagents at it with only a tiny task prompt and real tools (WebFetch, Bash, Write). Agents must discover the docs themselves, install deps, ask for credentials if needed, and attempt real execution. The skill captures each agent's trace, tool calls, retries, wall time, errors, and scores on Setup Friction, Speed, Efficiency, Error Recovery, and Doc Quality, then emits an HTML report with an A, F grade and concrete fixes. Use when the user asks to audit agent experience, test a skill, audit docs for agents, check if a SDK is agent-friendly, validate a SKILL.md, measure agent DX, or benchmark how painful onboarding is for an AI agent. Triggers: 'audit agent experience', 'test this skill', 'audit docs for agents', 'is my SDK agent-friendly', 'run a DX audit', 'agent experience test', 'test my docs', 'how do agents do with my product'.
Audit Agent Experience
Evaluate how well a product/SDK/docs surface works when an AI agent actually tries to onboard and do a realistic task, starting from a short one-sentence prompt, with nothing pasted in. The agent must find the docs, install what it needs, and attempt real work. That's the only honest test of agent DX.
The skill spawns multiple subagents in parallel, captures each one's tool-call trace, and scores the experience using the same dimensions as the Skill Test Arena dashboard: Setup Friction, Speed, Efficiency, Error Recovery, Doc Quality.
Core principle
Do not spoonfeed. The subagent gets a tiny prompt like "Get started with {product} and {do its primary thing}". It must discover the docs, choose the path, and hit real failures. A good doc survives this; a bad doc does not.
Workflow
Execute these steps in order. Do not skip ahead.
Step 1, Identify the target and define the abstract goal
Resolve what the user is asking to audit. The target may arrive in one of three forms:
- URL, a docs site or product page (e.g.,
https://docs.example.com). This is the seed the subagents start from. - Repo / file path, for SKILL.md audits or SDK repos.
- Product name, if the user is vague ("test my product"), ask via
AskUserQuestionfor the URL or repo.
This skill is product-agnostic. Never assume what the user wants to audit. Do not infer a target from environment signals (operator's email domain, git remote, repo name, recent files, memory, CLAUDE.md). Even if context strongly suggests a particular company, the user-facing question must NOT pre-fill or default to any specific product, URL, or company name. Ask open-endedly with neutral options only: e.g., "Paste a URL", "Paste a local path", "Type a product name". If the user did not name a target in their invocation, ask them, start fresh, no priors.
