The built-in code-review workflow in Claude Code 2.1.220

1. Result

Claude Code 2.1.220 contains a built-in JavaScript workflow named code-review.

The program registers this workflow with hidden: true. The workflow is inside the installed executable. It is not the public Markdown code-review plugin.

The workflow has five stages:

Scope → Find → Verify → Sweep → Synthesize

The command /code-review xhigh can select this workflow. However, a feature flag controls this selection. The command does not always use the workflow.

The terms ultra and ultracode refer to related but different features. Neither is the name of this workflow.

2. Terms

This report uses these technical terms:

Term	Meaning
Agent	A model session that does an assigned task.
Workflow	A JavaScript program that controls agents and processes their results.
Finder	An agent that searches for possible problems.
Candidate	A possible problem that requires a check.
Verifier	An independent agent that checks candidates against the code.
Finding	A candidate that the review includes in its report.
Diff	The code changes selected for review.
Feature flag	A configuration value that controls a program feature.
Inline review	A review that does not use this named Workflow program. It can still use agents.

3. Inspection method and limits

The inspected program was Claude Code 2.1.220 for macOS ARM64.

The executable contains a Bun section. This section includes bytecode and a minified JavaScript bundle. Minification replaces descriptive names with short names and removes much formatting.

The bundle contains a function named gDd(). This function builds the review script from a text template and shared prompts.

The investigation recovered the complete script. The recovered script has 354 lines and approximately 25 KB of text.

The script requires the Claude Code Workflow runtime. It is not a separate Node.js program. The runtime supplies these functions and values:

agent
parallel
phase
log
args

These findings apply to version 2.1.220. They do not establish the same behavior in later versions.

A second installation, version 2.1.260, was present. However, the shell selected version 2.1.220. Check the selected executable before you compare results.

4. Review stages

4.1 Scope

One agent establishes the review scope. It returns:

The diff command.
The changed file paths.
A change summary.
The applicable CLAUDE.md files.
The rules that apply to the changed code.

The target can be a pull request, branch, reference range, file path, or written scope instruction.

With no target, the agent selects the current branch changes. It also includes uncommitted changes when they exist.

The workflow stops if the scope contains no changed files.

4.2 Find

The finder agents operate in parallel. Each correctness finder gets a different task.

Finder	Task
A	Examine each changed line and its containing function for incorrect behavior.
B	Check whether deleted code had a safeguard that the new code does not retain.
C	Check the callers and called functions for incompatible changes.
D	Search for known errors in the language or framework.
E	Check that wrappers and proxies call the correct object and supply the required methods.

A separate finder checks five code-quality subjects:

Reuse of existing code.
Unnecessary complexity.
Unnecessary computation or input/output operations.
The level of the implementation, called altitude in the source.
Compliance with applicable CLAUDE.md rules.

Each candidate contains a file path, an optional line number, a summary, and a failure scenario.

For a code-quality candidate, the scenario describes a concrete cost instead of an incorrect result or crash.

All initial finders must finish before verification starts.

4.3 Verify

The script converts equivalent file paths to a common form. It then groups candidates by file and line.

One independent verifier checks each group. The verifier gives a separate result for each candidate in that group.

Result	Meaning
`CONFIRMED`	The verifier can identify the triggering state and the incorrect behavior.
`PLAUSIBLE`	The failure mechanism exists, but its triggering state is uncertain.
`REFUTED`	The claim is incorrect, impossible under the code's constraints, or prevented by other code.

The prompt states “PLAUSIBLE by default.”

A realistic but uncertain failure condition is not sufficient reason to reject a candidate. Rejection requires evidence from the code.

The final report can therefore contain uncertain findings. This is an intentional property of the review instructions.

Grouping does not combine duplicate claims. Each candidate keeps its own result. The script removes candidates that have no verifier result.

4.4 Sweep

The xhigh and max levels add one new finder after the first verification stage.

This finder receives the previous candidates. It searches only for problems that the first search missed.

It can return up to eight additional candidates. Independent verifiers check these candidates before the final report.

The high level does not include this stage.

4.5 Synthesize

The script removes candidates with a REFUTED result.

A final agent selects findings by their index numbers. It identifies duplicate claims and puts the findings in priority order.

The script then assembles the report from the existing finding text. The final agent does not rewrite that text.

Correctness findings take priority over code-quality findings. Within each category, CONFIRMED takes priority over PLAUSIBLE.

If the final agent omits a verified finding, the script adds it when the report still has space.

5. Effort levels and limits

Level	Correctness finders	Code-quality finders	Initial candidate limit	Additional search	Report limit
`high`	3	1	48	None	10 findings
`xhigh`	5	1	80	8 candidates	15 findings
`max`	5	1	80	8 candidates	15 findings

The initial candidate limits include all five code-quality subjects:

high:  (3 × 6) + (5 × 6) = 48
xhigh: (5 × 8) + (5 × 8) = 80
max:   (5 × 8) + (5 × 8) = 80

These are maximum limits, not required totals. The number of verifier agents depends on the number of distinct candidate locations.

The xhigh and max levels use the same workflow structure. The source identifies model reasoning effort as their difference.

The workflow's args value selects its structure. The script does not set each agent's reasoning effort.

6. Normal command selection

In an interactive Claude Code session, use one of these commands:

/code-review high
/code-review xhigh
/code-review max
/code-review xhigh main...HEAD

When the selection conditions pass, the built-in skill tells Claude to make this tool call:

Workflow({ name: "code-review", args: "xhigh main...HEAD" })

Version 2.1.220 requires all these conditions:

The review level is high, xhigh, or max.
Claude is not preloading the skill.
Workflows is enabled, available, and permitted by policy.
The session is interactive, not a claude -p session.
The session has the Workflow tool.
tengu_review_workflow_routing is true.

One inspected installation had these cached values:

{
  "tengu_workflows_enabled": true,
  "tengu_review_workflow_routing": false
}

Thus, Workflows availability alone does not establish automatic selection of the review workflow.

Cached values can change after an update from the service. These values are not a statement about all accounts.

The investigation did not change feature flags or settings.

7. Request the named workflow directly

The named-workflow lookup includes hidden built-in workflows. It is separate from the command's automatic selection flag.

If the Workflow tool is available and permitted, use this procedure:

Set the model effort:
```
/effort xhigh
```

Give Claude this instruction:

Use the Workflow tool with name "code-review" and args "xhigh main...HEAD".
Use this exact named workflow.
Do not edit files or post GitHub comments.
If the workflow is unavailable, report that condition.
Do not use a different review method.

Check for a Workflow tool call with the specified name.
Use /workflows to examine progress.
Check for the Scope, Find, Verify, Sweep, and Synthesize stages.

If user settings disable Workflows, this command requests enablement for one session:

claude --settings '{"enableWorkflows":true}'

Policy and service availability still apply.

The inspected registration and lookup code support this direct request. The investigation did not test it through a live Claude session.

CAUTION: The workflow can start many agents. These agents consume model tokens. The investigation did not measure cost or completion time.

8. What “ultra” means

Cloud review

These commands select the separate cloud review service:

/code-review ultra
/ultrareview
claude ultrareview

The local program starts a cloud session and waits for its findings. This operation requires remote access to the code and can incur charges.

The local launcher does not establish which workflow program the cloud service uses.

Ultracode

This command selects xhigh effort and continuing use of dynamic workflows for substantive tasks:

/effort ultracode

The ultracode keyword can also request dynamic workflows for one turn.

Neither option specifically selects the named code-review workflow. The review script recognizes high, xhigh, and max, not ultra.

Public plugin

The official public code-review plugin describes its procedure in Markdown.

The inspected plugin uses parallel reviewers and confidence scores. It removes issues with scores below 80.

That procedure is different from the JavaScript workflow described here.

9. Evidence and validation

The recovered source has these identifiers and locations:

Identifier	Location in the recovered bundle	Function
`DRo()`	Line 13604	Registers built-in workflows and the hidden option.
`Osn()`	Line 13992	Finds a workflow by name.
`gDd()`	Lines 15832–16188	Builds and registers the code-review script.
`$X_()`	Line 16614	Initializes the bundled workflows.
`q8S()`	Lines 23710–23725	Builds the review instructions, including the Workflow tool call.
`eom()`	Line 23725	Checks the conditions for automatic workflow selection.

These names and line numbers apply only to the recovered 2.1.220 bundle.

SHA-256 of the recovered bundle:

d60e0e81efcc86861d9a7094b027b2b7b7cbd99469eebbcd6a5b707030211120

The investigation performed these checks without model requests:

The extracted script passed a JavaScript syntax check.
Test runs used synthetic agent results at high, xhigh, and max.
The tests confirmed the initial finder counts.
Candidates at one location used one verifier agent.
Verification results remained attached to the correct candidates.
The final stage combined duplicate findings.
Only xhigh and max performed the additional search.
An empty scope stopped the review.

These tests check program behavior with supplied results. They do not measure bug detection, false findings, model compliance, live availability, or cost.

No live model review or cloud review ran during the investigation.

10. Conclusion

The strongest match is the hidden code-review JavaScript workflow inside Claude Code 2.1.220.

It uses parallel finders, independent verification, an optional additional search, and a final report stage.

The command name alone does not prove that this workflow ran. Check the Workflow tool call and its stage display.

nateberkopec/claude-code-review-workflow-report.md

Select an option

No results found