Troubleshoot App

Use this skill to diagnose live app problems from the outside in: reproduce the user-visible issue, correlate it with data-plane truth, inspect logs and code, then recommend a fix. Keep it globally usable; discover the project’s actual sources instead of assuming a stack.

This is quality regime B (interactive product). Wrong outputs from APIs/pipelines with no UI → diagnose-bug (A). Thrashing agents / bad LLM generations → agents analyze / Langfuse traces (C), not this skill.

Use lightweight BDD completion scenarios and existing requirements as the definition of what should be happening (handbook/concepts/13-quality-trace.md). Look in DocSlime docs/ (PRODUCT.md, experience/, REQUIREMENTS.md, engineering/TESTING.md, …), issue bodies, PR descriptions, existing .feature/tests, and acceptance criteria. Prefer refining an existing definition over inventing a parallel one. If none fits, draft a concise Given/When/Then scenario and say where it should live. A broken, confusing, or falsely promised experience is still a bug — including craft/a11y/framing debt (handbook/concepts/12-bugs-and-debt.md).

For backend-only, API, worker, data-pipeline, or algorithm failures (no meaningful browser UI), use diagnose-bug instead.

Core Rule

Do not jump straight from screenshot to code. Establish what the user sees, what the app believes, and what durable data says. Treat analytics as evidence, not authority.

Before making code, config, or data changes, end the diagnosis with:

Do you want me to implement this fix?

The user can answer yes/no. If the user already explicitly says to implement or fix in the same request, proceed after a concise diagnosis.