What problem does it solve? When an application segfaults, aborts, or disappears with a "Process crashed" notification, it is hard to tell what actually happened, whose bug it is, and whether user data was lost. This Skill provides an evidence-based workflow for diagnosing crashes from systemd-coredump core dumps on a Fedora Asahi (aarch64) machine. ## Core Features & Use Cases - Evidence gathering: Reads backtraces and command lines via coredumpctl, correlates crash timestamps against filesystem mtimes, journal entries, and recent dnf package updates, and rules out OOM kills from systemd-oomd first. - Symbolization: Uses Fedora's debuginfod server with gdb to resolve stack frames, handles aarch64-specific concerns, and treats core dumps as sensitive memory copies that must be written to mktemp paths and deleted afterward. - Attribution and reporting: Separates proven facts from inference, distinguishes dotfiles bugs from upstream project bugs and Asahi kernel/mesa issues, and defines strict conditions for filing upstream issues with gh (verified bug, explicit user consent, authenticated CLI, duplicate search first). - Use Case: A user asks "why does my file manager keep crashing?" The Skill checks coredumpctl list for a pattern, correlates the crash time with a recent package update, symbolizes the stack via debuginfod, and reports the likely mechanism plus whether it is a dotfiles or upstream bug. ## Quick Start Ask the assistant to diagnose why a specific program crashed using the most recent core dump from coredumpctl.
