| name | cypress-analysis-requirements |
| description | Requirements-analysis skill for Cypress planning and implementation. Use when Codex needs to extract testable behaviors, acceptance criteria, risks, dependencies, or open questions from tickets, specs, markdown docs, or other requirement sources before writing tests or coverage plans. |
| metadata | {"author":"jovd83","version":"1.1","dispatcher-category":"testing","dispatcher-capabilities":"requirements-analysis, cypress-requirements-analysis","dispatcher-accepted-intents":"analyze_cypress_requirements, derive_cypress_testable_behaviors","dispatcher-input-artifacts":"requirements, ticket, spec, markdown_docs, repo_context","dispatcher-output-artifacts":"analysis_baseline, requirement_summary, open_questions, routing_request","dispatcher-stack-tags":"cypress, analysis, ui-testing","dispatcher-risk":"low","dispatcher-writes-files":false} |
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.sh on Linux)
Analysis & Requirements Skill
Use this skill to turn raw product or engineering artifacts into a trustworthy testing baseline for Cypress work.
1. Information Gathering
Use the best available sources in this order:
- user-provided tickets, specs, exports, or links,
- repository-local docs such as
docs/, markdown files, issue exports, or feature notes,
- nearby automation or product artifacts that clarify behavior.
Do not keep searching indefinitely once you have enough evidence to form a reliable baseline.
2. Requirement Extraction
Produce a concise requirements baseline that separates:
- confirmed behaviors,
- inferred behaviors,
- risks and edge cases,
- open questions or missing evidence,
- source evidence.
When tabular output helps, use:
| Requirement ID | Behavior | Evidence | Confidence | Notes |
|---|
Normalize vague prose into testable behaviors. Capture authorization rules, data constraints, negative paths, and dependencies when the source implies them.
3. User Validation
Pause for confirmation when ambiguity would materially change the downstream plan, implementation, or documentation.
Use a direct validation prompt such as:
"Here is the requirements baseline I derived for the Cypress work. Please confirm the confirmed behaviors, call out any missing evidence, and tell me what should stay assumption-only before I plan or implement."
If the user asked only for the baseline, stop after this step.
If the requirements are clear enough and the same request also asks for downstream planning, continue while keeping assumptions explicit and auditable.
4. Handoff
Use dispatcher intent plan_cypress_coverage when the next step is coverage planning.
If dispatcher routing is unavailable, hand off to cypress-coverage-plan-generation.
