How do I install the UX Acceptance Coordinator skill?

Run npx skillmds@latest add emdash-cms/ux-acceptance-coordinator in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is UX Acceptance Coordinator safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with UX Acceptance Coordinator?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is UX Acceptance Coordinator free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published UX Acceptance Coordinator?

emdash-cms (@emdash-cms) published this skill. Their other Agent Skills are listed on their SkillMD profile.

UX Acceptance Coordinator by emdash-cms

Name: UX Acceptance Coordinator
Author: emdash-cms

UX Acceptance Coordinator

Coordinate black-box, agent-driven UX acceptance journeys against a disposable EmDash admin site. Use when preparing, dispatching, verifying, or reporting a manual browser journey performed by a separate tester agent. Do not use for deterministic Playwright tests or ordinary code review.

emdash-cms 23d6262 3.2 KB Updated Sep 17, 2026

File contents

Coordinate UX acceptance testing

Run a goal-driven browser journey with a tester that has no repository context. Keep site preparation, private success checks, and product diagnosis in the coordinator context.

Prepare the run

Read the selected journey in acceptance/journeys/.
Check the journey's status and requires frontmatter. If its status is needs-profile, report the missing bootstrap requirements and stop. Do not substitute a simpler profile or relax the journey.
Read its site profile in acceptance/sites/ and the portable tester instructions in acceptance/tester/SKILL.md.
Choose the journey's target. Use Node unless the journey or change under test requires the Cloudflare runtime.

Start one disposable site:

pnpm ux:site:start -- --target node --profile editorial-small

Keep the run ID, start URL, and run-data path from the command output. Never send the run-data file or API token to the tester.

Isolate the tester

Create the tester outside the repository checkout. Give it only:

the contents of acceptance/tester/SKILL.md;
the journey's Tester brief section;
the generated start URL;
a writable location for its report and screenshots.

Do not give the tester AGENTS.md, repository skills, source files, route names, the coordinator checks, or implementation context. Do not describe a clean context as isolated when the selected agent mechanism still exposes the checkout. If the environment cannot create a separate context within the user's authorization, prepare the handoff and ask the user to launch it.

Use any agent implementation that provides browser control. Do not translate the brief into tool-specific click instructions.

Verify and report

Wait for the tester to finish or explicitly give up. Preserve its action log, screenshots, and report without rewriting its observations.

Run the journey's Coordinator checks independently. Prefer a read-only public API with the local token in the run-data file; use direct database inspection only when the public surface cannot establish the result. The tester's claim is not proof of completion.

Classify the run as one of:

PASS: the checks passed and the tester found no material friction.
PASS_WITH_FRICTION: the checks passed and the tester found a concrete UX issue.
FAIL_PRODUCT: the site remained usable, but the journey goal was not achieved.
FAIL_INFRASTRUCTURE: bootstrap, browser control, or the local server prevented a meaningful attempt.
INCONCLUSIVE: the available evidence cannot distinguish product and test failures.

Report the functional result separately from UX findings. Include the path taken, failed or confusing actions, evidence, and independent check results.

Stop the exact run after collecting evidence, even when the journey fails:

pnpm ux:site:stop -- <run-id>

Keep the site running only when the user asks to inspect it further.

---name: ux-acceptance-coordinatordescription: Coordinate black-box, agent-driven UX acceptance journeys against a disposable EmDash admin site. Use when preparing, dispatching, verifying, or reporting a manual browser journey performed by a separate tester agent. Do not use for deterministic Playwright tests or ordinary code review.---# Coordinate UX acceptance testingRun a goal-driven browser journey with a tester that has no repository context. Keep site preparation, private success checks, and product diagnosis in the coordinator context.## Prepare the run1. Read the selected journey in `acceptance/journeys/`.2. Check the journey's `status` and `requires` frontmatter. If its status is `needs-profile`, report the missing bootstrap requirements and stop. Do not substitute a simpler profile or relax the journey.3. Read its site profile in `acceptance/sites/` and the portable tester instructions in `acceptance/tester/SKILL.md`.4. Choose the journey's target. Use Node unless the journey or change under test requires the Cloudflare runtime.5. Start one disposable site: ```console pnpm ux:site:start -- --target node --profile editorial-small ```6. Keep the run ID, start URL, and run-data path from the command output. Never send the run-data file or API token to the tester.## Isolate the testerCreate the tester outside the repository checkout. Give it only:- the contents of `acceptance/tester/SKILL.md`;- the journey's `Tester brief` section;- the generated start URL;- a writable location for its report and screenshots.Do not give the tester `AGENTS.md`, repository skills, source files, route names, the coordinator checks, or implementation context. Do not describe a clean context as isolated when the selected agent mechanism still exposes the checkout. If the environment cannot create a separate context within the user's authorization, prepare the handoff and ask the user to launch it.Use any agent implementation that provides browser control. Do not translate the brief into tool-specific click instructions.## Verify and reportWait for the tester to finish or explicitly give up. Preserve its action log, screenshots, and report without rewriting its observations.Run the journey's `Coordinator checks` independently. Prefer a read-only public API with the local token in the run-data file; use direct database inspection only when the public surface cannot establish the result. The tester's claim is not proof of completion.Classify the run as one of:- `PASS`: the checks passed and the tester found no material friction.- `PASS_WITH_FRICTION`: the checks passed and the tester found a concrete UX issue.- `FAIL_PRODUCT`: the site remained usable, but the journey goal was not achieved.- `FAIL_INFRASTRUCTURE`: bootstrap, browser control, or the local server prevented a meaningful attempt.- `INCONCLUSIVE`: the available evidence cannot distinguish product and test failures.Report the functional result separately from UX findings. Include the path taken, failed or confusing actions, evidence, and independent check results.Stop the exact run after collecting evidence, even when the journey fails:```consolepnpm ux:site:stop -- <run-id>```Keep the site running only when the user asks to inspect it further.

Frequently asked questions