{"id":20638,"plugin_id":"plugins_6aa6c75c405c819192333b0725d82361","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:16:24.195Z","digest":"ab095de4715213366dafa17086c523a6d7a74a70c37125d5a5c7a6241b5329bc","against":null,"payload":{"description":"Vendor-neutral evidence-first investigation of technical customer and product issues.","included_files":[],"name":"product-support-investigator","skill_md_contents":"---\nname: product-support-investigator\ndescription: Vendor-neutral evidence-first investigation of technical customer and product issues.\n---\n\n# Product Support Investigator Community\n\nFollow the repository root `SKILL.md`, which is the canonical methodology for all agent implementations. Use available evidence from tickets, telemetry, code, deployments, infrastructure, and customer reports; integrations are optional.\n\nPreserve these non-negotiable rules:\n\n- Separate **Observed**, **Inferred**, and **Unknown**.\n- Never invent evidence or present assumptions as facts.\n- Rank hypotheses and show evidence for, against, missing, and qualitative confidence (High, Medium, or Low).\n- Decide whether the available evidence supports immediate investigation or requires minimal clarification; do not ask for information that tools can discover.\n- Check recent changes, similar incidents, business impact, blast radius, risk, ownership, and next discriminating checks.\n- Trace beyond an exception toward the deepest evidence-supported underlying cause.\n- Treat negative evidence carefully: absence is meaningful only when the signal was expected and the source is complete enough.\n- Treat successful related operations as control evidence and compare successful versus failing paths before blaming a shared dependency.\n- Prefer differential investigation: isolate what exists only in the failing path before broad generic troubleshooting.\n- Re-rank hypotheses when new or contradictory evidence appears; do not preserve the first leading hypothesis by default.\n- Do not infer severity from the technical error alone; severity must follow demonstrated customer/business impact and failure scope.\n- Distinguish customer/product, platform, integration, deployment, developer-tooling, local-environment, and observability failures.\n- Treat pre-signed URLs, temporary tokens, and signed query strings as sensitive; do not expose or probe them with arbitrary HTTP methods.\n- Missing logs or connectors do not prevent investigation; degrade gracefully using the evidence available.\n- Keep investigation read-only by default and customer communication safe.\n\nAdapt output depth to complexity and requested mode. Do not include empty sections. For Standard and Deep investigations, use relevant headings from this canonical full structure:\n\n1. Executive Summary\n2. Goal and Failure Stage\n3. Issue Validation Status\n4. Incident Classification\n5. Business Impact\n6. Technical Signals\n7. Timeline / Last Known Success / Onset\n8. Observed Facts\n9. AI Inferences\n10. Unknowns\n11. Evidence\n12. Correlations\n13. Layer / Sequence Validation\n14. Successful Control Paths / Differential Signals\n15. Blast Radius\n16. Similar Incidents / Known Issues\n17. Recent Changes / Version Compatibility\n18. Hypotheses\n19. Root Cause Assessment\n20. Risk Assessment\n21. Investigation Checklist / Next Useful Check\n22. Missing Evidence\n23. Suggested Command or Search\n24. Workaround\n25. Customer Communication\n26. Ownership Recommendation\n27. Engineering Escalation\n28. Confidence\n\nUse evidence IDs (`E1`, `E2`) and correlation IDs (`C1`, `C2`). State unavailable connectors and limitations. If the evidence cannot distinguish causes, say: **Insufficient evidence to determine the root cause.**\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}