菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | e2e-guide-analysis |
| description | 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. |
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 typeThe full QC8 comment-quality catalog — eight bad comment shapes to delete with before/after examples, plus the keep-list of comments that earn their place. Load before writing or editing code comments, or when a review flags comment quality. AGENTS.md carries the one-line rule and the shape titles; this skill carries the worked examples.
Per-PR documentation-drift prevention. When a PR adds new code subsystems, scripts, skills, docs, plugin routes, feature flags, or changes architecture relationships, this skill produces the AGENTS.md, CLAUDE.md, and .cursor/rules/ updates needed in the same PR so agent guidance never falls behind the code. Use this on /review or directly before merge.
Security audit — frontend (F1-F6 rules from `.cursor/rules/frontend-security.mdc`), Go backend (URL allowlists, token handling, hardcoded secrets, unbounded reads), MCP HTTP transport (size / wallclock / concurrency caps, Zod-validated tool inputs), and dependency audit (`npm audit` high+critical, Go module advisories). Reports findings with concrete remediation per rule. Never edits source — the user applies fixes.
Routed PR review orchestrator. Load for `/review` command or any PR review task.
Generate a structured PR description from the current diff using `docs/design/CONCERNS.md` routing. Interviews the author for motivation before drafting. Produces canonical sections (Summary, What to look at, Why, How to verify, Breaking changes, Reversibility) tailored to change type. Outputs the draft for human review; can apply via `gh pr edit` after explicit confirmation. Pair with `/review` — this skill drafts, `/review` reviews.
Locate technical debt in a subsystem or architectural component of a codebase. Use when the user runs `/techdebt <subsystem>` or asks to audit a module for smells, duplication, prop drilling, dead code, or other debt patterns. Examples: "/techdebt src/auth", "find tech debt in components/docs-panel", "audit the interactive-engine for smells".