Ccc Harden

/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

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)

Trigger flow

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:

   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:

• 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

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)

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