@qwen-code/qwen-code 0.14.1 → 0.14.2-nightly.20260410.4d2d4432d

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -98,6 +98,7 @@ Settings are organized into categories. All settings should be placed within the
98
98
  | --------------------------------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
99
99
  | `ui.theme` | string | The color theme for the UI. See [Themes](../configuration/themes) for available options. | `undefined` |
100
100
  | `ui.customThemes` | object | Custom theme definitions. | `{}` |
101
+ | `ui.statusLine` | object | Custom status line configuration. A shell command whose output is shown in the footer's left section. See [Status Line](../features/status-line). | `undefined` |
101
102
  | `ui.hideWindowTitle` | boolean | Hide the window title bar. | `false` |
102
103
  | `ui.hideTips` | boolean | Hide helpful tips in the UI. | `false` |
103
104
  | `ui.hideBanner` | boolean | Hide the application banner. | `false` |
@@ -168,6 +169,18 @@ Settings are organized into categories. All settings should be placed within the
168
169
  }
169
170
  ```
170
171
 
172
+ **max_tokens (adaptive output tokens):**
173
+
174
+ When `samplingParams.max_tokens` is not set, Qwen Code uses an adaptive output token strategy to optimize GPU resource usage:
175
+
176
+ 1. Requests start with a default limit of **8K** output tokens
177
+ 2. If the response is truncated (the model hits the limit), Qwen Code automatically retries with **64K** tokens
178
+ 3. The partial output is discarded and replaced with the full response from the retry
179
+
180
+ This is transparent to users — you may briefly see a retry indicator if escalation occurs. Since 99% of responses are under 5K tokens, the retry happens rarely (<1% of requests).
181
+
182
+ To override this behavior, either set `samplingParams.max_tokens` in your settings or use the `QWEN_CODE_MAX_OUTPUT_TOKENS` environment variable.
183
+
171
184
  **contextWindowSize:**
172
185
 
173
186
  Overrides the default context window size for the selected model. Qwen Code determines the context window using built-in defaults based on model name matching, with a constant fallback value. Use this setting when a provider's effective context limit differs from Qwen Code's default. This value defines the model's assumed maximum context capacity, not a per-request token limit.
@@ -206,6 +219,7 @@ The `extra_body` field allows you to add custom parameters to the request body s
206
219
  | `context.fileFiltering.respectQwenIgnore` | boolean | Respect .qwenignore files when searching. | `true` |
207
220
  | `context.fileFiltering.enableRecursiveFileSearch` | boolean | Whether to enable searching recursively for filenames under the current tree when completing `@` prefixes in the prompt. | `true` |
208
221
  | `context.fileFiltering.enableFuzzySearch` | boolean | When `true`, enables fuzzy search capabilities when searching for files. Set to `false` to improve performance on projects with a large number of files. | `true` |
222
+ | `context.gapThresholdMinutes` | number | Minutes of inactivity after which retained thinking blocks are cleared to free context tokens. Aligns with typical provider prompt-cache TTL. Set higher if your provider has a longer cache TTL. | `5` |
209
223
 
210
224
  #### Troubleshooting File Search Performance
211
225
 
@@ -490,22 +504,23 @@ For authentication-related variables (like `OPENAI_*`) and the recommended `.qwe
490
504
 
491
505
  ### Environment Variables Table
492
506
 
493
- | Variable | Description | Notes |
494
- | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
495
- | `QWEN_TELEMETRY_ENABLED` | Set to `true` or `1` to enable telemetry. Any other value is treated as disabling it. | Overrides the `telemetry.enabled` setting. |
496
- | `QWEN_TELEMETRY_TARGET` | Sets the telemetry target (`local` or `gcp`). | Overrides the `telemetry.target` setting. |
497
- | `QWEN_TELEMETRY_OTLP_ENDPOINT` | Sets the OTLP endpoint for telemetry. | Overrides the `telemetry.otlpEndpoint` setting. |
498
- | `QWEN_TELEMETRY_OTLP_PROTOCOL` | Sets the OTLP protocol (`grpc` or `http`). | Overrides the `telemetry.otlpProtocol` setting. |
499
- | `QWEN_TELEMETRY_LOG_PROMPTS` | Set to `true` or `1` to enable or disable logging of user prompts. Any other value is treated as disabling it. | Overrides the `telemetry.logPrompts` setting. |
500
- | `QWEN_TELEMETRY_OUTFILE` | Sets the file path to write telemetry to when the target is `local`. | Overrides the `telemetry.outfile` setting. |
501
- | `QWEN_TELEMETRY_USE_COLLECTOR` | Set to `true` or `1` to enable or disable using an external OTLP collector. Any other value is treated as disabling it. | Overrides the `telemetry.useCollector` setting. |
502
- | `QWEN_SANDBOX` | Alternative to the `sandbox` setting in `settings.json`. | Accepts `true`, `false`, `docker`, `podman`, or a custom command string. |
503
- | `SEATBELT_PROFILE` | (macOS specific) Switches the Seatbelt (`sandbox-exec`) profile on macOS. | `permissive-open`: (Default) Restricts writes to the project folder (and a few other folders, see `packages/cli/src/utils/sandbox-macos-permissive-open.sb`) but allows other operations. `strict`: Uses a strict profile that declines operations by default. `<profile_name>`: Uses a custom profile. To define a custom profile, create a file named `sandbox-macos-<profile_name>.sb` in your project's `.qwen/` directory (e.g., `my-project/.qwen/sandbox-macos-custom.sb`). |
504
- | `DEBUG` or `DEBUG_MODE` | (often used by underlying libraries or the CLI itself) Set to `true` or `1` to enable verbose debug logging, which can be helpful for troubleshooting. | **Note:** These variables are automatically excluded from project `.env` files by default to prevent interference with the CLI behavior. Use `.qwen/.env` files if you need to set these for Qwen Code specifically. |
505
- | `NO_COLOR` | Set to any value to disable all color output in the CLI. | |
506
- | `CLI_TITLE` | Set to a string to customize the title of the CLI. | |
507
- | `CODE_ASSIST_ENDPOINT` | Specifies the endpoint for the code assist server. | This is useful for development and testing. |
508
- | `TAVILY_API_KEY` | Your API key for the Tavily web search service. | Used to enable the `web_search` tool functionality. Example: `export TAVILY_API_KEY="tvly-your-api-key-here"` |
507
+ | Variable | Description | Notes |
508
+ | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
509
+ | `QWEN_TELEMETRY_ENABLED` | Set to `true` or `1` to enable telemetry. Any other value is treated as disabling it. | Overrides the `telemetry.enabled` setting. |
510
+ | `QWEN_TELEMETRY_TARGET` | Sets the telemetry target (`local` or `gcp`). | Overrides the `telemetry.target` setting. |
511
+ | `QWEN_TELEMETRY_OTLP_ENDPOINT` | Sets the OTLP endpoint for telemetry. | Overrides the `telemetry.otlpEndpoint` setting. |
512
+ | `QWEN_TELEMETRY_OTLP_PROTOCOL` | Sets the OTLP protocol (`grpc` or `http`). | Overrides the `telemetry.otlpProtocol` setting. |
513
+ | `QWEN_TELEMETRY_LOG_PROMPTS` | Set to `true` or `1` to enable or disable logging of user prompts. Any other value is treated as disabling it. | Overrides the `telemetry.logPrompts` setting. |
514
+ | `QWEN_TELEMETRY_OUTFILE` | Sets the file path to write telemetry to when the target is `local`. | Overrides the `telemetry.outfile` setting. |
515
+ | `QWEN_TELEMETRY_USE_COLLECTOR` | Set to `true` or `1` to enable or disable using an external OTLP collector. Any other value is treated as disabling it. | Overrides the `telemetry.useCollector` setting. |
516
+ | `QWEN_SANDBOX` | Alternative to the `sandbox` setting in `settings.json`. | Accepts `true`, `false`, `docker`, `podman`, or a custom command string. |
517
+ | `SEATBELT_PROFILE` | (macOS specific) Switches the Seatbelt (`sandbox-exec`) profile on macOS. | `permissive-open`: (Default) Restricts writes to the project folder (and a few other folders, see `packages/cli/src/utils/sandbox-macos-permissive-open.sb`) but allows other operations. `strict`: Uses a strict profile that declines operations by default. `<profile_name>`: Uses a custom profile. To define a custom profile, create a file named `sandbox-macos-<profile_name>.sb` in your project's `.qwen/` directory (e.g., `my-project/.qwen/sandbox-macos-custom.sb`). |
518
+ | `DEBUG` or `DEBUG_MODE` | (often used by underlying libraries or the CLI itself) Set to `true` or `1` to enable verbose debug logging, which can be helpful for troubleshooting. | **Note:** These variables are automatically excluded from project `.env` files by default to prevent interference with the CLI behavior. Use `.qwen/.env` files if you need to set these for Qwen Code specifically. |
519
+ | `NO_COLOR` | Set to any value to disable all color output in the CLI. | |
520
+ | `CLI_TITLE` | Set to a string to customize the title of the CLI. | |
521
+ | `CODE_ASSIST_ENDPOINT` | Specifies the endpoint for the code assist server. | This is useful for development and testing. |
522
+ | `QWEN_CODE_MAX_OUTPUT_TOKENS` | Overrides the default maximum output tokens per response. When not set, Qwen Code uses an adaptive strategy: starts with 8K tokens and automatically retries with 64K if the response is truncated. Set this to a specific value (e.g., `16000`) to use a fixed limit instead. | Takes precedence over the capped default (8K) but is overridden by `samplingParams.max_tokens` in settings. Disables automatic escalation when set. Example: `export QWEN_CODE_MAX_OUTPUT_TOKENS=16000` |
523
+ | `TAVILY_API_KEY` | Your API key for the Tavily web search service. | Used to enable the `web_search` tool functionality. Example: `export TAVILY_API_KEY="tvly-your-api-key-here"` |
509
524
 
510
525
  ## Command-Line Arguments
511
526
 
@@ -1,5 +1,6 @@
1
1
  export default {
2
2
  commands: 'Commands',
3
+ 'code-review': 'Code Review',
3
4
  'followup-suggestions': 'Followup Suggestions',
4
5
  'sub-agents': 'SubAgents',
5
6
  arena: 'Agent Arena',
@@ -16,5 +17,6 @@ export default {
16
17
  language: 'i18n',
17
18
  channels: 'Channels',
18
19
  hooks: 'Hooks',
20
+ 'status-line': 'Status Line',
19
21
  'scheduled-tasks': 'Scheduled Tasks',
20
22
  };
@@ -1,6 +1,6 @@
1
1
  # Approval Mode
2
2
 
3
- Qwen Code offers three distinct permission modes that allow you to flexibly control how AI interacts with your code and system based on task complexity and risk level.
3
+ Qwen Code offers four distinct permission modes that allow you to flexibly control how AI interacts with your code and system based on task complexity and risk level.
4
4
 
5
5
  ## Permission Modes Comparison
6
6
 
@@ -40,6 +40,18 @@ You can switch into Plan Mode during a session using **Shift+Tab** (or **Tab** o
40
40
 
41
41
  If you are in Normal Mode, **Shift+Tab** (or **Tab** on Windows) first switches into `auto-edits` Mode, indicated by `⏵⏵ accept edits on` at the bottom of the terminal. A subsequent **Shift+Tab** (or **Tab** on Windows) will switch into Plan Mode, indicated by `⏸ plan mode`.
42
42
 
43
+ **Use the `/plan` command**
44
+
45
+ The `/plan` command provides a quick shortcut for entering and exiting Plan Mode:
46
+
47
+ ```bash
48
+ /plan # Enter plan mode
49
+ /plan refactor the auth module # Enter plan mode and start planning
50
+ /plan exit # Exit plan mode, restore previous mode
51
+ ```
52
+
53
+ When you exit Plan Mode with `/plan exit`, your previous approval mode is automatically restored (e.g., if you were in Auto-Edit before entering Plan Mode, you'll return to Auto-Edit).
54
+
43
55
  **Start a new session in Plan Mode**
44
56
 
45
57
  To start a new session in Plan Mode, use the `/approval-mode` then select `plan`
@@ -59,14 +71,10 @@ qwen --prompt "What is machine learning?"
59
71
  ### Example: Planning a complex refactor
60
72
 
61
73
  ```bash
62
- /approval-mode plan
63
- ```
64
-
65
- ```
66
- I need to refactor our authentication system to use OAuth2. Create a detailed migration plan.
74
+ /plan I need to refactor our authentication system to use OAuth2. Create a detailed migration plan.
67
75
  ```
68
76
 
69
- Qwen Code analyzes the current implementation and create a comprehensive plan. Refine with follow-ups:
77
+ Qwen Code enters Plan Mode and analyzes the current implementation to create a comprehensive plan. Refine with follow-ups:
70
78
 
71
79
  ```
72
80
  What about backward compatibility?
@@ -235,7 +243,7 @@ qwen --prompt "Run the test suite, fix all failing tests, then commit changes"
235
243
 
236
244
  ### Keyboard Shortcut Switching
237
245
 
238
- During a Qwen Code session, use **Shift+Tab**​ (or **Tab** on Windows) to quickly cycle through the three modes:
246
+ During a Qwen Code session, use **Shift+Tab**​ (or **Tab** on Windows) to quickly cycle through the four modes:
239
247
 
240
248
  ```
241
249
  Default Mode → Auto-Edit Mode → YOLO Mode → Plan Mode → Default Mode
@@ -0,0 +1,279 @@
1
+ # Code Review
2
+
3
+ > Review code changes for correctness, security, performance, and code quality using `/review`.
4
+
5
+ ## Quick Start
6
+
7
+ ```bash
8
+ # Review local uncommitted changes
9
+ /review
10
+
11
+ # Review a pull request (by number or URL)
12
+ /review 123
13
+ /review https://github.com/org/repo/pull/123
14
+
15
+ # Review and post inline comments on the PR
16
+ /review 123 --comment
17
+
18
+ # Review a specific file
19
+ /review src/utils/auth.ts
20
+ ```
21
+
22
+ If there are no uncommitted changes, `/review` will let you know and stop — no agents are launched.
23
+
24
+ ## How It Works
25
+
26
+ The `/review` command runs a multi-stage pipeline:
27
+
28
+ ```
29
+ Step 1: Determine scope (local diff / PR worktree / file)
30
+ Step 2: Load project review rules
31
+ Step 3: Run deterministic analysis (linter, typecheck) [zero LLM cost]
32
+ Step 4: 5 parallel review agents [5 LLM calls]
33
+ |-- Agent 1: Correctness & Security
34
+ |-- Agent 2: Code Quality
35
+ |-- Agent 3: Performance & Efficiency
36
+ |-- Agent 4: Undirected Audit
37
+ '-- Agent 5: Build & Test (runs shell commands)
38
+ Step 5: Deduplicate --> Batch verify --> Aggregate [1 LLM call]
39
+ Step 6: Reverse audit (find coverage gaps) [1 LLM call]
40
+ Step 7: Present findings + verdict
41
+ Step 8: Autofix (user-confirmed, optional)
42
+ Step 9: Post PR inline comments (if requested)
43
+ Step 10: Save report + incremental cache
44
+ Step 11: Clean up (remove worktree + temp files)
45
+ ```
46
+
47
+ ### Review Agents
48
+
49
+ | Agent | Focus |
50
+ | --------------------------------- | ------------------------------------------------------------------ |
51
+ | Agent 1: Correctness & Security | Logic errors, null handling, race conditions, injection, XSS, SSRF |
52
+ | Agent 2: Code Quality | Style consistency, naming, duplication, dead code |
53
+ | Agent 3: Performance & Efficiency | N+1 queries, memory leaks, unnecessary re-renders, bundle size |
54
+ | Agent 4: Undirected Audit | Business logic, boundary interactions, hidden coupling |
55
+ | Agent 5: Build & Test | Runs build and test commands, reports failures |
56
+
57
+ All agents run in parallel. Findings from Agents 1-4 are verified in a **single batch verification pass** (one agent reviews all findings at once, keeping LLM calls fixed). After verification, a **reverse audit agent** re-reads the entire diff with knowledge of all confirmed findings to catch issues that every other agent missed. Reverse audit findings skip the verification step (the agent already has full context) and are included directly as high-confidence results.
58
+
59
+ ## Deterministic Analysis
60
+
61
+ Before the LLM agents run, `/review` automatically runs your project's existing linters and type checkers:
62
+
63
+ | Language | Tools detected |
64
+ | --------------------- | ---------------------------------------------------------------- |
65
+ | TypeScript/JavaScript | `tsc --noEmit`, `npm run lint`, `eslint` |
66
+ | Python | `ruff`, `mypy`, `flake8` |
67
+ | Rust | `cargo clippy` |
68
+ | Go | `go vet`, `golangci-lint` |
69
+ | Java | `mvn compile`, `checkstyle`, `spotbugs`, `pmd` |
70
+ | C/C++ | `clang-tidy` (if `compile_commands.json` available) |
71
+ | Other | Auto-discovered from CI config (`.github/workflows/*.yml`, etc.) |
72
+
73
+ For projects that don't match standard patterns (e.g., OpenJDK), `/review` reads CI configuration files to discover what lint/check commands the project uses. No user configuration needed.
74
+
75
+ Deterministic findings are tagged with `[linter]` or `[typecheck]` and skip LLM verification — they are ground truth.
76
+
77
+ - **Errors** → Critical severity
78
+ - **Warnings** → Nice to have (terminal only, not posted as PR comments)
79
+
80
+ If a tool is not installed or times out, it is skipped with an informational note.
81
+
82
+ ## Severity Levels
83
+
84
+ | Severity | Meaning | Posted as PR comment? |
85
+ | ---------------- | ------------------------------------------------------------------- | -------------------------- |
86
+ | **Critical** | Must fix before merging (bugs, security, data loss, build failures) | Yes (high-confidence only) |
87
+ | **Suggestion** | Recommended improvement | Yes (high-confidence only) |
88
+ | **Nice to have** | Optional optimization | No (terminal only) |
89
+
90
+ Low-confidence findings appear in a separate "Needs Human Review" section in the terminal and are never posted as PR comments.
91
+
92
+ ## Autofix
93
+
94
+ After presenting findings, `/review` offers to auto-apply fixes for Critical and Suggestion findings that have clear solutions:
95
+
96
+ ```
97
+ Found 3 issues with auto-fixable suggestions. Apply auto-fixes? (y/n)
98
+ ```
99
+
100
+ - Fixes are applied using the `edit` tool (targeted replacements, not full-file rewrites)
101
+ - Per-file linter checks run after fixes to verify they don't introduce new issues
102
+ - For PR reviews, fixes are committed and pushed from the worktree automatically — your working tree stays clean
103
+ - Nice to have and low-confidence findings are never auto-fixed
104
+ - PR review submission always uses the **pre-fix verdict** (e.g., "Request changes") since the remote PR hasn't been updated until the autofix push completes
105
+
106
+ ## Worktree Isolation
107
+
108
+ When reviewing a PR, `/review` creates a temporary git worktree (`.qwen/tmp/review-pr-<number>`) instead of switching your current branch. This means:
109
+
110
+ - Your working tree, staged changes, and current branch are **never touched**
111
+ - Dependencies are installed in the worktree (`npm ci`, etc.) so linting and build/test work
112
+ - Build and test commands run in isolation without polluting your local build cache
113
+ - If anything goes wrong, your environment is unaffected — just delete the worktree
114
+ - The worktree is automatically cleaned up after the review completes
115
+ - If a review is interrupted (Ctrl+C, crash), the next `/review` of the same PR automatically cleans up the stale worktree before starting fresh
116
+ - Review reports and cache are saved to the main project directory (not the worktree)
117
+
118
+ ## Cross-repo PR Review
119
+
120
+ You can review PRs from other repositories by passing the full URL:
121
+
122
+ ```bash
123
+ /review https://github.com/other-org/other-repo/pull/456
124
+ ```
125
+
126
+ This runs in **lightweight mode** — no worktree, no linter, no build/test, no autofix. The review is based on the diff text only (fetched via GitHub API). PR comments can still be posted if you have write access.
127
+
128
+ | Capability | Same-repo | Cross-repo |
129
+ | ------------------------------------------------ | --------- | ----------------------------- |
130
+ | LLM review (Agents 1-4 + verify + reverse audit) | ✅ | ✅ |
131
+ | Agent 5: Build & test | ✅ | ❌ (no local codebase) |
132
+ | Deterministic analysis (linter/typecheck) | ✅ | ❌ |
133
+ | Cross-file impact analysis | ✅ | ❌ |
134
+ | Autofix | ✅ | ❌ |
135
+ | PR inline comments | ✅ | ✅ (if you have write access) |
136
+ | Incremental review cache | ✅ | ❌ |
137
+
138
+ ## PR Inline Comments
139
+
140
+ Use `--comment` to post findings directly on the PR:
141
+
142
+ ```bash
143
+ /review 123 --comment
144
+ ```
145
+
146
+ Or, after running `/review 123`, type `post comments` to publish findings without re-running the review.
147
+
148
+ **What gets posted:**
149
+
150
+ - High-confidence Critical and Suggestion findings as inline comments on specific lines
151
+ - For Approve/Request changes verdicts: a review summary with the verdict
152
+ - For Comment verdict with all inline comments posted: no separate summary (inline comments are sufficient)
153
+ - Model attribution footer on each comment (e.g., _— qwen3-coder via Qwen Code /review_)
154
+
155
+ **What stays terminal-only:**
156
+
157
+ - Nice to have findings (including linter warnings)
158
+ - Low-confidence findings
159
+
160
+ ## Follow-up Actions
161
+
162
+ After the review, context-aware tips appear as ghost text. Press Tab to accept:
163
+
164
+ | State after review | Tip | What happens |
165
+ | ---------------------------------- | ------------------ | --------------------------------------- |
166
+ | Local review with unfixed findings | `fix these issues` | LLM interactively fixes each finding |
167
+ | PR review with findings | `post comments` | Posts PR inline comments (no re-review) |
168
+ | PR review, zero findings | `post comments` | Approves the PR on GitHub (LGTM) |
169
+ | Local review, all clear | `commit` | Commits your changes |
170
+
171
+ Note: `fix these issues` is only available for local reviews. For PR reviews, use Autofix (Step 8) — the worktree is cleaned up after the review, so post-review interactive fixing is not possible.
172
+
173
+ ## Project Review Rules
174
+
175
+ You can customize review criteria per project. `/review` reads rules from these files (in order):
176
+
177
+ 1. `.qwen/review-rules.md` (Qwen Code native)
178
+ 2. `.github/copilot-instructions.md` (preferred) or `copilot-instructions.md` (fallback — only one is loaded, not both)
179
+ 3. `AGENTS.md` — `## Code Review` section
180
+ 4. `QWEN.md` — `## Code Review` section
181
+
182
+ Rules are injected into the LLM review agents (1-4) as additional criteria. For PR reviews, rules are read from the **base branch** to prevent a malicious PR from injecting bypass rules.
183
+
184
+ Example `.qwen/review-rules.md`:
185
+
186
+ ```markdown
187
+ # Review Rules
188
+
189
+ - All API endpoints must validate authentication
190
+ - Database queries must use parameterized statements
191
+ - React components must not use inline styles
192
+ - Error messages must not expose internal paths
193
+ ```
194
+
195
+ ## Incremental Review
196
+
197
+ When reviewing a PR that was previously reviewed, `/review` only examines changes since the last review:
198
+
199
+ ```bash
200
+ # First review — full review, cache created
201
+ /review 123
202
+
203
+ # PR updated with new commits — only new changes reviewed
204
+ /review 123
205
+ ```
206
+
207
+ ### Cross-model review
208
+
209
+ If you switch models (via `/model`) and re-review the same PR, `/review` detects the model change and runs a full review instead of skipping:
210
+
211
+ ```bash
212
+ # Review with model A
213
+ /review 123
214
+
215
+ # Switch model
216
+ /model
217
+
218
+ # Review again — full review with model B (not skipped)
219
+ /review 123
220
+ # → "Previous review used qwen3-coder. Running full review with gpt-4o for a second opinion."
221
+ ```
222
+
223
+ Cache is stored in `.qwen/review-cache/` and tracks both the commit SHA and model ID. Make sure this directory is in your `.gitignore` (a broader rule like `.qwen/*` also works). If the cached commit was rebased away, it falls back to a full review.
224
+
225
+ ## Review Reports
226
+
227
+ For same-repo reviews, results are saved as a Markdown file in your project's `.qwen/reviews/` directory (cross-repo lightweight reviews skip report persistence):
228
+
229
+ ```
230
+ .qwen/reviews/2026-04-06-143022-pr-123.md
231
+ .qwen/reviews/2026-04-06-150510-local.md
232
+ ```
233
+
234
+ Reports include: timestamp, diff stats, deterministic analysis results, all findings with verification status, and the verdict.
235
+
236
+ ## Cross-file Impact Analysis
237
+
238
+ When code changes modify exported functions, classes, or interfaces, the review agents automatically search for all callers and check compatibility:
239
+
240
+ - Parameter count/type changes
241
+ - Return type changes
242
+ - Removed or renamed public methods
243
+ - Breaking API changes
244
+
245
+ For large diffs (>10 modified symbols), analysis prioritizes functions with signature changes.
246
+
247
+ ## Token Efficiency
248
+
249
+ The review pipeline uses a fixed number of LLM calls regardless of how many findings are produced:
250
+
251
+ | Stage | LLM calls | Notes |
252
+ | ------------------------------- | ---------- | --------------------------------------------------- |
253
+ | Deterministic analysis (Step 3) | 0 | Shell commands only |
254
+ | Review agents (Step 4) | 5 (or 4) | Run in parallel; Agent 5 skipped in cross-repo mode |
255
+ | Batch verification (Step 5) | 1 | Single agent verifies all findings at once |
256
+ | Reverse audit (Step 6) | 1 | Finds coverage gaps; findings skip verification |
257
+ | **Total** | **7 or 6** | Same-repo: 7; cross-repo: 6 (no Agent 5) |
258
+
259
+ ## What's NOT Flagged
260
+
261
+ The review intentionally excludes:
262
+
263
+ - Pre-existing issues in unchanged code (focus on the diff only)
264
+ - Style/formatting/naming that matches your codebase conventions
265
+ - Issues a linter or type checker would catch (handled by deterministic analysis)
266
+ - Subjective "consider doing X" suggestions without a real problem
267
+ - Minor refactoring that doesn't fix a bug or risk
268
+ - Missing documentation unless the logic is genuinely confusing
269
+ - Issues already discussed in existing PR comments (avoids duplicating human feedback)
270
+
271
+ ## Design Philosophy
272
+
273
+ > **Silence is better than noise.** Every comment should be worth the reader's time.
274
+
275
+ - If unsure whether something is a problem → don't report it
276
+ - Linter/typecheck issues are handled by tools, not LLM guesses
277
+ - Same pattern across N files → aggregated into one finding
278
+ - PR comments are high-confidence only
279
+ - Style/formatting issues matching codebase conventions are excluded
@@ -61,6 +61,7 @@ Commands for managing AI tools and models.
61
61
  | `/mcp` | List configured MCP servers and tools | `/mcp`, `/mcp desc` |
62
62
  | `/tools` | Display currently available tool list | `/tools`, `/tools desc` |
63
63
  | `/skills` | List and run available skills | `/skills`, `/skills <name>` |
64
+ | `/plan` | Switch to plan mode or exit plan mode | `/plan`, `/plan <task>`, `/plan exit` |
64
65
  | `/approval-mode` | Change approval mode for tool usage | `/approval-mode <mode (auto-edit)> --project` |
65
66
  | →`plan` | Analysis only, no execution | Secure review |
66
67
  | →`default` | Require approval for edits | Daily use |
@@ -71,7 +72,19 @@ Commands for managing AI tools and models.
71
72
  | `/extensions` | List all active extensions in current session | `/extensions` |
72
73
  | `/memory` | Manage AI's instruction context | `/memory add Important Info` |
73
74
 
74
- ### 1.5 Side Question (`/btw`)
75
+ ### 1.5 Built-in Skills
76
+
77
+ These commands invoke bundled skills that provide specialized workflows.
78
+
79
+ | Command | Description | Usage Examples |
80
+ | ------------ | ------------------------------------------------------------------- | ------------------------------------------------- |
81
+ | `/review` | Review code changes with 5 parallel agents + deterministic analysis | `/review`, `/review 123`, `/review 123 --comment` |
82
+ | `/loop` | Run a prompt on a recurring schedule | `/loop 5m check the build` |
83
+ | `/qc-helper` | Answer questions about Qwen Code usage and configuration | `/qc-helper how do I configure MCP?` |
84
+
85
+ See [Code Review](./code-review.md) for full `/review` documentation.
86
+
87
+ ### 1.6 Side Question (`/btw`)
75
88
 
76
89
  The `/btw` command allows you to ask quick side questions without interrupting or affecting the main conversation flow.
77
90
 
@@ -139,7 +152,7 @@ The `/btw` command allows you to ask quick side questions without interrupting o
139
152
  >
140
153
  > Use `/btw` when you need a quick answer without derailing your main task. It's especially useful for clarifying concepts, checking facts, or getting quick explanations while staying focused on your primary workflow.
141
154
 
142
- ### 1.6 Information, Settings, and Help
155
+ ### 1.7 Information, Settings, and Help
143
156
 
144
157
  Commands for obtaining information and performing system settings.
145
158
 
@@ -154,7 +167,7 @@ Commands for obtaining information and performing system settings.
154
167
  | `/copy` | Copy last output content to clipboard | `/copy` |
155
168
  | `/quit` | Exit Qwen Code immediately | `/quit` or `/exit` |
156
169
 
157
- ### 1.7 Common Shortcuts
170
+ ### 1.8 Common Shortcuts
158
171
 
159
172
  | Shortcut | Function | Note |
160
173
  | ------------------ | ----------------------- | ---------------------- |
@@ -164,7 +177,7 @@ Commands for obtaining information and performing system settings.
164
177
  | `Ctrl/cmd+Z` | Undo input | Text editing |
165
178
  | `Ctrl/cmd+Shift+Z` | Redo input | Text editing |
166
179
 
167
- ### 1.8 CLI Auth Subcommands
180
+ ### 1.9 CLI Auth Subcommands
168
181
 
169
182
  In addition to the in-session `/auth` slash command, Qwen Code provides standalone CLI subcommands for managing authentication directly from the terminal:
170
183
 
@@ -12,7 +12,7 @@ After Qwen Code finishes responding, a suggestion appears as dimmed text in the
12
12
  > run the tests
13
13
  ```
14
14
 
15
- The suggestion is generated by sending the conversation history to the model, which predicts what you would naturally type next.
15
+ The suggestion is generated by sending the conversation history to the model, which predicts what you would naturally type next. If the response contains an explicit tip (e.g., `Tip: type post comments to publish findings`), the suggested action is extracted automatically.
16
16
 
17
17
  ## Accepting Suggestions
18
18