| name | mobile-crawler-triage |
| description | Use after a mobile-autocrawler crawl has produced a report.json, when the user wants the results triaged: failures prioritized by severity, grouped by root cause, with concrete fix suggestions, reproduction steps, and which bugs to tackle first. Trigger phrases: "triage the crawl report", "what should I fix first", "analyze these crashes", "prioritize the bugs from the crawl", "what did the crawler find and how do I fix it". Reads report.json (and screenshots) and produces a prioritized, actionable bug report. |
Mobile Crawl Triage
You turn a raw report.json from mobile-autocrawler into a prioritized,
fix-oriented bug report a developer can act on immediately.
Inputs
- A
report.json path (default ./mobile-crawler-report/report.json).
- Optionally the source repo of the app under test (to map failures to code).
Workflow
1. Load and digest
node scripts/triage-report.mjs ./mobile-crawler-report/report.json
This groups failures by severity and type, clusters likely-duplicate failures
(same trigger label / same screen / same error text), and prints replay commands.
Also read the report's accessibilityRecommendations and skippedActions.
2. Prioritize
Order work by impact using references/severity-rubric.md:
- Critical — crashes, can't-launch, blank screens after common actions. These
block users; fix first.
- High — broken login/signup, frozen screens, RN redboxes.
- Medium — visible errors, failed navigation, stuck loading.
- Low — navigation loops, unlabeled elements, skipped-unknown.
Within a tier, prefer failures at low depth (early in a flow → more users hit
them) and those that reproduced on replay.
3. Cluster by root cause
Multiple failures often share one bug. Merge failures that have the same
triggerActionLabel + stateName, or the same error text / log signature. Report
the cluster once with a count, not N near-duplicates.
4. Diagnose & suggest fixes
For each cluster, use references/fix-playbook.md to map symptom → likely cause →
concrete fix. If you have the app's source, grep for the trigger label / screen
name / error string to point at the probable file. Inspect the evidence
screenshots and logSnippet (e.g. a SIGSEGV or undefined is not an object
stack pins it down).
5. Verify before asserting
Don't claim a bug is real on the crawler's word alone — confirm it reproduces:
mobile-autocrawler replay --report ./mobile-crawler-report/report.json --failure failure_001
Mark each finding as confirmed (reproduced) or needs manual check.
6. Output
Produce a single prioritized markdown report:
- A one-line verdict (e.g. "2 critical, 1 high — ship-blocking").
- A ranked table: severity · title · screen · depth · reproduced? · replay cmd.
- Per critical/high finding: root-cause hypothesis, suggested fix, the exact repro
steps, and a pointer to the likely code if the repo is available.
- A short "tech debt" section from
accessibilityRecommendations (add testIDs).
- An honest coverage note (what wasn't reached, and why).
Don'ts
- Don't invent failures that aren't in the report.
- Don't suggest disabling the safety guard or tapping skipped destructive actions.
- Don't overstate confidence on failures that didn't reproduce.
References
references/severity-rubric.md — how to rank and what each severity means.references/fix-playbook.md — symptom → cause → fix for each detector type.
