agent-review

Review vs Develop

Collects a rich context bundle (diff, stat, commit log, selected full file contents, consumer graph) then dispatches up to ten subagents: six-to-eight specialist reviewers run in parallel, then a challenger validates Critical findings, and a synthesis agent runs last to produce an executive summary.

steps:

• agent: prompt: | Run git fetch origin with 'all' permissions to bypass sandbox restrictions for SSH key permissions.

• run: git log develop..HEAD --oneline

• run: git diff --stat develop...HEAD

• run: git diff --name-only develop...HEAD

• run: git diff develop...HEAD

• agent: prompt: | You have the output of git diff --name-only develop...HEAD from the previous step.

    ## Pre-review configuration
  
    ### Step A — Classify conditional reviewers and path groups
  
    **A1 — Conditional reviewers:** Scan the changed file list and determine which conditional subagents apply:
  
    - `perf-reviewer` → triggered if any file is under `presentation/` OR matches `*_bloc.dart` / `*_cubit.dart`
    - `data-layer-reviewer` → triggered if any file path includes `data/service/`, `data/dto/`, `data/source/`, `data/repository/`, or `data/mapper/`
    - `ui-reviewer` → triggered if any file is under `presentation/pages/` or `presentation/widgets/`, or matches `*_page.dart` / `*_widget.dart`
  
    Build two lists:
    - `ALWAYS_REVIEWERS`: `code-quality-reviewer`, `bug-reviewer`, `architecture-reviewer`, `pre-pr-validator`, `tech-debt-reviewer`
    - `CONDITIONAL_REVIEWERS`: the subset of `perf-reviewer`, `data-layer-reviewer`, `ui-reviewer` that are triggered
  
    **A2 — Path groups:** Parse the changed file list and group files into logical review segments using this hierarchy (apply the first matching rule):
  
    | Path pattern | Group label |
    |---|---|
    | `packages/features/<feature>/lib/src/<segment>/` or files directly under `lib/src/<segment>/` | `<feature>/<segment>` (e.g. `store_oechsle/search`) |
    | `packages/features/<feature>/test/` | `<feature>/test` |
    | `packages/features/<feature>/` (anything else) | `<feature>` |
    | `packages/core/` | `core` |
    | `packages/libraries/<lib>/` | `<lib>` |
    | `apps/<app>/` | `apps/<app>` |
    | `.cursor/` | `project config` |
    | anything else | `other` |
  
    Build `PATH_GROUPS`: a deduplicated, sorted list of group labels present in this diff.
    For each group, also record the path prefix used to match files into it (needed for filtering in the orchestration step).
  
    ### Step B — Ask the user
  
    Use the `AskQuestion` tool to present **2–3 questions at once**:
  
    **Q1 (multi-select, id: `reviewers`):** "The following reviewers always run: code-quality-reviewer, bug-reviewer, architecture-reviewer, pre-pr-validator, tech-debt-reviewer. Which additional reviewers would you like to enable?"
    - Do NOT include the 5 core reviewers (`code-quality-reviewer`, `bug-reviewer`, `architecture-reviewer`, `pre-pr-validator`, `tech-debt-reviewer`) as options — they always run and are non-negotiable.
    - Do NOT list `finding-challenger` or `review-synthesizer` — they always run and are not user-configurable.
    - List ONLY the conditional reviewers that are in `CONDITIONAL_REVIEWERS`:
      - `perf-reviewer` — Widget rebuilds, memory leaks, BLoC state efficiency
      - `data-layer-reviewer` — Retrofit, DTOs, DataSource/Repository patterns
      - `ui-reviewer` — UI Kit compliance, design tokens, Agora* components
    - Pre-select all reviewers in `CONDITIONAL_REVIEWERS` by default; the user may deselect any of them.
    - If `CONDITIONAL_REVIEWERS` is empty, skip Q1 entirely and inform the user that only the 5 core reviewers apply for this diff.