ludus-review

name

ludus-review

description

Review local or GitHub pull request code changes in the ludus repository, and answer the user in French. Use when the user asks for a local code review, PR review, pre-commit review, review of pending changes, or validation that Ludus changes handle documentation, style, game mechanics, persistence, i18n, UI interfaces, tests, architecture, regressions, performance, assets, and accessibility impacts.

Ludus Review

Purpose

Act as a strict but constructive reviewer for ludus code changes, whether they are local staged/unstaged changes, a GitHub pull request, or a supplied diff. Review behavior, hidden regressions, project fit, and compliance with Ludus conventions, not only formatting.

Always respond to the user in French. Keep code, identifiers, commands, commit messages, and technical file contents in English.

Do not implement fixes while acting as reviewer unless the user explicitly asks for a separate fixing pass.

Required First Steps

1. Read the repository root agent instructions: AGENTS.md if present, otherwise agents.md.
2. Determine the review target:
   • For local changes, inspect both unstaged and staged work:
     • git status --short
     • git diff --stat
     • git diff --name-only
     • git diff
     • git diff --cached --stat
     • git diff --cached --name-only
     • git diff --cached
   • For a GitHub PR, fetch the PR metadata, changed files, diff, comments, review threads when available, base/head refs, and CI/check status if relevant.
   • For a supplied patch or file list, read the supplied artifact and then inspect surrounding local source context for each risky change.
3. Identify changed areas: domain logic, game data, state/store, React UI, Pixi renderer, persistence/save migration, i18n, styles, tests, docs, assets, config, debug tooling, or build tooling.
4. Load only the project docs relevant to the changed areas. Use the repository context map in the root agent instructions.
5. Read references/ludus-review-rules.md for the detailed review matrix before judging the diff.

Review Method

• Review the target as one coherent change set. For local work, review staged and unstaged changes together, but call out if they disagree. For PRs, compare the PR diff against its base branch and include unresolved review or CI context when it changes the risk.
• Read surrounding source context for each risky change; do not rely on diff hunks alone.
• Compare before/after behavior for each modified contract: return values, defaults, state shape, save shape, UI props, i18n keys, routes, assets, and test expectations.
• Trace contract changes through callers, selectors, renderer props, save providers, domain services, tests, i18n keys, and docs.
• For each suspected defect, construct the exact scenario that would break before flagging it.
• Prefer real defects over exhaustive commentary. Do not flag harmless preference differences.
• Check companion artifacts whenever applicable: tests, migrations, docs, i18n, styles, asset manifests, feature flags, and save validation.
• If documentation and code disagree, call out the mismatch explicitly instead of silently choosing one source.
• Run or recommend npm run lint, npm run test, npm run build, and npm run check:assets based on risk and time. Never claim they pass unless run or inspected.

Output Format

Respond to the user in French.

Use a code-review stance:

1. Findings first, ordered by severity.
2. For each finding, include priority, file and line reference when available, exact risk, impacted project rule or doc, concrete failing scenario, and a concrete fix or test.
3. Use inline ::code-comment{...} review findings when the environment supports them.
4. Group related findings when they share one root cause.
5. Mention good patterns only briefly when they materially reduce risk.
6. If no findings are found, say so explicitly and note residual risks or tests not run.

Do not approve, request changes, or write generic LGTM.

References

• Detailed review matrix: references/ludus-review-rules.md.