AI Review · Jira UX · Multica under the hood

AI Review with Jira and Multica

The goal is to integrate a universal AI reviewer into the familiar Jira workflow. The team assigns an issue to a single digital identity, Reviewer, while Multica assembles multi-repository context behind the scenes, performs the review, and returns the result to Jira.

What we are solving

1
One Jira-based UXThe user does not open a separate interface. They assign an issue to Reviewer and receive the final comment in the same issue.
2
Context from multiple repositoriesClient, ClientCore, and four server repositories live in one product workspace while remaining independent Git repositories.
3
Review of task-specific commitsReviewer checks commits whose messages contain the Jira issue key. A new set of changes creates a new, independent review run.

Product working context

Client ClientCore shelterserver sheltershared shelteradmin shelterresourceconverter
6 independent Git repositories
From the Jira comment, Coordinator receives branches and operational context, finds the required commits, and gives a deterministic Python script an exact description of what the slot workspace must contain.

Pilot configuration in Multica

The pilot has only two parts: an infrastructure layer with three workspaces and two agents. There is one AI Reviewer; the slots are not its replicas.
1

Runtime and workspaces

1 Runtime · 3 Multica projects
Coordinator ProjectCoordinator workspace: Slot 01/02 state, the review-run queue, manifests, operational JSON, and orchestration state.
Review Slot 01The first independent local directory with six Git repositories, prepared for a particular review run.
Review Slot 02A second, identical local directory for a parallel pilot review.
Two slots limit filesystem parallelism and make it possible to test the queue without creating a separate workspace for every Jira issue.
2

Agents

AI Review Coordinator

A lightweight model such as Codex Spark. Coordinator does not perform deep code analysis: it receives events, selects a slot, starts Python processes, creates the review issue, and publishes the result in Jira.

Universal AI Reviewer

One universal agent that can work with an issue in any slot project. It is not split into client and server reviewers and receives only read-only access to an already prepared workspace.

Jira also has a single digital identity: Reviewer. Reviewer’s own skills are specified separately; this proposal fixes only its role and access boundary.

Review pipeline: from a Jira hook to handing the issue back

Coordinator edits a single operational progress comment. There are few visible states: only four user-relevant stages, without technical noise.
Jira status
Coordinator accepted the request
Jira status
Waiting for a slotor: Preparing the slot
Jira status
Review started in the slot
Final state in Jira
The review itself is publishedthe issue is returned to the assignee
Stage 1

Accept the request

The Jira assignment hook starts Coordinator and records a new review run.

Step 1Jira hook

Issue assigned to Reviewer

Autopilot receives the issue key, the user who sent the issue for review, and comments containing branches and operational context.

Jira statusCoordinator accepted the request
Step 2Coordinator

Resolve the change set

Coordinator determines the task type and finds commits in the relevant repositories whose messages contain this Jira issue key.

Jira statusCoordinator accepted the request
Stage 2

Obtain a workspace

Coordinator reserves an available slot or puts the run in the queue.

Step 3Coordinator

Select a slot or queue

An available Slot 01/02 is atomically assigned to the run. If no slots are available, the run is stored in the coordinator workspace queue.

Jira statusWaiting for a slot
Step 4Python process

Start prepare_workspace.py

A one-shot process fetches, resets, and checks out the required commits in six repositories, writes a manifest, and exits.

Jira statusPreparing the slot
Step 5Python callback

Receive workspace.ready

Coordinator verifies that the manifest belongs to the expected run and that every repository is at the required commit SHA.

Jira statusPreparing the slot
Stage 3

Start the review

Coordinator creates an issue in the prepared slot project, and the single Reviewer begins its analysis.

Step 6Multica issue

Create an issue in the selected slot project

The issue contains Jira context, the list of target commits, repository paths, the manifest, and an indication of whether the review is client-side, server-side, or cross-repository.

Jira statusReview started in the slot
Step 7AI Reviewer

Perform a read-only review

Reviewer follows the checklists, inspects the target commits and related code across every relevant repository, then writes a structured result into its own Multica issue.

Jira statusReview started in the slot
Stage 4

Return the result

Coordinator publishes the result and releases the infrastructure resource.

Step 8Multica hook

Receive the completed reviewer issue

Coordinator retrieves the review result and verifies that it contains a summary, checklist results, and a findings list with the exact fragment of the source diff that demonstrates the reason for every finding.

Jira statusReview started in the slot
Step 9Jira R/W

Publish the review and return the issue

Jira receives a final rich-text comment with the conclusion, severity, and a paragraph for every finding; problematic lines from the reviewed change set are quoted in inline diff blocks. After publication, the issue returns to the person who sent it for review.

JiraThe review is published; the issue is returned
Step 10Python process

Start cleanup_workspace.py

The slot is cleaned, its assignment is removed, and after slot.cleaned it becomes available to the next run in the queue.

JiraThe review is published; the issue is returned

Queue and repeat review

  • the next queued run immediately takes a released slot
  • a watchdog can periodically recheck the queue as a fallback mechanism
  • after new changes, the Jira issue is assigned to Reviewer again and a new run is created in any available slot
  • neither the old slot workspace nor the old AI session is process state

Keep deterministic work separate from the LLM

Coordinator starts a Python process and completes its task. It does not keep an agent session open during fetch, checkout, or cleanup.

Three AI Review Coordinator skills

Coordinator skills correspond to three types of incoming events. This avoids one enormous orchestrator with implicit continuation logic.
Skill 01 · Jira hook

new_review_from_jira

Input
assignment of a Jira issue to Reviewer
Actions
read comments, find the change set, select a slot or queue, write the progress comment
Output
a started prepare_workspace.py process or a queued review run
Skill 02 · Python callback

workspace_ready_from_python

Input
workspace.ready + slot manifest
Actions
validate slot/run/SHA, create an issue in the required slot project, assign Universal AI Reviewer
Output
the reviewer task is running; Jira shows “Review started in the slot”
Skill 03 · Multica hook

review_completed_from_multica

Input
completion of a reviewer issue
Actions
retrieve the result, publish the Jira comment, return the issue, start cleanup
Output
the final review in Jira and a slot returned to the pool
Universal AI Reviewer skills are not split into separate system skills in this version of the proposal. Instead, the review contract is defined below: which checklists Reviewer follows and the format in which it returns findings.

Boundaries of responsibility and access

Reviewer remains genuinely read-only: it analyzes prepared state but does not manage Jira, slots, or Python processes.

Permissions matrix

minimum permissions required for each role
Component Jira Python runner Coordinator state Slot files Git repos Multica issues
AI Review Coordinator R/W spawn / status R/W manifest / state via prepare logic create / read
Python prepare / cleanup — process status callback R/W fetch / reset / checkout —
Universal AI Reviewer — — — read-only read-only context own issue
full access limited / read-only operational process no access

How the AI review itself works

Reviewer analyzes game code against explicit checklists. The result is a regular rich-text Jira comment with a concise summary, paragraphs for each finding, and exact fragments of the reviewed diff.
Pass 1Assemble the change setFind every commit with the issue key and build a diff across the affected repositories.
Pass 2Follow the checklistsCheck correctness, architecture, configuration, duplication, and the cost of the change.
Pass 3Verify relationshipsInspect calls, models, and contracts beyond the lines in the changed diff.
Pass 4Build the Jira reportAssign severity and provide the exact location, risk, and direction for a fix.

Preflight · Mechanical checks and change-set boundaries

Layer 1
CheckVerificationWhat Reviewer checks
✓All task commits were foundThe list of reviewed commits from every repository. The branch of every repository in the slot.

Checklist A · Game logic and correctness

Layer 2
CheckVerificationWhat Reviewer checks
✓The Jira requirement is implementedThe change genuinely solves the described task instead of replacing it with different logic that is locally convenient.
✓Style is consistent with the projectNaming, method structure, imports/usings, and local patterns match the surrounding code.
✓States and transitions are correctRepeated calls, partial execution, cancellation, missing data, boundary values, and unexpected event order are handled.
✓Errors and fallback pathsExceptions and invalid states are handled at the correct level; logging provides enough context for diagnosis.
✓PerformanceThere are no unnecessary allocations, repeated passes, serialization, expensive lookups, or network work on frequent game and server paths.

Checklist B · Architecture, configuration, and no duplication

Layer 2
CheckVerificationWhat Reviewer checks
✓Separation of concernsLogic resides in the correct layer, methods and classes do not acquire unrelated responsibilities, and dependencies are not tangled unnecessarily.
✓Existing functionality was not recreatedBefore adding a method, helper, model, converter, or algorithm, Reviewer searches the entire project for an equivalent and flags duplication of an existing implementation.
✓Parameters are editable by game designersBalance and product parameters are not hard-coded but stored in JSON configuration described by the corresponding proto schemas.
✓The code remains readableThere is no excessive nesting, overly long methods, non-obvious side effects, or hidden assumptions for the next developer to reconstruct.

Checklist C · Cross-repository consistency and intent

Layer 3
CheckVerificationWhat Reviewer checks
✓Client and server interpret data identicallyIdentifiers, enums, units, serialization, default values, and state-transition rules match.
✓Contract changes reach every repositoryIf a model or protocol changes, Reviewer checks every place where the contract is read, written, converted, or stored.
✓Version compatibilityA new client does not assume an immediate server update, and the server does not require every player to already use the new client version.

Final Jira comment format

A regular rich-text report: introductory paragraphs with branches and reviewed commits, a concise checklist summary, then several paragraphs for every finding. The path is formatted as inline code, and the exact hunk from the source change set as a Jira code block with the diff language. The direction for a fix remains a separate paragraph; Reviewer does not synthesize a patch in place of the source diff.

AI Review · HC-12345

Summary. Maximum severity: HIGH. Found: 1 HIGH, 1 MEDIUM, 1 LOW.

Change set. Client · HC-12345_feature · a1b2c3d; ClientCore · HC-12345_feature · d4e5f6a; shelterserver · HC-12345_feature · 7b8c9d0.

Checklists. Game logic — FINDINGS; Architecture & configs — FINDINGS; Cross-repo — FINDINGS.

HIGHAIR-001 · State is persisted only partially

shelterserver/.../BattleService.java:184

If an exception occurs after the first change, part of the state has already been persisted while the rest remains stale. The client and server may observe different outcomes for the same game operation.

Fix. Apply both changes atomically or add explicit compensation for the first step.

Source diff fragment

@@ BattleService.java:184 @@  applyBattleResult(player, battle);+ savePlayerState(player);+ saveBattleState(battle);

MEDIUMAIR-002 · Cooldown is hard-coded

Client/.../CooldownController.cs:73

The cooldown value is hard-coded even though the mechanic’s other parameters come from JSON/proto configuration. A game designer cannot change it without a new build, and the client and server values may diverge.

Fix. Add a field to the proto schema and read it from the shared JSON configuration.

Source diff fragment

@@ CooldownController.cs:73 @@- _cooldown.Start(_config.CooldownSeconds);+ _cooldown.Start(30);

LOWAIR-003 · Rounding rule is duplicated

ClientCore/.../RewardUtils.cs:41

The new helper repeats an existing method with the same rounding rule. Two implementations of one rule may diverge over time.

Fix. Reuse the existing shared method.

Source diff fragment

@@ RewardUtils.cs:41 @@+ public static int CalculateReward(float value, float multiplier)+ {+     return Mathf.RoundToInt(value * multiplier);+ }

After publication: Coordinator returns the Jira issue to the user who sent it for review. If there are no findings, the report still contains a checklist summary and the short statement “No findings.”