Hi, and thanks for this skill — the API-driven Cloudflare diagnostics are genuinely useful, and check_cloudflare_config.py is a nice read-only companion.
One safety suggestion for cloudflare-troubleshooting/scripts/fix_ssl_mode.py. As written, the script issues a PATCH to /zones/{zone_id}/settings/ssl (lines 52–61) the moment it's invoked, with no confirmation step and no dry-run. main() reads the mode straight from argv and calls through (lines 132–136, 172–173). --purge-cache similarly fires a purge_everything POST with no guard (lines 95–104, 177–179). Since these change live production settings, a mistyped mode or the wrong domain takes effect instantly — e.g. flipping SSL to off/flexible on a production zone, or an unintended full cache purge. The script also overwrites the SSL mode without ever showing the operator the current value, so there's no old → new preview.
To be clear about scope: this isn't a vulnerability — the operator supplies their own credentials and arguments. It's a footgun, and a guard rail would bring it in line with the safety posture elsewhere in this marketplace (the macos-cleaner skill, for instance, advertises interactive confirmation).
Proposed change (no new dependencies, keeps the existing positional-arg interface):
- Default to dry-run. Without
--apply, fetch and print zone + current SSL mode → target mode, then exit without writing.
- Require an explicit
--apply before any mutating PATCH/POST (SSL change and cache purge).
- Echo
zone and old → new before applying, so the operator can eyeball it.
- Optionally, for the most destructive targets (
off/flexible, --purge-cache), require a typed confirmation even with --apply — happy to leave that to your preference.
I'm glad to open a PR with this (it's a focused diff in fix_ssl_mode.py plus a usage-text update, and I'll bump the skill version in marketplace.json per CONTRIBUTING/CLAUDE.md). Let me know if you'd prefer dry-run-by-default or apply-by-default-with-confirmation as the convention, and I'll match it. Thanks again for maintaining this.
Hi, and thanks for this skill — the API-driven Cloudflare diagnostics are genuinely useful, and
check_cloudflare_config.pyis a nice read-only companion.One safety suggestion for
cloudflare-troubleshooting/scripts/fix_ssl_mode.py. As written, the script issues aPATCHto/zones/{zone_id}/settings/ssl(lines 52–61) the moment it's invoked, with no confirmation step and no dry-run.main()reads the mode straight fromargvand calls through (lines 132–136, 172–173).--purge-cachesimilarly fires apurge_everythingPOST with no guard (lines 95–104, 177–179). Since these change live production settings, a mistyped mode or the wrong domain takes effect instantly — e.g. flipping SSL tooff/flexibleon a production zone, or an unintended full cache purge. The script also overwrites the SSL mode without ever showing the operator the current value, so there's noold → newpreview.To be clear about scope: this isn't a vulnerability — the operator supplies their own credentials and arguments. It's a footgun, and a guard rail would bring it in line with the safety posture elsewhere in this marketplace (the
macos-cleanerskill, for instance, advertises interactive confirmation).Proposed change (no new dependencies, keeps the existing positional-arg interface):
--apply, fetch and printzone + current SSL mode → target mode, then exit without writing.--applybefore any mutating PATCH/POST (SSL change and cache purge).zoneandold → newbefore applying, so the operator can eyeball it.off/flexible,--purge-cache), require a typed confirmation even with--apply— happy to leave that to your preference.I'm glad to open a PR with this (it's a focused diff in
fix_ssl_mode.pyplus a usage-text update, and I'll bump the skill version inmarketplace.jsonper CONTRIBUTING/CLAUDE.md). Let me know if you'd prefer dry-run-by-default or apply-by-default-with-confirmation as the convention, and I'll match it. Thanks again for maintaining this.