Add skill for PostHog config defaults (autocapture / session recording / opt-out)

[sarahxsanders]

Why

Companion to a wizard concern: the legacy wizard-side regex scanner had medium-severity rules that fired when an agent silently wrote `autocapture: false`, `disable_session_recording: true`, or `opt_out_capturing: true` into a PostHog SDK init config. Those rules were removed in the wizard's warlock-migration PR — and (correctly) NOT added to warlock, because they're PostHog-specific, not platform-agnostic security concerns.

The wizard now has L0 protection via an agent commandment ("Keep PostHog data capture at its defaults..."), but no L2 enforcement. The natural place for L2 PostHog-specific rules is a context-mill skill — that matches the "skills own product knowledge" model the rest of the wizard uses.

What needs to happen

Add a context-mill skill (working name: `posthog-defaults-enforcer` or similar) that:

1. Documents the patterns that should NOT appear in SDK init config:
   • `autocapture: false`
   • `disable_session_recording: true` (and `disableSessionRecording: true`)
   • `opt_out_capturing: true` / `opted_out: true`
2. Documents the legitimate runtime form (`posthog.opt_out_capturing()` for GDPR consent) so the rules don't over-match.
3. Optionally ships YARA rules in the skill bundle that the wizard can load.

Related

• Wizard side: Add wizard-owned L2 ruleset for PostHog config defaults (autocapture / session recording / opt-out) wizard#592 tracks the L2 ruleset shape.

🤖 Generated with Claude Code

[ryanwaits]

just left notes on #175 about the L0 half.

i dont think this one is buildable as written. there's no loader for skill-bundled yara rules: no .yar or .yara under context/, and scan-warlock.js scans built skill zips as a CI check rather than loading rules out of them. and #592's option B rests on this:

Warlock supports consumer-supplied rules.

as far as i can tell it doesnt. the signature is scan(content: string), rules ship bundled in-package, no plugin api?

warlock's readme also names autocapture_disabled, session_recording_disabled and opt_out_capturing as rules it rejected during the port, and says best-practice checks belong in the wizard or context-mill as agent context

also nothing catches these today anyway as far as i can tell. the one shipped warlock rule that mentions autocapture is scan_context = "input", so it fires on content telling the agent to disable it, not on the agent writing autocapture: false (the L0 commandment is doing all the work)

so should this close in favor of the L0 text in #175? or if you do still want revert-on-write, that looks like wizard#592 option A, wizard-side. also happy to be wrong on any of this, still wrapping my head around how the three pieces fit together.