/security-audit

name: security-audit
description: "Security audit — save tampering, cheat vectors, network exploits, data exposure, input validation. Before public or multiplayer release."
argument-hint: "[full | network | save | input | quick]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Agent, Bash(bash "*/.claude/skills/security-audit/../../hooks/yaml-helper.sh" resolve_config *)
model: sonnet

!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow`

**Automation mode**: Resolve `modes.automation` (`project.local.yaml` → `project.yaml` → default `collaborative`). Every `AskUserQuestion` call and every file write follows `.claude/docs/automation-modes.md` (collaborative asks always · guided major-only · autonomous logs and proceeds; `automation_always_ask` categories always prompt).

**`workflow`** (resolved above) decides only what Phase 7 tells you about the release gate: at `standard` and `full` it requires this report; at `minimal` it does not. The audit itself runs the same at every tier.

Security Audit

Security is not optional for any shipped game. Even single-player games have save tampering vectors. Multiplayer games have cheat surfaces, data exposure risks, and denial-of-service potential. This skill systematically audits the codebase for the most common game security failures and produces a prioritised remediation plan.

**Run this skill:**

• Before any public release (required for the Polish → Release gate at `workflow: standard` and `full`)
• Before enabling any online/multiplayer feature
• After implementing any system that reads from disk or network
• When a security-related bug is reported

**Output:** `production/security/security-audit-[date]-[scope].md` — the scope in the name keeps a same-day `quick` or `save` run from overwriting the `full` report the release gate reads.

---

Phase 1: Parse Arguments and Scope

**Modes:**

• `full` — all categories (recommended before release)
• `network` — network/multiplayer only
• `save` — save file and serialization only
• `input` — input validation and injection only
• `quick` — high-severity checks only (fastest, for iterative use)
• No argument — run `full`

Read `project.yaml` to determine the following, falling back to `.claude/docs/technical-preferences.md` for engine/language/platforms when a key is absent or empty:

• `engine.name` and `engine.language` — **load-bearing: they select the Phase 3

pattern set, and an engine with no sourced set for a category makes that category `NOT ASSESSED`.** If `engine.name` is absent or empty, say so in the report and treat every grep category as `NOT ASSESSED`; do not fall back to the Godot lists because they are the ones written out in full

• `platform.targets` (affects which attack surfaces apply)
• `platform.multiplayer` and `platform.online` — whether multiplayer/networking is

in scope. `technical-preferences.md` has no equivalent fields, so the legacy fallback cannot supply them.

> **ABSENT DOES NOT MEAN `false`.** These keys have a reader — > this skill — and **no writer in the setup flow**: neither > `/setup-engine` nor `/start` emits a `platform:` block, and only `/project-settings` > sets them, when someone runs it, so on most Claude Code Game Studios projects both keys are > absent. Defaulting them to `false` would skip **Category 2 (Network and > Multiplayer Security) on every project, genuinely multiplayer ones > included** — a security category failing open on a value nothing sets. > > When either key is absent or empty: **do not assume single-player, and do not > skip Category 2.** Ask the user whether the game has multiplayer or online > features. If you cannot ask, run Category 2 anyway and mark it > `NOT ASSESSED — multiplayer scope unconfirmed (platform.multiplayer unset — > set it with /project-settings)`, which makes `CLEAR TO SHIP` unreachable per Phase 5. > While the scope is unconfirmed, rate severity as for a multiplayer game — an > open HIGH is then DO NOT SHIP — and say in the report that the rating assumed > multiplayer, as `security-engineer` does. > Over-scanning a single-player game costs a few minutes; under-scanning a > multiplayer one ships the category unrun. > > Set them explicitly with `/project-settings platform.multiplayer=true` (they are > project-wide, so `--local` is refused). Recording it in `project.yaml` is the > fix; this rule is the guard for until someone does.

---

Phase 2: Spawn Security Engineer

Spawn `security-engineer` via `Agent` — the audit is its job, so do not run the categories in this session instead. If it cannot be spawned, say why, run the scan here, and let the report's **Audited by** line say so.

**Send this fixed brief template.** Fill only the `{…}` slots, from `project.yaml` (else technical preferences), the code root resolved per `.claude/docs/code-root-resolution.md`, and the Phase 3 text copied as written. Add nothing else: no view on the game's type, no expected severity, no opinion on any finding — a sentence of your own is where a pre-rating gets in.

Run a security audit of this project for /security-audit.

Scope: {full | network | save | input | quick}
Engine: {engine.name} {engine.version}, language {engine.language}
platform.multiplayer: {true | false | unset}    platform.online: {true | false | unset}    Phase 1 answer: {multiplayer | single-player | not asked}
Code root: {the resolved code root, or "unresolved"}
Also scan: {assets/data/ and the config files that exist, or "none"}
Categories to run, with their checks and grep patterns for this engine:
{each Phase 3 category this scope runs, copied as written, with the table's row for this engine}
NOT SOURCEABLE on this engine: {categories, or "none"} — report each NOT ASSESSED; never call it reviewed, verified safe or passed
Skipped, with reason: {e.g. "Category 2 — platform.multiplayer and platform.online are false", or "none"}
Re