---
name: code-style-review
description: "Use when a caller wants the style/architecture checklist in code-style-patterns.mdc applied by its own name — checks naming, module and file layout, and TypeScript usage patterns against that specific ruleset, over this branch's diff. Narrower than a general style pass, and separate from the correctness-and-security AI review baseline. NOT for: a general style review (review-style) or an architecture review (review-architecture)."
triggers:
  - "code-style-review"
  - "architecture style"
metadata:
  author: "MrCipherSmith"
  version: "1.0.0"
  category: "review"
  compatible_harnesses: "cursor,codex,zed,opencode,claude"
license: "MIT"
---


# Code Style Review

Проводи ревью только изменений текущей ветки от момента отбранчевания от родительской ветки, строго по правилам из `.metaproject/rules/core/code-style-patterns.mdc`.

## Scope

- Если пользователь **не передал commit hash/range**, ревьюируй полный срез от merge-base до текущего рабочего дерева:
  - закоммиченные изменения (`BASE_SHA..HEAD`)
  - локальные незакоммиченные (`staged/unstaged/untracked`)
- Если пользователь **явно передал commit hash/range**, ревьюируй только запрошенный диапазон; незакоммиченные изменения не добавляй, если это отдельно не попросили.
- Не обсуждай легаси вне изменённого скоупа.
- Фидбек должен быть подробным: проблема -> почему это проблема -> где (файл/участок) -> что сделать -> пример исправления.
- Исправления предлагай в виде unified diff-патчей, не вноси изменения в код напрямую.

## Scope Detection

See shared script: `.metaproject/skills/gdskills/shared/git-merge-base.md`

Run the script from that file to determine MERGE_BASE and SCOPE before proceeding with the review.

Собери входные данные:

### A) Режим по умолчанию (без hash/range)

```bash
git status

# Закоммиченная часть ветки
git log --oneline "${BASE_SHA}..HEAD"
git diff --name-status --find-renames "${BASE_SHA}..HEAD"
git diff --find-renames "${BASE_SHA}..HEAD"

# Полный текущий срез от merge-base до рабочего дерева
# включает commit'ы + staged + unstaged
# (untracked смотри через git status / git ls-files)
git diff --name-status --find-renames "${BASE_SHA}"
git diff --find-renames "${BASE_SHA}"
git ls-files --others --exclude-standard
```

### B) Режим с явным hash/range

```bash
git show --stat --name-status --patch <COMMIT_SHA>
git log --oneline <FROM_SHA>..<TO_SHA>
git diff --name-status --find-renames <FROM_SHA>..<TO_SHA>
git diff --find-renames <FROM_SHA>..<TO_SHA>
```

Используй только эти изменения как вход для ревью.

## Review checklist (по `.metaproject/rules/core/code-style-patterns.mdc`)

### TypeScript Strictness
- Запрещён `any` (предлагай `unknown` + type guards / корректные типы).
- Props через `interface`, префикс `I*`.
- Предпочитай `?.` и `??`, избегай `!` (non-null assertion).

### MobX
- В сторах обязателен `makeObservable(this)` в конструкторе.
- Для асинхронных мутаций после `await` - `runInAction`.
- Методы экшенов: `@action.bound`.
- Derived state: `@computed`.
- Для коллекций/списков - `@observable.shallow` (когда применимо).
- Inter-store callbacks (`onChangeX`, `onFireX`, `handleX`, `syncX`) обязаны быть `private`. Публичный `@action.bound` только для методов вызываемых из React-компонентов.

### React Components
- Компоненты, читающие observable, обязаны быть `observer(...)`.
- MVVM: логика и side effects в Store/Service, а не во View.
- Запрещай бизнес-логику в `useEffect` (предлагай store actions/reactions).
- Следи за порядком структуры файла: imports -> interfaces -> component -> helpers.

### Architecture & Layers
- API/IO не во View: в Service/Store.
- Взаимодействие со Store - через actions (без прямых мутаций вне экшенов).

### Anti-patterns severity
- Critical: API во View, missing `observer`, direct store mutation, грубые нарушения MobX async.
- Warnings: `console.log` вместо `AppLogger`, inline object props без memo/const, тяжёлая логика в render, спорные типы, public inter-store callbacks/handlers.

## Output format (обязательный отчёт)

Сформируй отчёт в Markdown строго по шаблону:

```markdown
## Summary
- [1-3 bullets] Что изменилось и общий уровень соответствия стилю

## Scope
- Branch: `<BRANCH>`
- Parent ref: `<PARENT>`
- Merge-base: `<BASE_SHA>`
- Scope mode: `<default-with-uncommitted | explicit-hash-range>`

## Critical issues (must fix)
### [Короткий заголовок проблемы]
- **Rule**: [ссылка/название секции из core/code-style-patterns.mdc]
- **Why**: [объяснение]
- **Where**: `path/to/file.tsx` (строки из diff)
- **Fix**: [что сделать]
- **Proposed patch**:
```diff
[unified diff]
```

## Warnings
... (тот же формат, без "must fix")

## Suggestions
... (тот же формат, improvements без обязательности)

## File-by-file notes
- `path/to/file`: [коротко, только по изменённым участкам]
```

## Rules of engagement

- Привязывай замечания к конкретным изменённым строкам (по diff).
- Если есть несколько вариантов, предлагай один default и короткий альтернативный.
- Не предлагай новые библиотеки без явного запроса.

---

## Scope Boundaries

This skill covers **code style and architecture patterns** — naming, organization, TypeScript usage, pattern compliance per `code-style-patterns.mdc`.

| Concern | This skill | Use instead |
|---------|-----------|-------------|
| Naming conventions, file organization, import order | ✅ YES | — |
| TypeScript patterns, component/hook structure | ✅ YES | — |
| Architecture pattern compliance | ✅ YES | — |
| Logic correctness, type safety deep dives | ❌ NO | `code-ai-review` or `code-learned-review` |
| MobX store internals | ❌ NO | `code-mobx-store-review` |

---

## Job Context Awareness

When dispatched by `job-orchestrator` as part of a job pipeline, the prompt MAY include:

```
JOB_NAME:     <job-name>
CONTEXT_PATH: .metaproject/jobs/<job-name>/ai/context.md
```

If provided and the file exists, read the context document before starting the review. Use it to:
- Understand which libraries and patterns were intentionally chosen for the implementation
- Validate code style against documented project conventions from the context
- Provide more accurate findings by understanding the project's architectural decisions

If the file does not exist or is not provided, proceed normally — context is optional and non-blocking.

---

## Red Flags

This profile is a thin legacy wrapper around `code-style-patterns.mdc`. It
predates the shared finding contract, it does not use the review domain's
severity vocabulary at all, and it is written mostly in Russian — each of those
is a way it misfires, and they are the rows below.

| Rationalization | Why it is wrong |
|----------------|-----------------|
| "A style review was asked for, so I will run this profile." | It is a legacy opt-in profile pinned to one rules file, reached by name or through `review --legacy-profiles`. A general style request belongs to `review-style`, and an architecture request to `review-architecture`; running this instead answers a narrower question than the one that was asked. |
| "The report has a Critical section, so downstream can consume it." | It cannot. `Critical` / `Warnings` / `Suggestions` are headings in a Markdown document, not a severity field: this profile predates `reviewer-finding.schema.json` and emits free prose with no machine-readable finding. Hand it to a person, never to `keryx review ingest`. |
| "The instructions are in Russian, so the report should be." | The language is an artefact of when this file was written. Write the report in the language the requester used. |
| "`public` reads more clearly than leaving the modifier off." | The project's ESLint configuration forbids the keyword outright, at error level. That is a build failure, not a matter of taste, and a reviewer arguing the taste is arguing with a gate that already decided. |
| "This component does not look like it reads observables, so the wrapper is optional." | Check what it reads through props and through the store getters it calls. Missing `observer` is rated critical in the checklist above because the failure is silent: the component simply stops updating. |
| "The `any` is temporary — the author will type it properly later." | Nothing records that intent and nothing revisits it. Rate the code in the diff, and propose `unknown` plus a type guard as the concrete fix. |
| "While reading for style I found a real bug, so I will report it here." | This report has nowhere to carry it and the requester is not reading it for that. Route it to `code-ai-review` (or `review-logic`) and say in one line that you did. |

---

## Verification

Report done only once all of these hold:

- The requester asked for this profile by name, or through
  `review --legacy-profiles`. A style or architecture request that names no
  profile belongs to `review-style` or `review-architecture`.
- The scope block carries the real branch, parent ref, merge-base and scope mode —
  not the template placeholders.
- Every entry carries Rule (the section of `code-style-patterns.mdc` it rests on),
  Why, Where (path plus the lines from the diff) and Fix, with a minimal unified
  diff rather than an edit applied to the tree.
- Every entry is anchored to a line the branch slice actually changed; legacy code
  outside that slice is not discussed.
- Entries are sorted into this document's own Critical / Warnings / Suggestions
  sections, and are not presented as a severity any other reviewer or tool
  consumes.
- The report is free prose by design, so it is delivered to a person and is not
  fed into the managed-review pipeline.