@mrciphersmith/keryx 0.2.9

package/src/gdskills/bundled/skills/review/review-security-code/SKILL.md

@@ -0,0 +1,348 @@
+---
+name: review-security-code
+description: "Use when a code-level security review is requested, checking for injection vulnerabilities, auth gaps, insecure cryptography, secrets, and OWASP Top 10 patterns in changed code. NOT for infrastructure, deployment, or dependency audits."
+triggers:
+  - "review security"
+  - "security review"
+  - "check for vulnerabilities"
+  - "security check"
+  - "OWASP review"
+  - dispatched by review-orchestrator
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "review"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode,claude"
+---
+
+# Review: Security Code (Code-Level Vulnerabilities)
+
+## Purpose
+
+Finds exploitable security vulnerabilities introduced in the changed code of the current branch. Covers injection, auth/authz gaps, IDOR, secrets, insecure crypto, CSRF, path traversal, and framework-specific patterns (NestJS, React). Produces findings with explicit attack vectors and concrete fixes.
+
+This skill covers **code-level security only**. It does NOT audit npm/bun dependency trees, Docker configurations, or deployment surfaces — use `security-audit` for those.
+
+---
+
+## Input Contract
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| Branch / diff range | No | Defaults to merge-base..HEAD + uncommitted changes |
+| Explicit commit hash/range | No | Review only that range when provided |
+| `JOB_NAME` | No | Job name when dispatched by orchestrator |
+| `CONTEXT_PATH` | No | Path to context doc when dispatched by orchestrator |
+
+---
+
+## Scope Boundaries
+
+| Concern | This skill | Use instead |
+|---------|-----------|-------------|
+| Injection (SQL, XSS, command, SSTI) | YES | — |
+| Auth/authz gaps, IDOR, privilege escalation | YES | — |
+| Missing input validation / DTO validation | YES | — |
+| Hardcoded secrets, logging secrets | YES | — |
+| Insecure cryptography (MD5, SHA1, weak random) | YES | — |
+| CSRF, path traversal, open redirect | YES | — |
+| OWASP Top 10 code patterns | YES | — |
+| NestJS-specific: missing guards, unvalidated DTOs | YES | — |
+| React-specific: dangerouslySetInnerHTML, eval() | YES | — |
+| npm/bun dependency vulnerabilities | NO | `security-audit` |
+| Infrastructure / Docker / deployment security | NO | `security-audit` |
+| Performance bottlenecks | NO | `review-performance` |
+| Logic correctness, architecture | NO | `review-logic`, `review-architecture` |
+| Code style, naming | NO | `code-style-review` |
+
+---
+
+## Scope Detection
+
+See shared script: `skills/shared/git-merge-base.md`
+
+Run the script from that file to determine `MERGE_BASE` (`BASE_SHA`) and `SCOPE` before proceeding.
+
+### Commands to collect the review slice
+
+```bash
+git status
+git log --oneline "${BASE_SHA}..HEAD"
+git diff --stat --name-status "${BASE_SHA}..HEAD"
+git diff "${BASE_SHA}..HEAD"
+
+# Include uncommitted changes (default mode):
+git diff --stat --name-status "${BASE_SHA}"
+git diff "${BASE_SHA}"
+git ls-files --others --exclude-standard
+```
+
+For explicit hash/range mode:
+
+```bash
+git diff --stat --name-status <FROM_SHA>..<TO_SHA>
+git diff <FROM_SHA>..<TO_SHA>
+```
+
+---
+
+## Review Checklist
+
+Work through every category below for each changed file. Tie every finding to a concrete line in the diff.
+
+### 1. Injection Vulnerabilities
+
+**SQL Injection**
+- [ ] Raw SQL built by string concatenation or template literals with user input
+- [ ] ORM `query()` / `rawQuery()` calls with unparameterized values
+- [ ] TypeORM `createQueryBuilder` using `.where(\`field = '${value}'\`)` instead of parameterized bindings
+
+Attack vector template: _"Attacker sends `' OR '1'='1` as `<param>`, bypassing WHERE clause."_
+
+**XSS (Cross-Site Scripting)**
+- [ ] React `dangerouslySetInnerHTML` with unsanitized user content
+- [ ] Template engines rendering user data without escaping
+- [ ] Server-side HTML construction with string concatenation
+
+Attack vector template: _"Attacker injects `<script>document.cookie</script>` via `<param>`."_
+
+**Command Injection**
+- [ ] `child_process.exec()` / `execSync()` with user-supplied arguments
+- [ ] Shell string building: `exec(\`ls ${userInput}\`)`
+- [ ] Prefer `execFile()` / `spawn()` with argument arrays
+
+Attack vector template: _"Attacker passes `; rm -rf /` as `<param>`, executed in shell context."_
+
+**Server-Side Template Injection (SSTI)**
+- [ ] Template engine `render()` called with user-controlled template string (not just data)
+- [ ] Dynamic template loading from user-supplied names without allowlist
+
+**`eval()` / `Function()` / `vm.runInNewContext()`**
+- [ ] Any usage with non-literal, non-compile-time strings
+
+### 2. Authentication and Authorization
+
+**Missing Authentication Guards**
+- [ ] NestJS: controllers or routes missing `@UseGuards(JwtAuthGuard)` (or equivalent)
+- [ ] Express: middleware chain missing auth check before sensitive handler
+- [ ] GraphQL resolvers missing `@UseGuards` decorator
+
+**Missing Authorization / RBAC**
+- [ ] NestJS: routes with data-mutating operations missing `@Roles()` / `@Permissions()`
+- [ ] Guard present but role check is overly permissive (e.g., allows any authenticated user for admin action)
+
+**Broken Auth Logic**
+- [ ] JWT verification disabled or bypassed (`verify: false`, `algorithms: []`)
+- [ ] Session fixation: session ID not rotated on privilege elevation
+- [ ] Password comparison with `==` instead of `crypto.timingSafeEqual` or bcrypt
+
+**Privilege Escalation**
+- [ ] User can change their own `role`, `permissions`, or `isAdmin` via a user-facing update endpoint
+- [ ] User ID taken from request body instead of authenticated session/token
+
+### 3. Insecure Direct Object References (IDOR)
+
+- [ ] DB lookup by `id` taken from request params/body without verifying ownership: `repo.findOne({ id: req.params.id })` — no `userId` scope check
+- [ ] File access, download, or deletion by filename/path from request without ownership validation
+
+Attack vector template: _"Attacker replaces `id=123` with `id=456` in request, accessing another user's resource."_
+
+### 4. Missing Input Validation / Sanitization
+
+- [ ] NestJS: DTO class without `class-validator` decorators (`@IsString()`, `@IsEmail()`, `@IsUUID()`, etc.)
+- [ ] NestJS: `ValidationPipe` not applied globally or per-handler
+- [ ] Express: no `express-validator` or equivalent on body/query params
+- [ ] Accepting unbounded `limit`/`offset` from user without max cap (DoS vector)
+- [ ] File upload: MIME type and extension validated only client-side, not server-side
+- [ ] Email/URL fields accepted without format validation
+
+### 5. Secrets and Credentials
+
+- [ ] Hardcoded API keys, passwords, tokens, or private keys in source
+- [ ] Secrets passed via URL query params (end up in logs and proxies)
+- [ ] Passwords, tokens, or PII logged via `console.log`, `logger.debug`, or error serialization
+- [ ] `.env` files committed to version control
+- [ ] JWT secret is a short literal string (`"secret"`, `"myapp"`)
+
+### 6. Insecure Cryptography
+
+- [ ] MD5 or SHA1 used for password hashing or security tokens
+- [ ] `Math.random()` used to generate tokens, nonces, or session IDs — use `crypto.randomBytes()`
+- [ ] AES-ECB mode (deterministic, leaks patterns) — prefer AES-GCM
+- [ ] RSA with key size < 2048 bits
+- [ ] Hardcoded IV/salt instead of random per-operation
+
+### 7. CSRF
+
+- [ ] State-changing endpoints (POST/PUT/PATCH/DELETE) accessible from browser context without CSRF token validation
+- [ ] CSRF protection middleware bypassed for specific routes
+- [ ] SameSite cookie attribute absent or set to `None` without `Secure`
+
+### 8. Path Traversal
+
+- [ ] File path constructed from user input without normalization and allowlist check: `fs.readFile('./uploads/' + filename)`
+- [ ] `path.join()` used but result not validated against base directory (join can escape with `..`)
+- [ ] Correct pattern: `path.resolve(BASE, filename)` followed by check that result starts with `BASE`
+
+Attack vector template: _"Attacker sends `filename=../../etc/passwd`, reading arbitrary server files."_
+
+### 9. Open Redirect
+
+- [ ] Redirect target taken from user-supplied query param without allowlist: `res.redirect(req.query.returnTo)`
+- [ ] Only relative paths or allowlisted origins should be accepted as redirect targets
+
+### 10. React-Specific Patterns
+
+- [ ] `dangerouslySetInnerHTML={{ __html: userContent }}` without DOMPurify or equivalent sanitization
+- [ ] `eval(userInput)` or `new Function(userInput)` in component or hook
+- [ ] Sensitive data stored in `localStorage` / `sessionStorage` (XSS accessible)
+- [ ] `postMessage` handler without origin check
+
+### 11. NestJS-Specific Patterns
+
+- [ ] Controller method lacks `@UseGuards` when the route handles sensitive data or mutations
+- [ ] DTO class lacks `class-validator` annotations; `ValidationPipe` has `whitelist: false` or `forbidNonWhitelisted: false`
+- [ ] `@Body() body: any` — accepting untyped, unvalidated body
+- [ ] `@Public()` decorator used on an endpoint that should require auth
+- [ ] File upload handler missing MIME-type and size validation
+
+---
+
+## Iron Laws
+
+1. **Every security finding MUST state the attack vector explicitly.** Name the attacker action, the entry point, and the impact. No attack vector → no finding above INFO.
+2. **A finding without a reproducible code path is INFO, not blocker.** "Could theoretically..." = INFO. "Attacker sends X to endpoint Y, which executes Z" = blocker/major.
+3. **Never flag theoretical vulnerabilities.** The vulnerable code path must exist in the changed diff. Do not report hypothetical misuse of safe APIs.
+4. **Do not flag the same pattern twice.** If the same class of issue (e.g., missing `@UseGuards`) appears in five files, group them under one finding with all locations listed.
+
+---
+
+## Output Contract
+
+### Class scope — required for `blocker` and `major`
+
+Every `blocker` and `major` finding must carry `class_scope`: **every** site that
+holds the shape you found, and **how you enumerated them** — the grep or query
+you ran, or the guard that derives the set.
+
+A finding anchored to one `file:line` is a claim about one site. The recorded
+history of this repository is that a fix then repairs that site and leaves its
+siblings: one writer of five, one operator instruction of four, six readers of
+eight. Each was found by the *next* review round, which is why reviews here have
+run to seven and four rounds instead of one.
+
+```yaml
+class_scope:
+  sites: ["src/lib/shell-config.ts:60", "src/session/store.ts:133"]
+  enumeration_method: "grep for the config-path resolvers; 7 writers, 2 unguarded"
+```
+
+"I checked the others" is not an enumeration method. A single-entry `sites` list
+is a claim that the class has exactly one member — make it deliberately, because
+`review-finding.schema.json` accepts it and the next round tests it.
+
+`minor` and `info` may omit it: enumerating the class for every low-severity
+observation is theatre, not rigour.
+
+### Status line (first line of response)
+
+```
+STATUS: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+```
+
+- `DONE` — review complete, findings (if any) are below, no external info needed
+- `DONE_WITH_CONCERNS` — review complete but one or more blockers or majors found
+- `NEEDS_CONTEXT` — cannot determine whether code is vulnerable without additional context (e.g., missing route config, missing auth middleware file not in diff)
+- `BLOCKED` — cannot run git commands or access the repo
+
+### Report structure
+
+```markdown
+STATUS: DONE_WITH_CONCERNS
+
+## Security Review
+
+### Scope
+- Branch: `<BRANCH>`
+- Parent ref: `<PARENT>`
+- Merge-base: `<BASE_SHA>`
+- Scope mode: default-with-uncommitted | explicit-hash-range
+- Changed files reviewed: <N>
+
+### Summary
+- Blockers: <N>
+- Major: <N>
+- Minor: <N>
+- Info: <N>
+
+### Findings
+
+### [F-001] Title
+- **Severity**: blocker | major | minor | info
+- **File**: path/to/file.ts:line
+- **Attack vector**: precise description of how an attacker exploits this
+- **Problem**: what is wrong in the code
+- **Why it matters**: concrete impact (data breach, account takeover, RCE, etc.)
+- **Fix**: concrete suggestion
+- **Patch** (optional):
+```diff
+- vulnerable line
++ fixed line
+```
+
+### Clean Areas
+[List categories with no findings, confirming they were checked]
+```
+
+### Severity definitions
+
+| Severity | Meaning |
+|----------|---------|
+| `blocker` | Exploitable vulnerability in the current code path; must fix before merge |
+| `major` | High-likelihood risk with a plausible attack scenario; strongly recommended before merge |
+| `minor` | Hardening improvement or defense-in-depth; can ship but should be tracked |
+| `info` | Pattern worth noting; no clear attack vector in current code |
+
+---
+
+## Red Flags Table
+
+Stop and re-read these rules if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "It's probably behind auth so injection doesn't matter" | Auth is a separate layer; injection must be fixed at the data layer regardless |
+| "The team would never send that payload" | Attackers are not on the team |
+| "MD5 is used for caching keys, not passwords — it's fine" | State it as INFO, but do not silently skip it; it often drifts |
+| "I'll downgrade to minor to avoid friction" | Severity reflects real risk, not social dynamics |
+| "The code uses an ORM so SQL injection is not possible" | ORMs have raw-query escape hatches; verify parameterization |
+| "No attack vector found — I'll call it major anyway" | No attack vector = INFO only, per Iron Law 1 |
+| "It's outside the diff but the pattern is clearly wrong" | Only flag changed code; flag legacy via INFO with note to track separately |
+
+---
+
+## Job Context Awareness
+
+When dispatched by `job-orchestrator` or `review-orchestrator` as part of a job pipeline, the prompt MAY include:
+
+```
+JOB_NAME:     <job-name>
+CONTEXT_PATH: <JOBS_ROOT>/<job-name>/ai/context.md
+```
+
+If provided and the file exists, read the context document before starting the review. Use it to:
+- Understand which auth framework is in use (custom JWT, Passport, Keycloak, etc.)
+- Identify intentional public endpoints that are documented as unauthenticated by design
+- Understand which validation library and pipe configuration the project uses
+- Avoid flagging intentional architectural security decisions as findings
+
+If the file does not exist or is not provided, proceed normally — context is optional and non-blocking.
+
+
+## Orchestrated Review Contract
+
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
+
+---
+

package/src/gdskills/bundled/skills/review/review-strict/SKILL.md

@@ -0,0 +1,328 @@
+---
+name: review-strict
+description: |
+  Use when: a strict engineering pass is needed — either as a meta-reviewer reading consolidated
+  findings from other reviewers and elevating weak findings, or standalone on a git diff.
+  Covers "strict review", "review --strict", "boss review", "review as boss", or dispatched
+  by review-orchestrator as an optional post-pass after other reviewers complete.
+  NOT for: first-pass review (run domain reviewers first); large refactors outside the diff
+  scope (file separately).
+version: "1.0.0"
+triggers:
+  - "strict review"
+  - "review --strict"
+  - "boss review"
+  - "review as boss"
+metadata:
+  author: "MrCipherSmith"
+  version: "1.0.0"
+  category: "review"
+license: "MIT"
+compatibility: "cursor,codex,zed,opencode,claude"
+---
+
+# Review — Strict (Meta-Reviewer)
+
+Strict engineering review pass. This is a **meta-reviewer**: it reads findings from other
+reviewers (or the raw diff when run standalone) and applies strict engineering judgment.
+It elevates understated findings, adds architectural commentary, and catches issues that
+domain reviewers may have let through. Style: direct, no-fluff, engineering-focused.
+
+---
+
+## Workflow
+
+```
+review-strict Progress:
+- [ ] Step 1: Read Job Context (if CONTEXT_PATH provided)
+- [ ] Step 2: Determine input mode (meta or standalone)
+- [ ] Step 3: If standalone — determine git scope and collect diff
+- [ ] Step 4: If meta — ingest findings from other reviewers
+- [ ] Step 5: Apply strict principles to findings or diff
+- [ ] Step 6: Elevate understated findings
+- [ ] Step 7: Add new findings not caught by other reviewers
+- [ ] Step 8: Check single source of truth violations
+- [ ] Step 9: Emit enhanced findings + strict commentary
+```
+
+---
+
+## Input Contract
+
+| Field | Type | Required | Description |
+|-------|------|----------|-------------|
+| `findings` | string | no | Consolidated findings from other reviewers (markdown). When present, operate in meta mode. |
+| `branch` | string | no | Branch to review. Defaults to current branch. Required in standalone mode. |
+| `commit_range` | string | no | Explicit range (e.g., `abc123..HEAD`). Overrides merge-base in standalone mode. |
+| `context_doc` | string | no | Path to job context document (e.g., `<JOBS_ROOT>/<job>/ai/context.md`). |
+
+---
+
+## Mode Detection
+
+**Meta mode** (preferred when dispatched by review-orchestrator `--strict`):
+- Input includes pre-existing findings from domain reviewers
+- Read those findings, then read the diff for context
+- Operate on both: elevate weak findings, add new ones
+
+**Standalone mode** (when invoked directly without pre-existing findings):
+- No findings provided
+- Determine git scope via `skills/shared/git-merge-base.md`
+- Collect diff and apply full strict checklist independently
+
+---
+
+## Scope Detection (standalone mode)
+
+See shared script: `skills/shared/git-merge-base.md`
+
+```bash
+# Default mode — all changes from merge-base to working tree
+git diff --name-only "${BASE_SHA}"
+git diff "${BASE_SHA}"
+
+# Explicit range mode
+git diff --name-only <FROM_SHA>..<TO_SHA>
+git diff <FROM_SHA>..<TO_SHA>
+```
+
+---
+
+## Strict Principles
+
+### Elevation Rules (meta mode)
+
+When reading findings from other reviewers, elevate severity when:
+
+| Condition | Elevate to |
+|-----------|-----------|
+| Finding labeled `minor` but could cause a bug under specific conditions | `major` |
+| Finding labeled `major` but blocks correctness or data integrity in any realistic scenario | `blocker` |
+| Finding labeled `info` but represents a design flaw (not just a suggestion) | `minor` or `major` |
+| Finding is vague ("consider refactoring X") without a concrete fix | Downgrade to `info` or rewrite with concrete fix |
+
+Every elevation must cite the line or code evidence that justifies the change. No elevation without evidence.
+
+---
+
+### Core Strict Checks
+
+**No ducktape fixes**
+- A fix that masks a symptom rather than addressing the root cause — flag as `major`
+- Example: `setTimeout(fn, 0)` to defer a race condition instead of fixing the race — flag as `major`; demand root cause fix
+- Example: `|| []` to avoid a null check instead of ensuring the upstream always returns an array — flag as `minor` if trivial, `major` if the null case indicates a real upstream bug
+
+**No magic timeouts**
+- `setTimeout(fn, 0)`, `setTimeout(fn, 100)`, `setTimeout(fn, 500)` without a comment explaining exactly why — always flag as `major`
+- Comment must explain: what is being deferred, why, and what the correct fix would be if time allowed
+- `setInterval` without a cleanup mechanism — `major`
+
+**No `any` and no unsafe casts**
+- `any` in new code — `major`
+- `as any` — `major`
+- `as unknown as T` without an explanatory comment — `major`
+- `@ts-ignore` without an explanatory comment — `major`
+
+**TODO comments in merged code**
+- `// TODO` / `// FIXME` / `// HACK` present in the diff — flag as `minor` with a note: "file a ticket or resolve before merge"
+- `// TODO: remove before deploy` in production-bound code — **blocker**
+
+**No architectural shortcuts**
+- Logic in the wrong layer: UI layer calling APIs directly, controller containing business rules, view accessing store internals — `major`
+- Challenge with: "why is this in this layer?" — must have a concrete answer
+- Cross-cutting concerns scattered in multiple places instead of one — `major` (single source of truth violation)
+
+**Single source of truth**
+- Same rule or check duplicated in two or more places — flag as `major`
+- Example: input validation logic in both the controller and the service — pick one authoritative location
+- Example: same constant defined in two files — centralize
+
+**MobX conventions (when MobX is in the diff)**
+- Inter-store callbacks (`onChangeX`, `handleX`, `syncX`, `onFireX`) that are `public` — flag as `major` ("should be `private`; public only if called from JSX")
+- `useCallback` or `useMemo` added without a demonstrable need (no expensive computation, no stable reference requirement) — flag as `minor`
+- MobX `autorun` or `reaction` without a disposal mechanism — flag as `major` (memory leak)
+
+**Conventions**
+- `currentState` naming: observable state fields named with `current` prefix when they represent present value — flag inconsistency as `minor`
+- Interface names without `I` prefix (`UserService` as an interface instead of `IUserService`) — flag as `minor`
+
+**No scope expansion**
+- Large refactors outside the diff scope: note them as `info` with "out of scope — file separately"
+- Never propose a rewrite of unrelated code in the same response
+
+---
+
+## Architectural Commentary
+
+After findings, add a brief "Not Today" section for:
+- Architectural shortcuts visible in the diff that are not bugs but will hurt maintainability
+- Technical debt introduced intentionally or unintentionally
+- Patterns that contradict the project's stated architecture
+
+Use the phrase "not today" sparingly — only when a shortcut was taken that needs to be acknowledged.
+Format: `> **Not today:** [what was shortcutted and why it matters long-term]`
+
+This section is non-blocking (info-level). It is opinion, not a finding. Keep it to ≤3 items.
+
+---
+
+## Iron Laws
+
+| Rule | Rationale |
+|------|-----------|
+| Every finding must cite code evidence (file:line or diff hunk) | "Strictly speaking" without evidence = `info` only |
+| No elevation without a concrete reason stated | Elevation is a claim; claims need backing |
+| No scope expansion — large refactors outside the diff = "out of scope, file separately" | Scope creep in reviews is as harmful as in implementation |
+| Severity of a finding is per-finding, never averaged or influenced by other findings | Each finding stands on its own |
+| `setTimeout(0)` — always flag, no exceptions | There is always a better solution |
+| `any` in new code — always flag, no exceptions | Type safety is non-negotiable |
+
+---
+
+## Orchestrated Review Contract
+
+When dispatched by `review-orchestrator`, follow the provided `reviewer-input.schema.json` payload. Return a `REVIEW_RESULT` object compatible with `skills/review-orchestrator/reviewer-finding.schema.json`, then a concise markdown summary. Keep findings evidence-based, include concrete `suggested_fix` for every blocker/major, and return `NEEDS_CONTEXT` instead of guessing when required context is missing.
+
+---
+
+## Finding Format
+
+### Class scope — required for `blocker` and `major`
+
+Every `blocker` and `major` finding must carry `class_scope`: **every** site that
+holds the shape you found, and **how you enumerated them** — the grep or query
+you ran, or the guard that derives the set.
+
+A finding anchored to one `file:line` is a claim about one site. The recorded
+history of this repository is that a fix then repairs that site and leaves its
+siblings: one writer of five, one operator instruction of four, six readers of
+eight. Each was found by the *next* review round, which is why reviews here have
+run to seven and four rounds instead of one.
+
+```yaml
+class_scope:
+  sites: ["src/lib/shell-config.ts:60", "src/session/store.ts:133"]
+  enumeration_method: "grep for the config-path resolvers; 7 writers, 2 unguarded"
+```
+
+"I checked the others" is not an enumeration method. A single-entry `sites` list
+is a claim that the class has exactly one member — make it deliberately, because
+`review-finding.schema.json` accepts it and the next round tests it.
+
+`minor` and `info` may omit it: enumerating the class for every low-severity
+observation is theatre, not rigour.
+
+```markdown
+### [F-001] Title
+
+- **Severity**: blocker | major | minor | info
+- **File**: path/to/file.ts:line
+- **Problem**: what is wrong
+- **Why it matters**: correctness / testability / conventions / maintainability
+- **Fix**: concrete suggestion
+- **Elevated from**: minor → major (or: new finding) <!-- only in meta mode -->
+- **Patch** (optional):
+  ```diff
+  - old line
+  + new line
+  ```
+```
+
+---
+
+## Output Contract
+
+```
+STATUS: DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
+```
+
+- `DONE` — no blockers or majors after strict pass
+- `DONE_WITH_CONCERNS` — one or more blocker or major findings
+- `NEEDS_CONTEXT` — cannot assess intent without context doc; state what is missing
+- `BLOCKED` — cannot access diff or findings input; state reason
+
+```markdown
+# Strict Review Report
+
+## Verdict: APPROVE | APPROVE_WITH_SUGGESTIONS | REQUEST_CHANGES
+
+## Summary
+<2-4 sentences: overall engineering quality, key concerns, whether findings from other
+reviewers were understated.>
+
+## Review Scope
+- Branch: `<BRANCH>`
+- Parent ref: `<PARENT>`
+- Merge-base: `<BASE_SHA>`
+- Mode: `<meta | standalone>`
+- Scope mode: `<default-with-uncommitted | explicit-hash-range>`
+- Input findings ingested: <N> (meta mode only)
+
+## Stats
+- blocker: N (N elevated)
+- major: N (N elevated, N new)
+- minor: N
+- info: N
+
+## Blockers (must fix before merge)
+<[F-NNN] findings>
+
+## Major Issues
+<[F-NNN] findings — mark elevated ones clearly>
+
+## Minor & Info
+<[F-NNN] findings>
+
+## Not Today
+> **Not today:** [architectural shortcut 1]
+> **Not today:** [architectural shortcut 2]
+
+## Positive Notes
+<Optional. What held up to strict scrutiny.>
+```
+
+---
+
+## Scope Boundaries
+
+| Concern | This skill | Use instead |
+|---------|------------|-------------|
+| Elevating/validating findings from domain reviewers | YES | — |
+| Strict engineering commentary on diff | YES | — |
+| `setTimeout`, `any`, ducktape, SSOT violations | YES | — |
+| MobX conventions (inter-store access, disposal) | YES | — |
+| First-pass logic review | NO | `review-logic` |
+| First-pass frontend patterns | NO | `review-frontend` |
+| First-pass backend patterns | NO | `review-backend` |
+| Large out-of-scope refactors | NO | file separately |
+
+---
+
+## Job Context Awareness
+
+When dispatched by `job-orchestrator` or called with an explicit context path, the prompt MAY include:
+
+```
+JOB_NAME:     <job-name>
+CONTEXT_PATH: <JOBS_ROOT>/<job-name>/ai/context.md
+```
+
+If provided and the file exists, read the context document **before** applying strict principles.
+Use it to understand:
+- Intentional architectural decisions (do not flag agreed-upon patterns as shortcuts)
+- Which libraries, patterns, and conventions were explicitly chosen
+- Acceptance criteria (to detect spec gaps if running standalone)
+
+If absent, proceed normally — context is optional and non-blocking.
+
+---
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|----------------|-----------------|
+| "The other reviewer already caught it, I don't need to address it" | Meta mode means you own the final assessment; weak findings stay weak unless you act |
+| "setTimeout(0) is a common pattern" | Common patterns can still be wrong; demand the root cause fix |
+| "I'll add a 'Not Today' for everything I disagree with" | Not Today is for real shortcuts, not personal preference; ≤3 items |
+| "Elevating to blocker feels harsh" | Harsh is blocking a production incident; elevate when the evidence supports it |
+| "The `any` is in a test file" | Type safety in tests matters; typed mocks prevent false-green tests |