@qwen-code/qwen-code 0.13.2-preview.0 → 0.14.0-nightly.20260402.a5f17ee39

package/bundled/qc-helper/docs/features/scheduled-tasks.md

@@ -0,0 +1,139 @@
+# Run Prompts on a Schedule
+
+> Use `/loop` and the cron scheduling tools to run prompts repeatedly, poll for status, or set one-time reminders within a Qwen Code session.
+
+Scheduled tasks let Qwen Code re-run a prompt automatically on an interval. Use them to poll a deployment, babysit a PR, check back on a long-running build, or remind yourself to do something later in the session.
+
+Tasks are session-scoped: they live in the current Qwen Code process and are gone when you exit. Nothing is written to disk.
+
+> **Note:** Scheduled tasks are an experimental feature. Enable them with `experimental.cron: true` in your [settings](../configuration/settings.md), or set `QWEN_CODE_ENABLE_CRON=1` in your environment.
+
+## Schedule a recurring prompt with /loop
+
+The `/loop` [bundled skill](skills.md) is the quickest way to schedule a recurring prompt. Pass an optional interval and a prompt, and Qwen Code sets up a cron job that fires in the background while the session stays open.
+
+```text
+/loop 5m check if the deployment finished and tell me what happened
+```
+
+Qwen Code parses the interval, converts it to a cron expression, schedules the job, and confirms the cadence and job ID. It then immediately executes the prompt once — you don't have to wait for the first cron fire.
+
+### Interval syntax
+
+Intervals are optional. You can lead with them, trail with them, or leave them out entirely.
+
+| Form                    | Example                               | Parsed interval              |
+| :---------------------- | :------------------------------------ | :--------------------------- |
+| Leading token           | `/loop 30m check the build`           | every 30 minutes             |
+| Trailing `every` clause | `/loop check the build every 2 hours` | every 2 hours                |
+| No interval             | `/loop check the build`               | defaults to every 10 minutes |
+
+Supported units are `s` for seconds, `m` for minutes, `h` for hours, and `d` for days. Seconds are rounded up to the nearest minute since cron has one-minute granularity. Intervals that don't divide evenly into their unit, such as `7m` or `90m`, are rounded to the nearest clean interval and Qwen Code tells you what it picked.
+
+### Loop over another command
+
+The scheduled prompt can itself be a command or skill invocation. This is useful for re-running a workflow you've already packaged.
+
+```text
+/loop 20m /review-pr 1234
+```
+
+Each time the job fires, Qwen Code runs `/review-pr 1234` as if you had typed it.
+
+### Manage loops
+
+`/loop` also supports two subcommands for managing existing jobs:
+
+```text
+/loop list
+```
+
+Lists all scheduled jobs with their IDs and cron expressions.
+
+```text
+/loop clear
+```
+
+Cancels all scheduled jobs at once.
+
+## Set a one-time reminder
+
+For one-shot reminders, describe what you want in natural language instead of using `/loop`. Qwen Code schedules a single-fire task that deletes itself after running.
+
+```text
+remind me at 3pm to push the release branch
+```
+
+```text
+in 45 minutes, check whether the integration tests passed
+```
+
+Qwen Code pins the fire time to a specific minute and hour using a cron expression and confirms when it will fire.
+
+## Manage scheduled tasks
+
+Ask Qwen Code in natural language to list or cancel tasks, or reference the underlying tools directly.
+
+```text
+what scheduled tasks do I have?
+```
+
+```text
+cancel the deploy check job
+```
+
+Under the hood, Qwen Code uses these tools:
+
+| Tool         | Purpose                                                                                                         |
+| :----------- | :-------------------------------------------------------------------------------------------------------------- |
+| `CronCreate` | Schedule a new task. Accepts a 5-field cron expression, the prompt to run, and whether it recurs or fires once. |
+| `CronList`   | List all scheduled tasks with their IDs, schedules, and prompts.                                                |
+| `CronDelete` | Cancel a task by ID.                                                                                            |
+
+Each scheduled task has an 8-character ID you can pass to `CronDelete`. A session can hold up to 50 scheduled tasks at once.
+
+## How scheduled tasks run
+
+The scheduler checks every second for due tasks and enqueues them when the session is idle. A scheduled prompt fires between your turns, not while Qwen Code is mid-response. If Qwen Code is busy when a task comes due, the prompt waits until the current turn ends.
+
+All times are interpreted in your local timezone. A cron expression like `0 9 * * *` means 9am wherever you're running Qwen Code, not UTC.
+
+### Jitter
+
+To avoid every session hitting the API at the same wall-clock moment, the scheduler adds a small deterministic offset to fire times:
+
+- **Recurring tasks** fire up to 10% of their period late, capped at 15 minutes. An hourly job might fire anywhere from `:00` to `:06`.
+- **One-shot tasks** scheduled for the top or bottom of the hour (minute `:00` or `:30`) fire up to 90 seconds early.
+
+The offset is derived from the task ID, so the same task always gets the same offset. If exact timing matters, pick a minute that is not `:00` or `:30`, for example `3 9 * * *` instead of `0 9 * * *`, and the one-shot jitter will not apply.
+
+### Three-day expiry
+
+Recurring tasks automatically expire 3 days after creation. The task fires one final time, then deletes itself. This bounds how long a forgotten loop can run. If you need a recurring task to last longer, cancel and recreate it before it expires.
+
+One-shot tasks do not expire on a timer — they simply delete themselves after firing once.
+
+## Cron expression reference
+
+`CronCreate` accepts standard 5-field cron expressions: `minute hour day-of-month month day-of-week`. All fields support wildcards (`*`), single values (`5`), steps (`*/15`), ranges (`1-5`), and comma-separated lists (`1,15,30`).
+
+| Example        | Meaning                      |
+| :------------- | :--------------------------- |
+| `*/5 * * * *`  | Every 5 minutes              |
+| `0 * * * *`    | Every hour on the hour       |
+| `7 * * * *`    | Every hour at 7 minutes past |
+| `0 9 * * *`    | Every day at 9am local       |
+| `0 9 * * 1-5`  | Weekdays at 9am local        |
+| `30 14 15 3 *` | March 15 at 2:30pm local     |
+
+Day-of-week uses `0` or `7` for Sunday through `6` for Saturday. When both day-of-month and day-of-week are constrained (neither is `*`), a date matches if either field matches — this follows standard vixie-cron semantics.
+
+Extended syntax like `L`, `W`, `?`, and name aliases such as `MON` or `JAN` is not supported.
+
+## Limitations
+
+Session-scoped scheduling has inherent constraints:
+
+- Tasks only fire while Qwen Code is running and idle. Closing the terminal or letting the session exit cancels everything.
+- No catch-up for missed fires. If a task's scheduled time passes while Qwen Code is busy on a long-running request, it fires once when Qwen Code becomes idle, not once per missed interval.
+- No persistence across restarts. Restarting Qwen Code clears all session-scoped tasks.

package/bundled/qc-helper/docs/features/sub-agents.md

@@ -98,6 +98,7 @@ Subagents are configured using Markdown files with YAML frontmatter. This format
 ---
 name: agent-name
 description: Brief description of when and how to use this agent
+model: inherit # Optional: inherit or model-id
 tools:
 	- tool1
 	- tool2
@@ -106,9 +107,17 @@ tools:
 
 System prompt content goes here.
 Multiple paragraphs are supported.
-You can use ${variable} templating for dynamic content.
 ```
 
+#### Model Selection
+
+Use the optional `model` frontmatter field to control which model a subagent uses:
+
+- `inherit`: Use the same model as the main conversation
+- Omit the field: Same as `inherit`
+- `glm-5`: Use that model ID with the main conversation's auth type
+- `openai:gpt-4o`: Use a different provider (resolves credentials from env vars)
+
 #### Example Usage
 
 ```
@@ -117,12 +126,7 @@ name: project-documenter
 description: Creates project documentation and README files
 ---
 
-You are a documentation specialist for the ${project_name} project.
-
-Your task: ${task_description}
-
-Working directory: ${current_directory}
-Generated on: ${timestamp}
+You are a documentation specialist.
 
 Focus on creating clear, comprehensive documentation that helps both
 new contributors and end users understand the project.
@@ -213,7 +217,7 @@ tools:
   - web_search
 ---
 
-You are a technical documentation specialist for ${project_name}.
+You are a technical documentation specialist.
 
 Your role is to create clear, comprehensive documentation that serves both
 developers and end users. Focus on:

package/bundled/review/SKILL.md

@@ -1,11 +1,12 @@
 ---
 name: review
-description: Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, or `/review <file-path>`.
+description: Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, `/review <file-path>`, or `/review <pr-number> --comment` to post inline comments on the PR.
 allowedTools:
   - task
   - run_shell_command
   - grep_search
   - read_file
+  - write_file
   - glob
 ---
 
@@ -15,7 +16,11 @@ You are an expert code reviewer. Your job is to review code changes and provide
 
 ## Step 1: Determine what to review
 
-Your goal here is to understand the scope of changes so you can dispatch agents effectively in Step 2. Based on the arguments provided:
+Your goal here is to understand the scope of changes so you can dispatch agents effectively in Step 2.
+
+First, parse the `--comment` flag: split the arguments by whitespace, and if any token is exactly `--comment` (not a substring match — ignore tokens like `--commentary`), set the comment flag and remove that token from the argument list. If `--comment` is set but the review target is not a PR, warn the user: "Warning: `--comment` flag is ignored because the review target is not a PR." and continue without it.
+
+Based on the remaining arguments:
 
 - **No arguments**: Review local uncommitted changes
   - Run `git diff` and `git diff --staged` to get all changes
@@ -36,6 +41,20 @@ Launch **four parallel review agents** to analyze the changes from different ang
 
 **IMPORTANT**: Do NOT paste the full diff into each agent's prompt — this duplicates it 4x. Instead, give each agent the command to obtain the diff, a concise summary of what the changes are about, and its review focus. Each agent can read files and search the codebase on its own.
 
+Apply the **Exclusion Criteria** (defined at the end of this document) — do NOT flag anything that matches those criteria.
+
+Each agent must return findings in this structured format (one per issue):
+
+```
+- **File:** <file path>:<line number or range>
+- **Issue:** <clear description of the problem>
+- **Impact:** <why it matters>
+- **Suggested fix:** <concrete code suggestion when possible, or "N/A">
+- **Severity:** Critical | Suggestion | Nice to have
+```
+
+If an agent finds no issues in its dimension, it should explicitly return "No issues found."
+
 ### Agent 1: Correctness & Security
 
 Focus areas:
@@ -80,15 +99,42 @@ Focus areas:
 - Unexpected side effects or hidden coupling
 - Anything else that looks off — trust your instincts
 
-## Step 3: Restore environment and present findings
+## Step 2.5: Deduplicate and verify
+
+### Deduplication
+
+Before verification, merge findings that refer to the same issue (same file, same line range, same root cause) even if reported by different agents. Keep the most detailed description and note which agents flagged it.
+
+### Independent verification
+
+For each **unique** finding, launch an **independent verification agent**. Run verification agents in parallel, but if there are more than 10 unique findings, batch them in groups of 10 to avoid resource exhaustion.
+
+Each verification agent receives:
 
-If you checked out a PR branch in Step 1, restore the original state first: check out the original branch, `git stash pop` if changes were stashed, and remove the temp file.
+- The finding description (what's wrong, file, line)
+- The command to obtain the diff (as determined in Step 1)
+- Access to read files and search the codebase
 
-Then combine results from all four agents into a single, well-organized review. Use this format:
+Each verification agent must **independently** (without seeing other agents' findings):
+
+1. Read the actual code at the referenced file and line
+2. Check surrounding context — callers, type definitions, tests, related modules
+3. Verify the issue is not a false positive — reject if it matches any item in the **Exclusion Criteria**
+4. Return a verdict:
+   - **confirmed** — with severity: Critical, Suggestion, or Nice to have
+   - **rejected** — with a one-line reason why it's not a real issue
+
+**When uncertain, lean toward rejecting.** The goal is high signal, low noise — it's better to miss a minor suggestion than to report a false positive.
+
+**After all verification agents complete:** remove all rejected findings. Only confirmed findings proceed to Step 3.
+
+## Step 3: Present findings
+
+Present the confirmed findings from Step 2.5 as a single, well-organized review. Use this format:
 
 ### Summary
 
-A 1-2 sentence overview of the changes and overall assessment.
+A 1-2 sentence overview of the changes and overall assessment. Include verification stats: "X findings reported, Y confirmed after independent verification."
 
 ### Findings
 
@@ -113,6 +159,98 @@ One of:
 - **Request changes** — Has critical issues that need fixing
 - **Comment** — Has suggestions but no blockers
 
+## Step 4: Post PR inline comments (only if `--comment` flag was set)
+
+Skip this step if `--comment` was not specified or the review target is not a PR.
+
+First, get the repository owner/repo and the PR's HEAD commit SHA:
+
+```bash
+gh repo view --json owner,name --jq '"\(.owner.login)/\(.name)"'
+gh pr view {pr_number} --json headRefOid --jq '.headRefOid'
+```
+
+**Important:** Use `gh pr view --json headRefOid` instead of `git rev-parse HEAD` — the local branch may be behind the remote, and the GitHub API requires the exact remote HEAD SHA. If either command fails, inform the user and skip Step 4.
+
+Then, for each confirmed finding, post an **inline comment** on the specific file and line using `gh api`:
+
+**Shell safety:** Review content may contain double quotes, `$VAR`, backticks, or other shell-sensitive characters. Do NOT interpolate review text directly into shell arguments. Instead, use a **two-step process**: write the body to a temp file using the `write_file` tool (which bypasses shell interpretation entirely), then reference the file with `-F body=@file` in the shell command.
+
+```
+# Step A: Use write_file tool to create /tmp/pr-comment.txt with content:
+**[{severity}]** {issue description}
+
+{suggested fix}
+```
+
+```bash
+# Step B: Post single-line comment referencing the file:
+gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
+  -F body=@/tmp/pr-comment.txt \
+  -f commit_id="{commit_sha}" \
+  -f path="{file_path}" \
+  -F line={line_number} \
+  -f side="RIGHT"
+
+# For multi-line findings (e.g., line range 42-50), add start_line and start_side:
+gh api repos/{owner}/{repo}/pulls/{pr_number}/comments \
+  -F body=@/tmp/pr-comment.txt \
+  -f commit_id="{commit_sha}" \
+  -f path="{file_path}" \
+  -F start_line={start_line} \
+  -F line={end_line} \
+  -f start_side="RIGHT" \
+  -f side="RIGHT"
+```
+
+Repeat Steps A-B for each finding, overwriting the temp file each time. Clean up the temp file in Step 5.
+
+If posting an inline comment fails (e.g., line not part of the diff, auth error), include the finding in the overall review summary comment instead.
+
+**Important rules:**
+
+- Only post **ONE comment per unique issue** — do not duplicate across lines
+- Keep each comment concise and actionable
+- Include the severity tag (Critical/Suggestion/Nice to have) at the start of each comment
+- Include the suggested fix in the comment body when available
+
+After posting all inline comments, use `write_file` to create `/tmp/pr-review-summary.txt` with the summary text, then submit the review using the action that matches the verdict from Step 3:
+
+```bash
+# Submit review with the matching action:
+# If verdict is "Approve":
+gh pr review {pr_number} --approve --body-file /tmp/pr-review-summary.txt
+
+# If verdict is "Request changes":
+gh pr review {pr_number} --request-changes --body-file /tmp/pr-review-summary.txt
+
+# If verdict is "Comment":
+gh pr review {pr_number} --comment --body-file /tmp/pr-review-summary.txt
+```
+
+If there are **no confirmed findings**:
+
+```bash
+gh pr review {pr_number} --approve --body "No issues found. LGTM! ✅"
+```
+
+## Step 5: Restore environment
+
+If you checked out a PR branch in Step 1, restore the original state now: check out the original branch, `git stash pop` if changes were stashed, and remove all temp files (`/tmp/pr-review-context.md`, `/tmp/pr-comment.txt`, `/tmp/pr-review-summary.txt`).
+
+This step runs **after** Step 4 to ensure the PR branch is still checked out when posting inline comments (Step 4 needs the correct commit SHA from the PR branch).
+
+## Exclusion Criteria
+
+These criteria apply to both Step 2 (review agents) and Step 2.5 (verification agents). Do NOT flag or confirm any finding that matches:
+
+- Pre-existing issues in unchanged code (focus on the diff only)
+- Style, formatting, or naming that matches surrounding codebase conventions
+- Pedantic nitpicks that a senior engineer would not flag
+- Issues that a linter or type checker would catch automatically
+- Subjective "consider doing X" suggestions that aren't real problems
+- If you're unsure whether something is a problem, do NOT report it
+
 ## Guidelines
 
 - Be specific and actionable. Avoid vague feedback like "could be improved."