openqodex 0.1.0

package/lenses/upsert-state-column.md

@@ -0,0 +1,57 @@
+---
+name: upsert-state-column
+description: Upsert / on-conflict writes that clobber workflow-state columns
+triggers:
+  files:
+    - "*.ts"
+    - "*.tsx"
+    - "*.js"
+    - "*.jsx"
+    - "*.mjs"
+    - "*.cjs"
+    - "*.py"
+    - "*.go"
+    - "*.rb"
+    - "*.java"
+    - "*.kt"
+    - "*.cs"
+    - "*.php"
+    - "*.sql"
+    - "**/*.ts"
+    - "**/*.tsx"
+    - "**/*.js"
+    - "**/*.jsx"
+    - "**/*.mjs"
+    - "**/*.cjs"
+    - "**/*.py"
+    - "**/*.go"
+    - "**/*.rb"
+    - "**/*.java"
+    - "**/*.kt"
+    - "**/*.cs"
+    - "**/*.php"
+    - "**/*.sql"
+  hunk_regex: "\\b(upsert|on[\\s_-]?conflict|onconflict|merge\\s+into)\\b"
+confidence_floor: 0.7
+---
+
+An upsert / on-conflict insert that writes a literal value to a
+state-bearing column (stage, status, state, tier, role, phase, plan)
+will overwrite that column on every matching row, including rows that
+have already advanced past that state. On CRM, billing, fulfillment,
+and auth flows this silently regresses the workflow on the next
+webhook or replay.
+
+Flag as a bug **unless** the write is explicitly guarded:
+
+- `ignoreDuplicates: true` / `ON CONFLICT DO NOTHING`
+- an `updateColumns` (drizzle / kysely / supabase) or `DO UPDATE SET`
+  list that **omits** the state column
+- a `WHERE` / `.eq()` predicate on the upsert that constrains by the
+  current value of the state column
+
+Confidence rule still applies: if you cannot tell from the diff
+whether such a guard exists upstream (helper wrapping the upsert,
+trigger on the table, generated-column default), read the surrounding
+code before raising. Drop the finding when the guard
+is plausible and you can't disprove it.

package/lenses/url-not-encoded-for-user-id.md

@@ -0,0 +1,78 @@
+---
+name: url-not-encoded-for-user-id
+description: URL string built by concatenating a user-supplied identifier without encodeURIComponent
+triggers:
+  files:
+    - "*.ts"
+    - "*.tsx"
+    - "*.js"
+    - "*.jsx"
+    - "*.mjs"
+    - "*.cjs"
+    - "**/*.ts"
+    - "**/*.tsx"
+    - "**/*.js"
+    - "**/*.jsx"
+    - "**/*.mjs"
+    - "**/*.cjs"
+  hunk_regex: "https?://|`/[a-z]|/api/|/users?/|/teams?/|/projects?/|\\?[a-z_]+="
+security: true
+confidence_floor: 0.8
+---
+
+A URL is built by string concatenation or template-string
+interpolation of an identifier (uuid, slug, user id, email,
+search query, encoded token) without `encodeURIComponent`. When
+the substituted value contains a reserved character (`#`, `?`,
+`&`, `/`, `=`, `+`, space) the URL silently breaks: the trailing
+path becomes a fragment, query params merge into the previous one,
+or the slash splits the route. Worst case it's a one-character
+SSRF if the substituted value can contain `@` (rewrites the host)
+or a `..` segment that escapes the intended subdirectory.
+
+Flag when a URL string in this diff:
+- is built with `+ var`, `${var}`, or `concat(var)` where `var` is
+  named like an identifier (`id`, `userId`, `slug`, `email`,
+  `token`, `name`, `query`, `searchTerm`, `*_id`, `*_uuid`),
+- AND the substitution happens in a path segment or query value
+  position,
+- AND there is no `encodeURIComponent(var)` / `encodeURI(var)` /
+  `new URL(...).searchParams.set(...)` / equivalent encode call
+  on the way in,
+- AND `var` is not a hardcoded constant from earlier in the
+  function.
+
+Examples that should fire:
+- `` `${baseUrl}/users/${userId}` `` where userId can hold `+`
+- `` `https://analytics.example.com/people/${authUserId}` ``
+- `fetch("/api/teams/" + slug + "/members")`
+- `` `?q=${searchTerm}` ``
+
+Suppress when:
+- the substitution is wrapped in `encodeURIComponent(...)`,
+- the URL is built with `url.searchParams.set(name, value)`;
+  the URLSearchParams encoder handles reserved chars (including
+  `/`, `=`, `&`) in the value,
+- the value is encoded per-segment first and only then assembled
+  into a pathname (e.g. `url.pathname = "/users/" +
+  encodeURIComponent(userId)`),
+- the substituted value is a literal / module-level constant /
+  enum member (compile-time-known safe),
+- the substituted value is already known to be opaque-encoded
+  upstream (e.g. JWT, base64url); note the encoding source if
+  the diff makes that visible.
+
+DO NOT suppress on `new URL(...)` alone. The URL constructor
+parses; it does NOT encode reserved characters inside a
+pre-assembled path. Likewise `url.pathname = "/users/" + userId`
+does NOT encode `/` (or other reserved chars) within the path
+segment: if the substituted `userId` contains a `/`, the route
+still splits exactly as the lens is meant to catch. The
+URL-class suppression only applies when the encoding happens at
+the per-segment / per-param boundary, not at pathname assignment
+time.
+
+Severity: `minor` for display URLs that just break visually,
+`major` when the unencoded value reaches the network layer and
+could redirect a request to a different host or path (the `..`
+and `@` escape cases).

package/lenses/use-state-default-not-functional.md

@@ -0,0 +1,30 @@
+---
+name: use-state-default-not-functional
+description: useState initialized with an expensive computation that re-runs every render
+triggers:
+  files:
+    - "*.tsx"
+    - "*.jsx"
+    - "**/*.tsx"
+    - "**/*.jsx"
+  hunk_regex: "useState\\s*\\("
+confidence_floor: 0.7
+---
+
+`useState(expensiveCompute())` invokes `expensiveCompute()` on
+EVERY render: React only uses the result on the first render but
+the call still happens. For pure functions this is wasted CPU; for
+calls with side effects (analytics fire, localStorage read,
+expensive parse) it's a real bug.
+
+Flag when `useState(expr)` initializer is:
+- a function call that's NOT a cheap literal / variable read
+- a `JSON.parse` / `localStorage.getItem` / `sessionStorage.getItem`
+  / a sync filesystem call / a heavy array build
+
+Suppress when:
+- the initializer is the lazy form `useState(() => expensiveCompute())`
+  (React only calls the function on mount)
+- the initializer is a literal, a stable variable, or a cheap
+  primitive lookup
+- the function is memoized externally and cheap on subsequent calls

package/package.json

@@ -0,0 +1,57 @@
+{
+  "name": "openqodex",
+  "version": "0.1.0",
+  "description": "Open source code review that runs inside your coding agent, before you push.",
+  "type": "module",
+  "license": "Apache-2.0",
+  "homepage": "https://github.com/openqodex/openqodex#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/openqodex/openqodex.git",
+    "directory": "packages/cli"
+  },
+  "bugs": {
+    "url": "https://github.com/openqodex/openqodex/issues"
+  },
+  "keywords": [
+    "code-review",
+    "static-analysis",
+    "claude-code",
+    "cursor",
+    "codex",
+    "cline",
+    "pre-commit"
+  ],
+  "engines": {
+    "node": ">=22"
+  },
+  "bin": {
+    "openqodex": "./dist/bin.js"
+  },
+  "files": [
+    "dist",
+    "lenses",
+    "docs",
+    "skills",
+    "templates",
+    "demo",
+    "toolchain.json",
+    "README.md",
+    "LICENSE",
+    "NOTICE"
+  ],
+  "dependencies": {},
+  "devDependencies": {
+    "@clack/prompts": "^1.8.1",
+    "commander": "^14.0.3",
+    "picocolors": "^1.1.1",
+    "yaml": "^2.9.1",
+    "zod": "^4.6.5",
+    "@openqodex/core": "0.1.0",
+    "@openqodex/scanners": "0.1.0"
+  },
+  "scripts": {
+    "build": "tsup",
+    "typecheck": "tsc -p tsconfig.json --noEmit"
+  }
+}

package/skills/openqodex/SKILL.md

@@ -0,0 +1,141 @@
+---
+name: openqodex
+description: Review the current code change before it is pushed. Runs the security and lint scanners that fit the changed files, then guides you through verifying their findings and reviewing the change yourself, and writes a report. Use before every git push, when asked to review changes, and when a push was blocked or warned by OpenQodex.
+---
+
+# OpenQodex: review the change before it is pushed
+
+OpenQodex runs deterministic scanners (gitleaks, semgrep, bandit, hadolint, shellcheck, actionlint, osv-scanner and others) on the files that changed, keeps only what they report on changed lines, and hands you a review brief. You review the change with your own tools and model, write your findings to a file in a fixed shape, and OpenQodex checks that file without a model and writes the report. No key and no account are needed. OpenQodex sends no code anywhere. One scanner goes online: when the change touches a dependency file, osv-scanner asks osv.dev about the names and versions of the dependencies; `--offline` on the review command skips that lookup. A custom scanner the developer approved does whatever its own command does.
+
+## When to run
+
+- Before any `git push`.
+- When the developer asks you to review their changes.
+- When a push was blocked or warned by the OpenQodex hook.
+- After fixing findings, to check the change again.
+
+## Procedure
+
+1. From the repository, run:
+
+   ```
+   npx -y openqodex@0.1.0 review --agent
+   ```
+
+   It works out the change (the commits not yet pushed plus everything uncommitted, untracked files included), runs the scanners and prints the brief. Read the whole brief before doing anything else.
+
+2. Verify each scanner candidate against the code. Every candidate has an id (`c1`, `c2`, ...) and a token like `[semgrep:python.lang.security.audit.formatted-sql-query]`. Open the file at the line and decide:
+   - real: raise it as a finding with `source` set to the token and `candidate` set to the id;
+   - not real (a test fixture, dead code, a pattern the code already guards): put it under `dropped` with a one-line reason.
+
+   Several candidates often describe one problem (two scanners, or two rules of one scanner, on the same line). Raise one of them and drop the others with the reason `duplicate of c<id>`.
+
+   Every candidate must end up in one of the two. A candidate you leave out is reported as "Not reviewed by the agent" and counts toward the verdict at its scanner severity.
+
+3. Weigh each pattern listed under "Patterns to weigh". Each one describes a kind of bug that changes like this one often carry. Check the changed lines against it. When a pattern leads you to a finding, set `source` to `lens:<name>`.
+
+4. Review the change yourself. Use your own tools to read the callers and the tests of every function the change touches. Look for wrong behaviour, missing checks, broken edge cases and changed behaviour with no test. Findings from your own reading have `source: null`.
+
+5. Write the findings to the exact path the brief names (it ends in `agent-findings.json`), in the shape below.
+
+6. Run:
+
+   ```
+   npx -y openqodex@0.1.0 review --finalize
+   ```
+
+   If it exits with code 2 and names a wrong field or a citation that does not match, fix what it names in your findings file and run finalize again. If it says the change moved or the config changed, run step 1 again and review from the new brief: the review must describe the change and the settings as they are now. Never change the developer's code or config to make finalize pass.
+
+7. Tell the developer the verdict, the counts by severity, the most serious findings in one line each, and the path of `report.md`. Do not paste the whole report.
+
+## The finding shape
+
+```json
+{
+  "version": 1,
+  "change_id": "3f9a1c0b2d4e",
+  "summary": "Adds a search endpoint and a deploy script.",
+  "findings": [
+    {
+      "severity": "critical",
+      "category": "security",
+      "confidence": 0.9,
+      "file_path": "app/search.py",
+      "line_number": 14,
+      "line_end": 14,
+      "title": "SQL injection in item search",
+      "description": "The query is built with an f-string from request.args, so a caller controls the SQL. Pass the value as a query parameter.",
+      "suggested_change": "cur.execute(\"SELECT * FROM items WHERE name = ?\", (q,))",
+      "source": "semgrep:python.lang.security.audit.formatted-sql-query",
+      "candidate": "c2"
+    }
+  ],
+  "dropped": [
+    { "candidate": "c5", "reason": "test fixture, not a real key" }
+  ]
+}
+```
+
+- `change_id`: copy it from the brief.
+- `summary`: what the change does, in one or two sentences. Not the findings.
+- `file_path`: relative to the repository root. `line_number` and `line_end` point at the code line that holds the problem, never at a comment or a blank line, and at an import only when the import itself is the problem. `line_end` is optional and defaults to `line_number`.
+- `title`: a short noun phrase naming the problem. No line numbers, no quoted code.
+- `description`: one to three sentences: what is wrong, why it matters, the fix.
+- `suggested_change`: the replacement text for the cited lines when the fix fits in a few lines, matching the indentation. Otherwise `null`, and explain the fix in `description`.
+- `source`: `null` for your own finding, the candidate's token when raising a candidate, or `lens:<name>` when a listed pattern led to it.
+- `candidate`: the candidate id when raising one, else leave it out. The id and the token must belong to the same candidate.
+- `confidence`: from 0 to 1, how sure you are that the problem is real, based on what you read.
+
+Severity says how much harm the problem does, not how sure you are:
+
+- `critical`: data loss, a security breach, a crash on a common path, broken authentication.
+- `major`: wrong behaviour under realistic conditions, a performance regression, a broken edge case someone would be paged for.
+- `minor`: a real bug that is unlikely to show in practice.
+- `nitpick`: style, naming or a convention preference.
+- `info`: worth knowing, no action needed.
+
+Category says what kind of problem it is:
+
+- `bug`: the code does the wrong thing.
+- `security`: the code can be abused, or leaks something it should not.
+- `performance`: the code is slower or uses more resources than it needs to.
+- `maintainability`: the code works but is hard to change safely (missing test, duplicated logic, unclear structure).
+- `style`: formatting, naming and conventions.
+
+## Rules
+
+- Raise only what you verified in the code. A guess with nothing in the code to point at is not a finding.
+- A finding with confidence under 0.7 is not raised. Finalize drops it and lists it as low confidence.
+- Every scanner candidate is either raised or listed under `dropped` with a reason.
+- Never edit code during the review. Review first, report, then fix only what the developer asks you to fix.
+- Never run `openqodex trust` without asking the developer first. It approves a custom scanner, which is a command that runs on their machine.
+- Never set `OPENQODEX_SKIP`. It is the developer's switch, not yours.
+- When the verdict is `blocked`, do not push. Show the developer the findings; push only if they say so after seeing them.
+- An empty findings list is a valid review. Do not pad it.
+
+## Reading the report
+
+- The report is in `.openqodex/reviews/<time>-<id>/` in the repository: `report.md` to read, `report.json` and `report.sarif` for tools. `.openqodex/latest.json` points at the newest one. The folder ignores itself in git, so it never shows in `git status`.
+- The verdict is `passed` (with or without warnings) or `blocked`. It is `blocked` only when the repository's `.openqodex.yaml` sets `block_on_severity` and a finding is at or above it. With no config, OpenQodex warns and never blocks.
+- "Outside the changed lines" lists findings on lines the developer did not change. They are shown but never count toward the verdict.
+- The coverage list says, for each scanner, whether it ran. A scanner that did not run has a one-line reason:
+  - `no matching files`: nothing in the change is the kind of file it reads.
+  - `installing`: it is being downloaded for the first time; it is included from the next run. Say so to the developer rather than waiting.
+  - `not installed`: it could not be installed here; the reason says why.
+  - `needs Ruby 2.7+` or `needs Go`: brakeman and rubocop need Ruby, golangci-lint needs Go. OpenQodex does not install language runtimes. If the developer wants those scanners, they install Ruby or Go the usual way for their system (for example `brew install ruby go` on a Mac) and run the review again.
+  - `untrusted`: a custom scanner from `.openqodex.yaml` that the developer has not approved. Tell the developer; approving it is their decision (`npx -y openqodex@0.1.0 trust`).
+  - `failed`: the scanner ran and broke; the reason has its error. A scanner problem never changes the exit code.
+
+## Inside a sandbox
+
+Some agents run commands in a sandbox that cannot reach the network or write outside the project. There the first run cannot download the scanners, and each scanner reports why it was not included. The review still runs with whatever is available. Tell the developer to run this once in their own terminal, outside the agent:
+
+```
+npx -y openqodex@0.1.0 doctor --install
+```
+
+It downloads every scanner that fits the machine into `~/.openqodex/tools/`. After that, reviews inside the sandbox include them.
+
+## More
+
+`npx -y openqodex@0.1.0 guide` prints this guide. `npx -y openqodex@0.1.0 guide <topic>` prints a page of the docs, offline: `quickstart`, `config`, `scanners`, `custom-scanners`, `security`, `agents`, `cli`.

package/templates/README.md

@@ -0,0 +1,67 @@
+# Templates that `openqodex init` writes
+
+Each file here is copied or merged by `openqodex init`. Two placeholders are filled at install time and no others exist:
+
+- `{{VERSION}}`: the version of the running `openqodex` package.
+- `{{LAUNCHER}}`: the absolute path of the launcher, `~/.openqodex/bin/openqodex` expanded.
+
+The skill itself is not a template: `init` copies `skills/openqodex/SKILL.md` from the package unchanged.
+
+User scope is the default. Project scope (`--project`) writes into the repository for a team to commit. A repository file written in user scope is added to `.git/info/exclude` so `git status` does not change.
+
+Every path below was read from the source named beside it on 2026-10-01. Anything marked "assumption, untested" was not confirmed and must not be written by `init` as if it were.
+
+## Claude Code
+
+| What | Template | User scope | Project scope |
+|---|---|---|---|
+| Skill | `skills/openqodex/SKILL.md` | `~/.claude/skills/openqodex/SKILL.md` | `.claude/skills/openqodex/SKILL.md` |
+| Push gate hook | `claude-code/settings-hook.json`, merged | `~/.claude/settings.json` | `.claude/settings.json` |
+
+- Settings paths: https://code.claude.com/docs/en/hooks, section "Hook locations".
+- Skill paths: the `skills` CLI agent table (github.com/vercel-labs/skills, README, "Supported agents"), and the same hooks page, which names `~/.claude/skills/` and `.claude/skills/`.
+- The hook: `matcher: "Bash"` with `if: "Bash(git push*)"` on the handler. The `if` field uses permission-rule syntax and is checked against each subcommand (same hooks page, "Bash if matching"). The page also says a pattern longer than the command name runs the hook anyway when the command holds `$()`, backticks or `$VAR`, so `hook check` must itself confirm the command is a push.
+- Merge rule: append the one entry under `hooks.PreToolUse`, keep every other key, do nothing when an entry with the same command already exists.
+
+## Codex CLI
+
+| What | Template | User scope | Project scope |
+|---|---|---|---|
+| Skill | `skills/openqodex/SKILL.md` | see the note below | `.agents/skills/openqodex/SKILL.md` |
+| Instructions | `codex/AGENTS-section.md`, between its markers | not written | `AGENTS.md` (replace the text between the markers, or append) |
+| Push gate hook | `codex/hooks.json`, merged | `~/.codex/hooks.json` | `.codex/hooks.json` |
+
+- Hook file paths, schema and output: https://learn.chatgpt.com/docs/hooks (where https://developers.openai.com/codex/hooks redirects). `codex features list` on Codex CLI 0.160.0 shows `hooks` as stable and on.
+- Codex hooks have no `if` field: the matcher is a regular expression on the tool name only. The hook therefore runs before every shell command, and `hook check` must abstain at once, printing nothing, when the command is not a `git push`.
+- Codex runs a new user or project hook only after the developer reviews and trusts it with `/hooks` inside Codex; project hooks load only in a trusted project. `init` must print that step.
+- Codex's PreToolUse output supports `permissionDecision` deny, `additionalContext` and `systemMessage`; `ask` is parsed but not implemented. Exit code 2 with the reason on stderr also denies.
+- Skill path conflict: the `skills` CLI table puts the Codex user skill in `~/.codex/skills/`; the Codex docs (https://learn.chatgpt.com/docs/build-skills) list `$HOME/.agents/skills` and repository `.agents/skills`, and do not list `~/.codex/skills/`. Write `~/.agents/skills/openqodex/SKILL.md`, which the Codex docs name. That Codex 0.160.0 still reads `~/.codex/skills/`: assumption, untested.
+
+## Cursor
+
+| What | Template | User scope | Project scope |
+|---|---|---|---|
+| Skill | `skills/openqodex/SKILL.md` | `~/.cursor/skills/openqodex/SKILL.md` | `.agents/skills/openqodex/SKILL.md` |
+| Rule | `cursor/openqodex.mdc` | `.cursor/rules/openqodex.mdc` in the repository, excluded from git | `.cursor/rules/openqodex.mdc` |
+
+- Rule location and frontmatter: https://cursor.com/docs/context/rules. Project rules are `.mdc` files in `.cursor/rules`; the fields are `description`, `globs` and `alwaysApply`; `alwaysApply: true` makes the rule apply to every chat. User rules live in Cursor's settings, not on disk, so there is no user-level rule file.
+- Skill paths: the `skills` CLI table, and https://cursor.com/docs/context/skills, which lists `.agents/skills/`, `.cursor/skills/`, `~/.agents/skills/` and `~/.cursor/skills/` (and the Claude and Codex folders for compatibility).
+- Cursor hooks (`.cursor/hooks.json`) were not checked: no Cursor hook is written. Assumption, untested, that a rule alone is enough for Cursor to review before pushing.
+
+## Cline
+
+| What | Template | User scope | Project scope |
+|---|---|---|---|
+| Skill | `skills/openqodex/SKILL.md` | `~/.cline/skills/openqodex/SKILL.md` | `.cline/skills/openqodex/SKILL.md` |
+| Rule | `cline/openqodex.md` | `~/Documents/Cline/Rules/openqodex.md` | `.clinerules/openqodex.md` |
+
+- Rule paths: https://docs.cline.bot/features/cline-rules. Cline reads every file in `.clinerules/` (or `.cline/rules/`) at the project root; global rules are in `~/Documents/Cline/Rules` on macOS and Linux (`Documents\Cline\Rules` on Windows), with `~/.cline/rules` and `~/Cline/Rules` also searched. A rule with no frontmatter always applies. The plan's default (rule in the repository, excluded from git) also works; the global rule folder avoids touching the repository.
+- Skill path conflict: the `skills` CLI table puts Cline skills in `.agents/skills/` and `~/.agents/skills/`; Cline's docs (https://docs.cline.bot/features/skills) list `.cline/skills/`, `.clinerules/skills/`, `.claude/skills/` and `~/.cline/skills/`, and not `.agents/skills/`. Write the path Cline's docs name. That Cline reads `.agents/skills/`: assumption, untested.
+
+## Not written on Day 0
+
+No MCP server configuration is written for any agent.
+
+## Placeholders
+
+`{{VERSION}}` is the running package version. `{{LAUNCHER}}` is the absolute launcher path, and `init` must substitute it already quoted for a POSIX shell (single quotes, with any single quote inside escaped), because a home folder can contain a space and the hook command is run through a shell.

package/templates/claude-code/settings-hook.json

@@ -0,0 +1,16 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "if": "Bash(git push*)",
+            "command": "{{LAUNCHER}} hook check"
+          }
+        ]
+      }
+    ]
+  }
+}

package/templates/cline/openqodex.md

@@ -0,0 +1,9 @@
+# Review before push with OpenQodex
+
+Before any `git push`, and whenever you are asked to review the changes, review the change with OpenQodex:
+
+1. Run `npx -y openqodex@{{VERSION}} review --agent` from the repository and read the brief it prints.
+2. Follow the openqodex skill for the rest of the review: verify each scanner candidate, write your findings to the path the brief names, then run `npx -y openqodex@{{VERSION}} review --finalize`. If the skill is not loaded, run `npx -y openqodex@{{VERSION}} guide` to print it.
+3. Show the developer the verdict and the report path. When the verdict is `blocked`, do not push unless the developer says so after seeing the findings.
+
+Never edit code during the review, never run `openqodex trust` without asking the developer, and never set `OPENQODEX_SKIP`.

package/templates/codex/AGENTS-section.md

@@ -0,0 +1,8 @@
+<!-- openqodex:start -->
+## Review before push (OpenQodex)
+OpenQodex is open source code review that runs scanners on the change and guides your own review before it is pushed.
+Before any `git push`, and when asked to review the changes, run `npx -y openqodex@{{VERSION}} review --agent` and follow the openqodex skill (`npx -y openqodex@{{VERSION}} guide` prints it).
+Write findings to the path the brief names, run `npx -y openqodex@{{VERSION}} review --finalize`, then show the developer the verdict and the report in `.openqodex/reviews/`.
+If scanners cannot install inside the sandbox, ask the developer to run `npx openqodex doctor --install` once in their own terminal.
+Do not push when the verdict is `blocked` unless the developer says so after seeing the findings.
+<!-- openqodex:end -->

package/templates/codex/hooks.json

@@ -0,0 +1,16 @@
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "^Bash$",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "{{LAUNCHER}} hook check",
+            "statusMessage": "OpenQodex: checking for a review before push"
+          }
+        ]
+      }
+    ]
+  }
+}

package/templates/cursor/openqodex.mdc

@@ -0,0 +1,15 @@
+---
+description: Review the change with OpenQodex before any git push
+globs:
+alwaysApply: true
+---
+
+# Review before push with OpenQodex
+
+Before any `git push`, and whenever you are asked to review the changes, review the change with OpenQodex:
+
+1. Run `npx -y openqodex@{{VERSION}} review --agent` from the repository and read the brief it prints.
+2. Follow the openqodex skill for the rest of the review: verify each scanner candidate, write your findings to the path the brief names, then run `npx -y openqodex@{{VERSION}} review --finalize`. If the skill is not loaded, run `npx -y openqodex@{{VERSION}} guide` to print it.
+3. Show the developer the verdict and the report path. When the verdict is `blocked`, do not push unless the developer says so after seeing the findings.
+
+Never edit code during the review, never run `openqodex trust` without asking the developer, and never set `OPENQODEX_SKIP`.