git:20260707.947ab2f to git:20260722.9d3ab82

10 added, 8 removed. Audit A to A.

---

name: ccc-harden

description: "Production hardening audit across 11 pillars (Vercel, GitHub, Sentry, PostHog, Stripe, Cloudflare, Secrets/PII). Read-only; --fix applies safe auto-fixes. Use pre-launch. NO PII."

allowed-tools:

- Read

- Bash

- Grep

- Glob

- AskUserQuestion

---

- # /ccc-harden — Production Hardening Audit

+ # $ccc-harden — Production Hardening Audit

Audit a site across **11 hardening pillars** to confirm it's safe to ship. Read-only by default. Apply safe auto-fixes with `--fix`.

## What it checks

| Pillar | What it verifies |

|--------|-----------------|

| **1. Vercel** | Project link, env vars, deploy headers, deploy protection, domain |

| **2. GitHub Linkage** | Remote URL, branch tracking, .gitignore coverage, working tree clean |

| **3. GitHub Org** | Branch protection on main, Dependabot enabled, secret scanning, CODEOWNERS |

| **4. Sentry** | SDK installed, DSN set, source maps uploading, alert rules, sample rate |

| **5. PostHog** | SDK installed, env vars set, autocapture config, event whitelist |

| **6. Plausible** | Script present, site ID, goals, funnels, recent traffic |

| **7. Clarity** | Script presence, project ID |

| **8. Google** | GA4, Search Console verified, sitemap submitted, Tag Manager |

| **9. Stripe** | Keys present, webhook configured, test/live separation |

| **10. Secrets & PII** | gitleaks scan, CSP/HSTS/X-Frame headers, .env audit, log scrubbing |

| **11. Cloudflare** | DNS health, TLS/SSL, bot management, caching, HTTP/3, WAF |

## When to use

✅ **Use when:**

- Pre-launch checklist for a new site

- Before a security review or compliance audit

- Periodic monthly/quarterly health check

- After a major refactor that touched config files

- When you suspect a leaked secret

🚫 **Don't use when:**

- Project is pre-MVP / local-only (overkill)

- - Quick fix that doesn't touch infra/config (use `/ccc-doctor` instead)

+ - Quick fix that doesn't touch infra/config (use `$ccc-doctor` instead)

## Trigger flow

- When the user invokes `/ccc-harden`:

+ When the user invokes `$ccc-harden`:

1. **Read `.harden.json`** at project root. If missing, run `bash ~/.claude/skills/harden-site/lib/tier.sh` to auto-classify (production/staging/parked/personal) and generate it.

2. **Ask the user** via AskUserQuestion which mode:

- **Audit only** (read-only, default — recommended)

- **Apply auto-fixes** (writes to vercel.json, .gitignore, etc.)

- **Single pillar** (pick from list of 11)

3. **Run pillars** based on `.harden.json` enabled list:

```bash

for pillar in ~/.claude/skills/harden-site/pillars/*.sh; do

name=$(basename "$pillar" .sh | sed 's/^[0-9]*-//')

enabled=$(jq -r ".pillars[\"$name\"]" .harden.json)

[ "$enabled" = "true" ] && bash "$pillar" --audit

done

```

4. **Aggregate results** into a single summary:

- Total checks · pass · warn · fail · skipped

- Top 5 manual actions required

- Top 5 auto-fixable items

- Severity-ranked (CRITICAL → HIGH → MEDIUM → LOW)

5. **Offer next step** via AskUserQuestion:

- **Apply auto-fixes now** (re-runs with `--fix`)

- **Show full report** (paginated output of all pillars)

- **Create Linear issues** for manual actions

- **Done — I'll triage manually**

## Privacy guarantee (NO PII)

CC Commander's hardening audit **never** sends data to PostHog or any telemetry endpoint. Every check is:

- Local-only (reads files, runs `gh`/`vercel`/`fly`/`op` CLIs)

- Reports rendered in the terminal

- Findings written to `.harden.report.md` (gitignored by default)

- Telemetry from `/ccc-harden` itself emits **only**:

+ Telemetry from `$ccc-harden` itself emits **only**:

- `skill_invoked` with `skill_id=ccc-harden`

- `harden_audit_completed` with `{ tier, pillars_run, pass, warn, fail }` (counts only, no file paths, no findings)

Zero PII. Zero secrets. Zero file content. Ever.

## Exit behavior

| Result | Exit | Next action |

|--------|------|-------------|

| All pass | 0 | "✅ Ready to ship." |

| Warnings only | 1 | "🟡 Review warnings before launch." |

| Failures | 2 | "🔴 Block launch until fixes applied." |

| Missing tokens | 3 | "⏭️ Pillar skipped — set up `op` access." |

## Setup (first run)

If the user has never run hardening before:

1. Auto-classify the project: `bash ~/.claude/skills/harden-site/lib/tier.sh`

2. Edit `.harden.json` to enable/disable pillars per their stack

3. For pillars that need API tokens (Vercel, Cloudflare, PostHog management API):

- Verify tokens in 1Password Alfred vault (see `~/.claude/skills/harden-site/TOKENS.md`)

- Run `op signin` if not already authenticated

4. First run is read-only — always show what would change before fixing

## Related skills

- - `/ccc-doctor` — generic project health check (lighter weight, no API tokens)

- - `/ccc-security` — OWASP audit + threat modeling (deeper than infra hardening)

- - `/ccc-deploy-check` — pre-deploy gate (12 quick checks before pushing)

- - `/ccc-deploy` — actual deploy workflow (uses hardening output as a precondition)

+ - `$ccc-doctor` — generic project health check (lighter weight, no API tokens)

+ - `$ccc-security` — OWASP audit + threat modeling (deeper than infra hardening)

+ - `$ccc-deploy-check` — pre-deploy gate (12 quick checks before pushing)

+ - `$ccc-deploy` — actual deploy workflow (uses hardening output as a precondition)

## Vendor sources

This skill wraps `~/.claude/skills/harden-site/` (Kevin's site-hardening skill, a fork of the upstream "harden" pattern). The 11 pillars and auto-fix logic live there; this plugin skill is the UX layer that makes them discoverable inside CC Commander.

To update the underlying logic, edit `~/.claude/skills/harden-site/pillars/*.sh` — this skill re-reads them every invocation.

---

> ⚙️ **Fable contract:** plan before build · verifier ≠ worker · prove before alarm · loops need gates · leave durable state — `rules/fable-method.md`

+ > (On Codex, present these options as a numbered list and ask the user to reply with a number — AskUserQuestion is Claude-only.)