debug-app
📋 Shared instructions: shared-instructions.md — read first.
Debug App — Monitor & Fix
Monitor the running app by reading the Metro dev-server terminal output, detect runtime and bundle errors, and fix them autonomously by editing the affected files (or routing to the right skill when the fix belongs in a domain like Dataverse schema or auth registration). For silent failures, inject temporary console.log statements at data-path boundaries, read the Metro terminal for output, then clean them up after the root cause is fixed. Modeled on the upstream app-debugger.agent.md pattern — foreground loop, 5-second cadence, exit on 3 consecutive clean polls.
Dev-client limitation: the standalone dev client outputs app/runtime logs, React errors, and Metro bundler output to the terminal running
npm run dev. This includes host runtime diagnostics that use strings such as[AuthProvider] MSAL init failed:,[bridge] fetch THREW for,[bridge] HTTP <status> for,[addAadAppToConnectionAcl] failed HTTP <status> for connection,[useConnectionRefs] could not verify connection ACLs; treating existing connections as setup-required, and[PAHost][ErrorBoundary] Unhandled JS error:. There is no separate device log stream. All diagnosis happens by reading that terminal and, where needed, injecting strategic trace statements into source files.
Subcommands (parsed from $ARGUMENTS)
| Form | Behavior |
|---|---|
/debug-app (no args) |
Default — terminal log-driven mode. Run Phase 0 (startup check), enter monitor loop. Log source is the Metro terminal (BashOutput on the $METRO_TERMINAL_ID recorded in memory-bank.md by /create-mobile-app Step 12). One read covers Metro bundler errors, app/runtime log lines (including host diagnostics), and red-box stack traces. If the terminal ID is not in memory-bank.md, ask the user which terminal is running npm run dev before starting. |
/debug-app "<symptom text>" |
Symptom-driven mode (recommended when there's a user-visible problem). Free-text symptom such as "todos not appearing on home screen", "login button does nothing", "list empty after refresh". Run Phase 0 → Phase 0.5 (parse symptom → ask the user to reproduce/navigate → walk the likely data path from terminal traces) → enter monitor loop. Catches silent failures (empty lists, blank screens, swallowed errors) that pure log polling misses. |
/debug-app status |
Print current state (last poll, fixes applied this session, unresolved errors). Do NOT enter loop. |
/debug-app stop |
If a loop is in progress, the user can type "stop" or this command to exit. State files preserved at .claude/debug-app/. |
Dispatch rule: if $ARGUMENTS is non-empty and is not one of the reserved subcommand tokens (status, stop, help, --help, -h, version, --version), treat the entire string (everything after the command name; outer quotes optional) as the symptom and use symptom-driven mode. For help / --help / -h, print the subcommands table above and exit.