Orchestrator
End-to-end Cypress skill pack for planning, authoring, debugging, documenting, and operationalizing test automation.
npx -y skills add jovd83/Cypress-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
- 0 stars0 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 Cypress requests. Use when Codex needs to classify the user's testing goal, choose the right Cypress subskill, and move from intent to implementation, planning, documentation, execution, or reporting without unnecessary menu-driven back-and-forth.
SKILL.md
4.4 KB, as published. Nobody here has run it
Telemetry & Logging
[!IMPORTANT] All usage of this skill must be logged via the Skill Dispatcher to ensure audit logs and wallboard analytics are accurate:
./log-dispatch.cmd --skill <skill_name> --intent <intent> --model <model_name> --reason <reason>(or./log-dispatch.shon Linux)
Cypress Orchestrator
Use this skill when the user asks for Cypress 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.
Deterministic First Question
If the user already gave enough context, do not ask this question. Route immediately.
If intent is still ambiguous and the answer would materially change the artifact or next step, ask exactly one routing question:
"What do you want to do right now with Cypress: write or fix tests, debug a failing run, plan coverage from requirements, document tests, work with a test-management tool, summarize results, or handle setup and migration?"
Do not ask a menu question after the user already requested a concrete deliverable.
Intent Routing Table
| User intent | Route | Follow-up only if needed |
|---|---|---|
| Write, fix, or review Cypress tests | core | Clarify scope only if it changes what gets built |
| Decide between POMs, fixtures, helpers, or commands | pom | Ask only if the current architecture is unclear |
| Run or debug a failing suite | core and documentation/root_cause | Request failure output if it is missing |
| Set up or debug CI execution | ci | Ask which CI provider only when examples differ materially |
| Derive requirements from tickets or specs | analysis | Ask for the strongest available source if none was provided |
| Produce or refine a coverage plan | coverage_plan/generation and coverage_plan/review | Clarify approval needs only for large or costly plans |
| Write test documentation or convert case formats | Dispatch render_test_artifact through skill-dispatcher or use documentation/tests | Ask for the desired format only if it is not inferable |
| Create handoff or session-state artifacts | documentation/cypress-handover or documentation/session-state | Confirm task scope only when multiple scopes exist |
| Export test cases to TestLink, TestRail, Xray, or Zephyr | Dispatch render_test_artifact through skill-dispatcher | Ask for the target system if not stated |
| Report execution to TestLink, TestRail, Xray, or Zephyr | relevant mappers/* or reporters/* | Ask for the target system if not stated |
| Summarize Cypress results for stakeholders | reporting/stakeholder | Ask for release context if the report would otherwise be misleading |
| Migrate from another framework or Selenium/WebDriver | migration | Ask for source stack if missing |
| Drive a browser from the terminal | cypress-cli | Ask whether the need is interaction, scraping, mocking, or diagnostics only if it changes the workflow |
| Install or align IDE workflows | installers/* | Ask for IDE only if it is not already clear |
Orchestration Rules
- Prefer the smallest capable subskill instead of loading the whole pack.
- After routing, do the work. Do not just announce the destination skill.
- State high-impact assumptions when you make them.
- Keep planning, documentation, and implementation handoffs explicit when multiple subskills are used in sequence.
- Escalate only when the missing decision materially changes scope, cost, risk, or long-lived structure.
- Treat direct sibling-skill paths as a compatibility fallback when dispatcher routing is unavailable.