The most dangerous part of XSS is what developers don't know is possible. There are lots of sinks and sources and the more features browsers support, the more surface area is exposed.

Lots of developers intuitively notice reflective XSS, but fewer notice persistent XSS and even fewer know about DOM-based XSS. Each of these has several, even dozens, of sinks and sources to check + be aware of.

I think your offerings would be vastly more valuable if you had a CSP policy generator that defaults to the strictest possible settings, allowing the user to opt out / loosen some rules. Perusing your docs, you only describe a small subset of what CSP is capable of. Your average user is short on time and will likely copy-paste your example policies as their first implementation iteration.

It's important to explain that every page on their domain should be protected by a CSP policy. Protecting just a subset of the domain means that there is still vulnerable surface area.

Iframe embeds. Injected forms. Injected IMG tags. Injected meta tags. Data URIs. SVG DOM events. LocalStorage. Cookie overflow attacks. Charset sniff attacks. Charset attacks against specific databases. IE CSS expressions. Image/HTML + JS Polyglots. etc.

A developer that isn't familiar with all of the possible attacks is likely to not make the CSP as restrictive as needed. I highly recommend if you are going to tackle XSS, try and aim to provide value for all XSS attacks, not just the easiest to defend against.

Also, you should provide resources to explain why XSS is dangerous, what is potentially at risk, how much companies pay for XSS on bug bounties, and resources for the developer to know how to craft a successful CSP policy. Without these, you aren't selling your value proposition.