Orchestrator
End-to-end Playwright skill pack for planning, authoring, debugging, documenting, and operationalizing test automation.
npx -y skills add jovd83/playwright-skill --skill orchestratorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Central entrypoint for broad or ambiguous Playwright requests. Use when Codex needs to classify the user's testing goal, choose the right Playwright subskill, and move from intent to implementation, planning, documentation, execution, or reporting without unnecessary menu-driven back-and-forth.
SKILL.md
4.2 KB, as published. Nobody here has run it
Playwright Orchestrator
Use this skill when the user asks for Playwright help but the exact workflow is not yet obvious. Its job is to classify the task, route to the right subskill, and keep the work moving.
Routing Principles
- Infer the task type when the user already gave enough context.
- Ask a clarifying question only when the answer would materially change the artifact, scope, or next tool.
- Do not stop for a menu when the user already asked for a concrete deliverable.
- Prefer the smallest capable subskill instead of loading the whole pack.
Route by Intent
| If the user wants to... | Route to... |
|---|---|
| write, fix, or review Playwright tests | ../core/SKILL.md |
| choose between fixtures, POMs, and helpers | ../pom/SKILL.md |
| set up or debug CI execution | ../ci/SKILL.md |
| migrate from Cypress or Selenium | ../migration/SKILL.md |
| drive a browser from the terminal | ../playwright-cli/SKILL.md |
| derive requirements from tickets or specs | ../analysis/SKILL.md |
| produce or refine a coverage plan | ../coverage_plan/generation/SKILL.md and ../coverage_plan/review/SKILL.md |
| write test documentation or convert case formats | dispatch render_test_artifact through skill-dispatcher, or fall back to C:\projects\skills\test-artifact-export-skill\SKILL.md |
| investigate failures | ../documentation/root_cause/SKILL.md |
| create handoff or resume-state artifacts | ../documentation/handover/SKILL.md and ../documentation/session-state/SKILL.md |
| export test cases to external test-management systems | dispatch render_test_artifact through skill-dispatcher, or fall back to C:\projects\skills\test-artifact-export-skill\SKILL.md |
| report execution to external test-management systems | the relevant ../mappers/, or ../reporters/ subskill |
Execution Contract
After routing, do the work. Do not just announce the destination skill.
When helpful, state:
- the inferred task type,
- the subskill you are using,
- any high-impact assumption,
- the artifact you are about to produce.
Shared Guardrails
- Prefer web-first assertions and resilient, user-facing locators.
- Do not write placeholder tests or claim implementation is complete when it is blocked.
- Keep setup and state in fixtures, UI behavior in page objects when repetition or complexity justifies them, and helpers stateless.
- Mock third-party dependencies selectively; do not mock away the system under test by default.
- Keep planning and documentation traceable to requirements and executable automation when those artifacts exist.
Escalation Rules
- If the task is underspecified but low risk, make a reasonable assumption and state it.
- If the task affects scope, cost, or long-lived structure, pause and get the missing decision.
- If multiple subskills are required, use them in sequence and keep the handoff between them explicit.
- Treat direct sibling-skill paths as a compatibility fallback when dispatcher routing is unavailable.