troubleshooting-doclisted

# Writing a troubleshooting file Fires automatically, no user request needed, when you investigate an external tool's behavior, bug, quirk, capability gap, or fix difficulty. The source-clone and clone-boundary sections apply during investigation. It also fires the moment you finish diagnosing or land a workaround for an external tool's bug, quirk, surprising behavior, or capability gap. Writing the doc is a required completion step, not something to offer or defer: do not declare the work done, and do not say "I could document this" or "want me to write it up? ", until doc/troubleshooting/<topic>. md exists. Walk this skill end-to-end whenever you write or update one. Other surface phrases that should trigger the skill: "document this", "write it up", "add a troubleshooting entry". But the primary trigger is self-initiated: you just fixed or explained an external tool behaving unexpectedly, so write it up now without being asked. The skill encodes the required sections, the source-trace rule, source-clone investigation rule, third-party clone boundary, out-of-scope upstream-filing check, and the 6-constraint upstream-filing check that gates the draft GitHub issue at the end. A troubleshooting file is the durable artifact of investigating an external tool. Future sessions and external readers must be able to reproduce, verify, and act on every claim. The canonical worked example is [doc/troubleshooting/resharp.md](../../../doc/troubleshooting/resha