Compatibility Playbook

SlashSnip works best when compatibility is treated as a workflow-level question, not as a vague marketing claim.

Recently re-tested

These browser surfaces were recently re-checked during manual QA and site copy cleanup:

• Gmail
• ChatGPT
• Claude

That does not mean every field inside every complex web app behaves the same way. It means these surfaces are part of the current known-good set.

Use caution here

Treat these as caution zones until you verify your exact workflow:

• Google Docs
• canvas-based editors
• highly customized rich-text editors
• apps with aggressive DOM rewrites

Detection pass is not enough

A content script loading successfully does not prove a usable workflow.

Before calling a surface "good", validate:

1. Trigger detection
2. Direct insertion
3. Menu open and item selection
4. Multiline expansion
5. Variable resolution

Best-practice checklist

• Test //shortcut and /// separately.
• Keep one starter snippet simple and one QA snippet multiline.
• If a menu appears in the wrong place, re-check caret positioning rather than assuming the whole trigger system is broken.
• Separate SlashSnip-attributed errors from site-side console noise.

What to do when a site is flaky

• Try the alias triggers @@shortcut and @@@.
• Reduce the snippet to plain text and remove variables.
• Test in a simpler field inside the same product.
• Keep a fallback snippet pack for manual copy/paste if the editor is highly customized.