📐 Review Prompt Extension

The Kodo tool supports the ability to extend the built-in prompt for review. This can be done in the following way

📁 1. The CONSTITUTION.md file

You can create a .review folder if it does not exist and add a CONSTITUTION.md file to this folder, which will contain part of the prompt that will be read by the tool during execution.

my-project/
├── .review/                  ← Create this folder
│   └── CONSTITUTION.md       ← Your custom rules
├── src/
└── ...

The .review folder must be placed in the root of your repository.

✏️ 1.1. Examples of the CONSTITUTION.md file

Example 1: Tell the reviewer what your linter already handles

Use this to stop the AI from commenting on formatting, import order, and other things already enforced by your tooling.

## Automated Tooling (Never Comment On These)

These are enforced automatically on every commit — mentioning them is noise:

- Formatting, indentation, trailing whitespace → Prettier
- Unused imports, import order → ESLint (import plugin)
- Semicolons, quote style → Prettier
- `console.log` removal → ESLint (no-console rule)
- Unused variables → TypeScript + ESLint

**If you would have flagged one of the above, stay silent.**
Only review what static analysis cannot catch: logic, intent, design decisions.

Example 2: Give the reviewer context about your project

Use this to prevent irrelevant suggestions and to make the reviewer aware of your critical invariants.

## Project Context

App: B2B SaaS dashboard. Multi-tenant. Each request is scoped to a `tenantId`.

### Patterns already in place — do not suggest alternatives
- Data fetching → React Query. Do not suggest `useEffect` + `fetch`, SWR, or Axios.
- Forms → React Hook Form + Zod. Do not suggest Formik or manual validation.
- Global errors → caught in `ErrorBoundary` at root. Local boundaries are intentional only when present.
- Auth → handled in middleware. Do not flag missing auth checks inside route handlers.
- `/lib/api.ts` is our fetch wrapper — raw `fetch()` outside this file is always a bug.

### What to always flag
- Any query or filter that does not include `tenantId` — this is a data leak.
- Any hardcoded string that looks like a user-facing label (should use i18n keys).
- Direct state mutation (we use Immer, but only inside `produce()` blocks).

Example 3: Control how many comments the reviewer leaves

Use this to reduce noise and make sure real issues are always surfaced first.

## Comment Rules

### Severity labels — use on every comment
🔴 BLOCKER  — wrong behavior, data leak, broken edge case. List these first.
🟡 WARNING  — will cause problems soon, but not an immediate break.
🔵 SUGGEST  — optional, one sentence, only if genuinely useful.

### Noise reduction rules
- If a PR is under 50 lines: max 5 comments. Cut suggestions first.
- Do NOT comment on correct code to show you read it.
- Do NOT suggest extracting a function unless the current one exceeds 40 lines.
- Do NOT flag missing comments/JSDoc unless the function has non-obvious behavior.
- One comment per issue — do not repeat the same point in different locations.

### Start every review with one of these
- "🔴 X blockers found — must fix before merge." (then list them)
- "✅ No blockers. X warnings and Y suggestions below."

💡 1.2. Recommendations for the CONSTITUTION.md file

There are some recommendations for creating content for this file:

Do not provide contradictory instructions and information.
Provide a detailed description of any modules and rules.
Do not make this file large, as it will be part of the prompt, which has a limited context.

📐 Review Prompt Extension

📁 1. The CONSTITUTION.md file

✏️ 1.1. Examples of the CONSTITUTION.md file

💡 1.2. Recommendations for the CONSTITUTION.md file

🤖 Kodo AI Reviewer

📚 Gitea

👩‍💻 Developer

🧑‍🔧 Tech Lead

📚 Bitbucket

👩‍💻 Developer

🧑‍🔧 Tech Lead

📚 Local Kodo