docs(compress): say that /caveman-compress sends the file to the model provider

[jwcastillo]

The README privacy section says "The skill runs on your machine and sends nothing", and skills/caveman-compress/SKILL.md doesn't mention that scripts/compress.py sends the file's full text to the configured provider: the claude CLI, the Anthropic API, or an OpenAI-compatible endpoint. The code already says this in a comment (SENSITIVE_BASENAME_REGEX: "ships raw bytes to the Anthropic API"), so this PR only brings the docs in line with it.

Changes (docs only, no code):

• skills/caveman-compress/SKILL.md: the description says the file's text goes to the configured model provider, and a short note under Purpose lists the providers and the existing refusal of secret-looking filenames.
• plugins/caveman/skills/caveman-compress/SKILL.md: synced byte for byte, the same way sync-skill.yml does.
• README.md → Privacy: names /caveman-compress as the exception to "sends nothing".

How I found it: a static and semantic pass with NVIDIA SkillSpector v2.12.0 flagged data flow in caveman-compress. I read each finding. The rest are false positives: the "credential access" hits are the code that refuses .env/credentials/.netrc, the env copy is what the subprocess needs, and the "hidden instructions" are the documented nocompress tags. The one real gap was the missing disclosure.

DCO: the commit is signed off.

🤖 Generated with Claude Code

[JuliusBrussee]

Reviewed — needs one change, then it's @JuliusBrussee's to accept. The disclosure is accurate and worth having; this is not a correctness objection.

The one blocker: the PR edits both skills/caveman-compress/SKILL.md and plugins/caveman/skills/caveman-compress/SKILL.md. Only the first is a source of truth — .github/workflows/sync-skill.yml copies skills/caveman-compress/ into that mirror on every push to main, so the second edit gets overwritten and should be dropped from the diff. Same note #1200 got; it's an easy trap in this tree.

I verified the claim rather than taking it on trust: /caveman-compress does send the file's text to the configured provider, and the secret-filename refusal happens before the read, so both halves of your warning hold.

Not adopted into #1196: a disclosure/wording change has no failing test behind it, and this routine only ships fixes it can demonstrate. The README Privacy edit reads fine to me and touches no benchmark number, but the skill description is what competes for activation across every installed agent, so the final wording is the maintainer's call.

---

Generated by Claude Code