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.

Operating contract

Shared by every DecisionNerd/dev-skills skill. Canonical copy: handbook/concepts/14-operating-contract.md.