.cursor/skills/e2e-guide-analysis/SKILL.md
Run E2E CLI against a JSON guide to analyze edge cases and behavior. Use when the user wants to test a guide with the e2e CLI for learning purposes, study e2e failures, analyze screenshots, or investigate edge cases in the guide runner.
npx skillsauth add grafana/grafana-pathfinder-app e2e-guide-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill runs the E2E CLI against a provided JSON guide with maximum diagnostic output, then analyzes results to identify edge cases and learnings. The goal is exploratory testing to inform e2e CLI design and guide specification improvements.
Before running, ensure:
npm run server (or verify at http://localhost:3000)npm run dev or npm run buildnpx pathfinder-cli e2e <GUIDE_PATH> \
--verbose \
--always-screenshot \
--trace \
--artifacts ./cursor/local/e2e/artifacts/<guide-name> \
--output ./cursor/local/e2e/artifacts/<guide-name>/report.json
Replace <GUIDE_PATH> with the user-provided path. Extract <guide-name> from the filename (or the title inside of the JSON if the guide-name is just 'content') and don't include .json in the name.
After the CLI completes (pass or fail), collect:
report.json from the artifacts directory.png files in the artifacts directorytrace.zip if tracing was enabled (in test-results/)*-dom.html files for selector debuggingFor each step in the guide, examine:
| Aspect | What to look for | | ---------------- | ---------------------------------------------------------------------- | | Status | passed, failed, skipped, not_reached | | Skip reason | pre_completed, no_do_it_button, requirements_not_met, skippable_failed | | Requirements | Were requirements met? Did fix buttons work? | | Timing | How long did each step take? Timeouts? | | Screenshots | Visual anomalies, unexpected UI state |
Categorize findings into:
Create or update: tests/e2e-runner/learning/<guide-name>.md
Use this template:
# E2E Analysis: <Guide Title>
**Guide**: `<path-to-guide>`
**Date**: <ISO date>
**CLI version**: (from package.json)
## Summary
<1-2 sentence overview of what was tested and overall outcome>
## Test Results
| Metric | Value |
| ----------- | ----- |
| Total steps | N |
| Passed | N |
| Failed | N |
| Skipped | N |
| Not reached | N |
| Duration | Xms |
## Observations
### [Issue Category]
**Finding**: <description>
**Evidence**: <screenshot reference, log excerpt, or JSON snippet>
**Impact**: <how this affects guide execution>
**Recommendation**: <suggested fix or investigation>
(repeat for each significant finding)
## Edge Cases Discovered
- <edge case 1>
- <edge case 2>
## Recommendations
### For guide authors
- <actionable guidance>
### For E2E CLI development
- <suggested improvements>
## Artifacts
- Screenshots: `artifacts/<guide-name>/`
- JSON report: `artifacts/<guide-name>/report.json`
- Trace: `test-results/.../trace.zip` (if enabled)
For deeper context, read these files:
docs/design/TESTING_STRATEGY.md - Overall testing philosophy and failure classificationdocs/design/e2e-test-runner-design.md - CLI architecture and step execution logic| Code | Meaning | | ---- | ------------------------- | | 0 | All steps passed | | 1 | One or more steps failed | | 2 | Configuration/setup error | | 3 | Grafana unreachable | | 4 | Auth failure |
doIt: false or are noop typedevelopment
Run typecheck, lint, and tests for both frontend and Go backend to tidy and test the code prior to committing and pushing.
tools
Optimise Grafana app plugin bundle size using React.lazy, Suspense, and webpack code splitting. Use when the user asks to reduce plugin bundle size, optimise module.js, add code splitting, improve initial plugin load performance, split plugin chunks, lazy load plugin pages, or help implement lazy loading in a Grafana app plugin. Triggers on phrases like "optimise plugin bundle size", "module.js is too large", "plugin is slow to load", "code split the plugin", "reduce initial JS payload", or "help me with Suspense in my plugin".
development
Periodic documentation maintenance audit. Finds orphaned docs, detects drift between .cursor/rules/ and docs/developer/, validates doc correctness against source code, tracks structural issues in a persistent backlog, and opens PRs to close highest-priority gaps per run. Use when the user asks to audit documentation, sync docs, or maintain the knowledge base.
development
Principal engineer level architecture design review and critique. Use when the user asks for design review, architecture feedback, design partnership, risk analysis of a design doc, or wants to drive ambiguity out of a plan. Never writes code; operates as a conversational design partner.