---
name: review
description: Use this skill when reviewing code, tests, or design decisions in the odoo_ocr project before approving or committing changes.
---

# Review Skill

Use this skill whenever you are asked to review code, tests, architecture, or any proposed change in the `odoo_ocr` project.

## Required Review Checklist

Before approving any change, verify the following. If any item fails, flag it and request a fix.

### 1. Project Rules Compliance

- [ ] New code lives under `src/odoo_ocr/`.
- [ ] Pydantic schemas are updated or added before business logic changes.
- [ ] Type hints are present; `mypy --strict` passes or only has justified exceptions.
- [ ] No hardcoded secrets, endpoints, or model names outside of `config.py` / settings.
- [ ] Logging is used; model calls log latency and token usage.

### 2. Model Client Rules

- [ ] Model calls go through `BaseVLMClient` (Ollama or llama.cpp).
- [ ] Extraction/review prompts force JSON output; no regex scraping of prose.
- [ ] Retries use exponential backoff for transient failures.
- [ ] Cache keys include prompt + image hash + model + temperature.

### 3. Pipeline Rules

- [ ] Every invoice must pass through the **review stage** before XML generation.
- [ ] `ReviewResult` includes `valid`, `confidence`, and `issues`.
- [ ] Confidence thresholds from `config.yaml` are respected:
  - `>= 0.90`: generate final XML.
  - `0.75–0.89`: generate XML with human-review flag.
  - `< 0.75`: do not generate final XML; emit sidecar JSON only.
- [ ] The original image is passed to the review VLM alongside the extracted JSON.

### 4. XML Rules

- [ ] Generated XML is parseable by `lxml`.
- [ ] Required Odoo records are present: `res.partner`, `account.move`, `account.move.line`.
- [ ] Tax records are deterministic by rate/type.
- [ ] External IDs are sanitized and stable.

### 5. Test Rules

- [ ] New modules have tests under `tests/`.
- [ ] Model calls are mocked in unit tests (use `FakeVLMClient` from `conftest.py`).
- [ ] `pytest`, `ruff check src tests`, and `mypy src/odoo_ocr --strict` all pass.

## Review Output Format

When asked to review, produce a concise report with:

1. **Summary**: what changed and whether it looks correct.
2. **Checklist results**: pass/fail per section above.
3. **Required fixes**: blockers that must be addressed.
4. **Suggestions**: non-blocking improvements.
5. **Verdict**: `APPROVE`, `APPROVE WITH NITS`, or `REQUEST CHANGES`.

If the user did not ask a specific question, default to reviewing the most recent changes in the working tree or the file(s) they mentioned.