mythic-oracle/.claude/commands/precommit.md

Pre-Commit Code Review

You are acting as a code reviewer, not an assistant. Do not ask questions. Do not offer to make changes. Produce a structured written report and nothing else.

---

Step 1 — Load context in this order

1. Read CLAUDE.md in full. This is the authoritative source for all conventions, schema definitions, workflow rules, and architectural decisions.
2. Run git diff HEAD and read the full output. This is the primary subject of review.
3. Run git log --oneline -5 and read the output for recent commit context.

Do not begin the report until you have read all three.

---

Step 2 — Review categories

Evaluate the staged changes against each category below. For each category, list every finding — including absences (things that should be present but are not). If a category has no findings, write "No findings."

1. Scope adherence

• Do the changed files match the stated purpose of this commit?
• Are any unrelated files touched?
• Does the commit appear to bundle more than one logical change?
• Does the git log suggest this change is consistent with the current build phase?

2. Schema consistency

• Do any queries reference columns not present in the CLAUDE.md schema?
• Are foreign keys used correctly and consistently?
• Is int_score used instead of int for Intelligence in D&D 5e and Cha'alt tables?
• Are any schema changes being made inside db.js rather than via a migration script?
• Are any tables being dropped and recreated instead of altered?
• Is better-sqlite3 the only database interface? No ORMs, no query builders.

3. API conventions

• Are all backend calls routed through api.js? No direct fetch calls elsewhere.
• Do new routes follow RESTful conventions consistent with existing routes?
• Do responses use consistent JSON structure and appropriate HTTP status codes?
• Are campaign-scoped routes validating campaign_id before querying?
• Are missing resources returning 404, not empty arrays or silent failures?

4. JS module patterns

• Are all JS files using ES module syntax (import/export)? No CommonJS.
• Have any frameworks, libraries, or build steps been introduced?
• Is getActiveCampaign() / setActiveCampaign() from app.js used for campaign context — not a local re-fetch or a hardcoded value?
• Is table data loaded from the API, not hardcoded in JS or HTML?
• Does any feature view add chaos factor controls? (Sidebar only — flag if so.)

5. Workflow rules

• Does this change touch only what the prompt scope described?
• Are there any signs of unrelated cleanup, refactoring, or opportunistic changes bundled into this commit?
• If new files were created, are they in the correct locations per the folder structure in CLAUDE.md?
• Is the commit message (if present) accurate and specific?

6. Security and hardening

Flag both active violations AND absences — a missing control is as important as a wrong one.

• Input validation: Are all incoming request parameters and body fields validated for presence and basic format before use? Flag any route where validation is absent.
• SQL injection: Are all database queries using parameterized statements? Flag any string interpolation or concatenation in query construction.
• Error handling: Do error responses avoid leaking stack traces, file paths, query text, or internal state to the client?
• Output safety: Is any user-supplied content being inserted into the DOM? Flag any use of innerHTML, outerHTML, or document.write with dynamic data.
• Hardcoded values: Are there any hardcoded credentials, tokens, secrets, or environment-specific absolute paths?
• Campaign scoping: For any route that reads or writes campaign-scoped data, is the campaign_id confirmed to belong to a real campaign before use?
• Logging: Is any sensitive user data (names, notes, content fields) being logged to the console or written to any output?

---

Step 3 — Report format

Write the report in this exact structure:

## Mythic Oracle — Pre-Commit Review

### 1. Scope Adherence
[CRITICAL/WARNING/INFO] <finding> — <one sentence explaining why this matters>

### 2. Schema Consistency
...

### 3. API Conventions
...

### 4. JS Module Patterns
...

### 5. Workflow Rules
...

### 6. Security & Hardening
...

---

### Verdict
Criticals: yes/no
Warnings: N
Recommendation: <one sentence — safe to commit / address criticals first /
consider resolving warnings before committing>

Use exactly these severity tags:
- `[CRITICAL]` - do not commit until resolved
- `[WARNING]` - worth addressing; your call whether it blocks the commit
- `[INFO]` - minor observation; no action required