@protolabsai/proto 0.14.0

package/dist/bundled/qc-helper/docs/features/arena.md

@@ -0,0 +1,218 @@
+# Agent Arena
+
+> Dispatch multiple AI models simultaneously to execute the same task, compare their solutions side-by-side, and select the best result to apply to your workspace.
+
+> [!warning]
+> Agent Arena is experimental. It has [known limitations](#limitations) around display modes and session management.
+
+Agent Arena lets you pit multiple AI models against each other on the same task. Each model runs as a fully independent agent in its own isolated Git worktree, so file operations never interfere. When all agents finish, you compare results and select a winner to merge back into your main workspace.
+
+Unlike [subagents](/users/features/sub-agents), which delegate focused subtasks within a single session, Arena agents are complete, top-level agent instances — each with its own model, context window, and full tool access.
+
+This page covers:
+
+- [When to use Agent Arena](#when-to-use-agent-arena)
+- [Starting an arena session](#start-an-arena-session)
+- [Interacting with agents](#interact-with-agents), including display modes and navigation
+- [Comparing results and selecting a winner](#compare-results-and-select-a-winner)
+- [Best practices](#best-practices)
+
+## When to use Agent Arena
+
+Agent Arena is most effective when you want to **evaluate or compare** how different models tackle the same problem. The strongest use cases are:
+
+- **Model benchmarking**: Evaluate different models' capabilities on real tasks in your actual codebase, not synthetic benchmarks
+- **Best-of-N selection**: Get multiple independent solutions and pick the best implementation
+- **Exploring approaches**: See how different models reason about and solve the same problem — useful for learning and insight
+- **Risk reduction**: For critical changes, validate that multiple models converge on a similar approach before committing
+
+Agent Arena uses significantly more tokens than a single session (each agent has its own context window and model calls). It works best when the value of comparison justifies the cost. For routine tasks where you trust your default model, a single session is more efficient.
+
+## Start an arena session
+
+Use the `/arena` slash command to launch a session. Specify the models you want to compete and the task:
+
+```
+/arena --models qwen3.5-plus,glm-5,kimi-k2.5 "Refactor the authentication module to use JWT tokens"
+```
+
+If you omit `--models`, an interactive model selection dialog appears, letting you pick from your configured providers.
+
+### What happens when you start
+
+1. **Worktree setup**: Qwen Code creates isolated Git worktrees for each agent at `~/.qwen/arena/<session-id>/worktrees/<model-name>/`. Each worktree mirrors your current working directory state exactly — including staged changes, unstaged changes, and untracked files.
+2. **Agent spawning**: Each agent starts in its own worktree with full tool access and its configured model. Agents are launched sequentially but execute in parallel.
+3. **Execution**: All agents work on the task independently with no shared state or communication. You can monitor their progress and interact with any of them.
+4. **Completion**: When all agents finish (or fail), you enter the result comparison phase.
+
+## Interact with agents
+
+### Display modes
+
+Agent Arena currently supports **in-process mode**, where all agents run asynchronously within the same terminal process. A tab bar at the bottom of the terminal lets you switch between agents.
+
+> [!note]
+> **Split-pane display modes are planned for the future.** We intend to support tmux-based and iTerm2-based split-pane layouts, where each agent gets its own terminal pane for true side-by-side viewing. Currently, only in-process tab switching is available.
+
+### Navigate between agents
+
+In in-process mode, use keyboard shortcuts to switch between agent views:
+
+| Shortcut | Action                            |
+| :------- | :-------------------------------- |
+| `Right`  | Switch to the next agent tab      |
+| `Left`   | Switch to the previous agent tab  |
+| `Up`     | Switch focus to the input box     |
+| `Down`   | Switch focus to the agent tab bar |
+
+The tab bar shows each agent's current status:
+
+| Indicator | Meaning                |
+| :-------- | :--------------------- |
+| `●`       | Running or idle        |
+| `✓`       | Completed successfully |
+| `✗`       | Failed                 |
+| `○`       | Cancelled              |
+
+### Interact with individual agents
+
+When viewing an agent's tab, you can:
+
+- **Send messages** — type in the input area to give the agent additional instructions
+- **Approve tool calls** — if an agent requests tool approval, the confirmation dialog appears in its tab
+- **View full history** — scroll through the agent's complete conversation, including model output, tool calls, and results
+
+Each agent is a full, independent session. Anything you can do with the main agent, you can do with an arena agent.
+
+## Compare results and select a winner
+
+When all agents complete, the Arena enters the result comparison phase. You'll see:
+
+- **Status summary**: Which agents succeeded, failed, or were cancelled
+- **Execution metrics**: Duration, rounds of reasoning, token usage, and tool call counts for each agent
+
+A selection dialog presents the successful agents. Choose one to apply its changes to your main workspace, or discard all results.
+
+### What happens when you select a winner
+
+1. The winning agent's changes are extracted as a diff against the baseline
+2. The diff is applied to your main working directory
+3. All worktrees and temporary branches are cleaned up automatically
+
+If you want to inspect results before deciding, each agent's full conversation history is available via the tab bar while the selection dialog is active.
+
+## Configuration
+
+Arena behavior can be customized in [settings.json](/users/configuration/settings):
+
+```json
+{
+  "arena": {
+    "worktreeBaseDir": "~/.qwen/arena",
+    "maxRoundsPerAgent": 50,
+    "timeoutSeconds": 600
+  }
+}
+```
+
+| Setting                   | Description                        | Default         |
+| :------------------------ | :--------------------------------- | :-------------- |
+| `arena.worktreeBaseDir`   | Base directory for arena worktrees | `~/.qwen/arena` |
+| `arena.maxRoundsPerAgent` | Maximum reasoning rounds per agent | `50`            |
+| `arena.timeoutSeconds`    | Timeout for each agent in seconds  | `600`           |
+
+## Best practices
+
+### Choose models that complement each other
+
+Arena is most valuable when you compare models with meaningfully different strengths. For example:
+
+```
+/arena --models qwen3.5-plus,glm-5,kimi-k2.5 "Optimize the database query layer"
+```
+
+Comparing three versions of the same model family yields less insight than comparing across providers.
+
+### Keep tasks self-contained
+
+Arena agents work independently with no communication. Tasks should be fully describable in the prompt without requiring back-and-forth:
+
+**Good**: "Refactor the payment module to use the strategy pattern. Update all tests."
+
+**Less effective**: "Let's discuss how to improve the payment module" — this benefits from conversation, which is better suited to a single session.
+
+### Limit the number of agents
+
+Up to 5 agents can run simultaneously. In practice, 2-3 agents provide the best balance of comparison value to resource cost. More agents means:
+
+- Higher token costs (each agent has its own context window)
+- Longer total execution time
+- More results to compare
+
+Start with 2-3 and scale up only when the comparison value justifies it.
+
+### Use Arena for high-impact decisions
+
+Arena shines when the stakes justify running multiple models:
+
+- Choosing an architecture for a new module
+- Selecting an approach for a complex refactor
+- Validating a critical bug fix from multiple angles
+
+For routine changes like renaming a variable or updating a config file, a single session is faster and cheaper.
+
+## Troubleshooting
+
+### Agents failing to start
+
+- Verify that each model in `--models` is properly configured with valid API credentials
+- Check that your working directory is a Git repository (worktrees require Git)
+- Ensure you have write access to the worktree base directory (`~/.qwen/arena/` by default)
+
+### Worktree creation fails
+
+- Run `git worktree list` to check for stale worktrees from previous sessions
+- Clean up stale worktrees with `git worktree prune`
+- Ensure your Git version supports worktrees (`git --version`, requires Git 2.5+)
+
+### Agent takes too long
+
+- Increase the timeout: set `arena.timeoutSeconds` in settings
+- Reduce task complexity — Arena tasks should be focused and well-defined
+- Lower `arena.maxRoundsPerAgent` if agents are spending too many rounds
+
+### Applying winner fails
+
+- Check for uncommitted changes in your main working directory that might conflict
+- The diff is applied as a patch — merge conflicts are possible if your working directory changed during the session
+
+## Limitations
+
+Agent Arena is experimental. Current limitations:
+
+- **In-process mode only**: Split-pane display via tmux or iTerm2 is not yet available. All agents run within a single terminal window with tab switching.
+- **No diff preview before selection**: You can view each agent's conversation history, but there is no unified diff viewer to compare solutions side-by-side before picking a winner.
+- **No worktree retention**: Worktrees are always cleaned up after selection. There is no option to preserve them for further inspection.
+- **No session resumption**: Arena sessions cannot be resumed after exiting. If you close the terminal mid-session, worktrees remain on disk and must be cleaned up manually via `git worktree prune`.
+- **Maximum 5 agents**: The hard limit of 5 concurrent agents cannot be changed.
+- **Git repository required**: Arena requires a Git repository for worktree isolation. It cannot be used in non-Git directories.
+
+## Comparison with other multi-agent modes
+
+Agent Arena is one of several planned multi-agent modes in Qwen Code. **Agent Team** and **Agent Swarm** are not yet implemented — the table below describes their intended design for reference.
+
+|                   | **Agent Arena**                                        | **Agent Team** (planned)                           | **Agent Swarm** (planned)                                |
+| :---------------- | :----------------------------------------------------- | :------------------------------------------------- | :------------------------------------------------------- |
+| **Goal**          | Competitive: Find the best solution to the _same_ task | Collaborative: Tackle _different_ aspects together | Batch parallel: Dynamically spawn workers for bulk tasks |
+| **Agents**        | Pre-configured models compete independently            | Teammates collaborate with assigned roles          | Workers spawned on-the-fly, destroyed on completion      |
+| **Communication** | No inter-agent communication                           | Direct peer-to-peer messaging                      | One-way: results aggregated by parent                    |
+| **Isolation**     | Full: separate Git worktrees                           | Independent sessions with shared task list         | Lightweight ephemeral context per worker                 |
+| **Output**        | One selected solution applied to workspace             | Synthesized results from multiple perspectives     | Aggregated results from parallel processing              |
+| **Best for**      | Benchmarking, choosing between model approaches        | Research, complex collaboration, cross-layer work  | Batch operations, data processing, map-reduce tasks      |
+
+## Next steps
+
+Explore related approaches for parallel and delegated work:
+
+- **Lightweight delegation**: [Subagents](/users/features/sub-agents) handle focused subtasks within your session — better when you don't need model comparison
+- **Manual parallel sessions**: Run multiple Qwen Code sessions yourself in separate terminals with [Git worktrees](https://git-scm.com/docs/git-worktree) for full manual control

package/dist/bundled/qc-helper/docs/features/checkpointing.md

@@ -0,0 +1,77 @@
+# Checkpointing
+
+Qwen Code includes a Checkpointing feature that automatically saves a snapshot of your project's state before any file modifications are made by AI-powered tools. This allows you to safely experiment with and apply code changes, knowing you can instantly revert back to the state before the tool was run.
+
+## How It Works
+
+When you approve a tool that modifies the file system (like `write_file` or `edit`), the CLI automatically creates a "checkpoint." This checkpoint includes:
+
+1.  **A Git Snapshot:** A commit is made in a special, shadow Git repository located in your home directory (`~/.qwen/history/<project_hash>`). This snapshot captures the complete state of your project files at that moment. It does **not** interfere with your own project's Git repository.
+2.  **Conversation History:** The entire conversation you've had with the agent up to that point is saved.
+3.  **The Tool Call:** The specific tool call that was about to be executed is also stored.
+
+If you want to undo the change or simply go back, you can use the `/restore` command. Restoring a checkpoint will:
+
+- Revert all files in your project to the state captured in the snapshot.
+- Restore the conversation history in the CLI.
+- Re-propose the original tool call, allowing you to run it again, modify it, or simply ignore it.
+
+All checkpoint data, including the Git snapshot and conversation history, is stored locally on your machine. The Git snapshot is stored in the shadow repository while the conversation history and tool calls are saved in a JSON file in your project's temporary directory, typically located at `~/.qwen/tmp/<project_hash>/checkpoints`.
+
+## Enabling the Feature
+
+The Checkpointing feature is disabled by default. To enable it, you can either use a command-line flag or edit your `settings.json` file.
+
+### Using the Command-Line Flag
+
+You can enable checkpointing for the current session by using the `--checkpointing` flag when starting Qwen Code:
+
+```bash
+qwen --checkpointing
+```
+
+### Using the `settings.json` File
+
+To enable checkpointing by default for all sessions, you need to edit your `settings.json` file.
+
+Add the following key to your `settings.json`:
+
+```json
+{
+  "general": {
+    "checkpointing": {
+      "enabled": true
+    }
+  }
+}
+```
+
+## Using the `/restore` Command
+
+Once enabled, checkpoints are created automatically. To manage them, you use the `/restore` command.
+
+### List Available Checkpoints
+
+To see a list of all saved checkpoints for the current project, simply run:
+
+```
+/restore
+```
+
+The CLI will display a list of available checkpoint files. These file names are typically composed of a timestamp, the name of the file being modified, and the name of the tool that was about to be run (e.g., `2025-06-22T10-00-00_000Z-my-file.txt-write_file`).
+
+### Restore a Specific Checkpoint
+
+To restore your project to a specific checkpoint, use the checkpoint file from the list:
+
+```
+/restore <checkpoint_file>
+```
+
+For example:
+
+```
+/restore 2025-06-22T10-00-00_000Z-my-file.txt-write_file
+```
+
+After running the command, your files and conversation will be immediately restored to the state they were in when the checkpoint was created, and the original tool prompt will reappear.

package/dist/bundled/qc-helper/docs/features/commands.md

@@ -0,0 +1,312 @@
+# Commands
+
+This document details all commands supported by Qwen Code, helping you efficiently manage sessions, customize the interface, and control its behavior.
+
+Qwen Code commands are triggered through specific prefixes and fall into three categories:
+
+| Prefix Type                | Function Description                                | Typical Use Case                                                 |
+| -------------------------- | --------------------------------------------------- | ---------------------------------------------------------------- |
+| Slash Commands (`/`)       | Meta-level control of Qwen Code itself              | Managing sessions, modifying settings, getting help              |
+| At Commands (`@`)          | Quickly inject local file content into conversation | Allowing AI to analyze specified files or code under directories |
+| Exclamation Commands (`!`) | Direct interaction with system Shell                | Executing system commands like `git status`, `ls`, etc.          |
+
+## 1. Slash Commands (`/`)
+
+Slash commands are used to manage Qwen Code sessions, interface, and basic behavior.
+
+### 1.1 Session and Project Management
+
+These commands help you save, restore, and summarize work progress.
+
+| Command     | Description                                               | Usage Examples                       |
+| ----------- | --------------------------------------------------------- | ------------------------------------ |
+| `/init`     | Analyze current directory and create initial context file | `/init`                              |
+| `/summary`  | Generate project summary based on conversation history    | `/summary`                           |
+| `/compress` | Replace chat history with summary to save Tokens          | `/compress`                          |
+| `/resume`   | Resume a previous conversation session                    | `/resume`                            |
+| `/restore`  | Restore files to state before tool execution              | `/restore` (list) or `/restore <ID>` |
+
+### 1.2 Interface and Workspace Control
+
+Commands for adjusting interface appearance and work environment.
+
+| Command      | Description                              | Usage Examples                |
+| ------------ | ---------------------------------------- | ----------------------------- |
+| `/clear`     | Clear terminal screen content            | `/clear` (shortcut: `Ctrl+L`) |
+| `/context`   | Show context window usage breakdown      | `/context`                    |
+| `/theme`     | Change Qwen Code visual theme            | `/theme`                      |
+| `/vim`       | Turn input area Vim editing mode on/off  | `/vim`                        |
+| `/directory` | Manage multi-directory support workspace | `/dir add ./src,./tests`      |
+| `/editor`    | Open dialog to select supported editor   | `/editor`                     |
+
+### 1.3 Language Settings
+
+Commands specifically for controlling interface and output language.
+
+| Command               | Description                      | Usage Examples             |
+| --------------------- | -------------------------------- | -------------------------- |
+| `/language`           | View or change language settings | `/language`                |
+| → `ui [language]`     | Set UI interface language        | `/language ui zh-CN`       |
+| → `output [language]` | Set LLM output language          | `/language output Chinese` |
+
+- Available built-in UI languages: `zh-CN` (Simplified Chinese), `en-US` (English), `ru-RU` (Russian), `de-DE` (German)
+- Output language examples: `Chinese`, `English`, `Japanese`, etc.
+
+### 1.4 Tool and Model Management
+
+Commands for managing AI tools and models.
+
+| Command          | Description                                   | Usage Examples                                |
+| ---------------- | --------------------------------------------- | --------------------------------------------- |
+| `/mcp`           | List configured MCP servers and tools         | `/mcp`, `/mcp desc`                           |
+| `/tools`         | Display currently available tool list         | `/tools`, `/tools desc`                       |
+| `/skills`        | List and run available skills                 | `/skills`, `/skills <name>`                   |
+| `/approval-mode` | Change approval mode for tool usage           | `/approval-mode <mode (auto-edit)> --project` |
+| →`plan`          | Analysis only, no execution                   | Secure review                                 |
+| →`default`       | Require approval for edits                    | Daily use                                     |
+| →`auto-edit`     | Automatically approve edits                   | Trusted environment                           |
+| →`yolo`          | Automatically approve all                     | Quick prototyping                             |
+| `/model`         | Switch model used in current session          | `/model`                                      |
+| `/extensions`    | List all active extensions in current session | `/extensions`                                 |
+| `/memory`        | Manage AI's instruction context               | `/memory add Important Info`                  |
+
+### 1.5 Information, Settings, and Help
+
+Commands for obtaining information and performing system settings.
+
+| Command     | Description                                     | Usage Examples                   |
+| ----------- | ----------------------------------------------- | -------------------------------- |
+| `/help`     | Display help information for available commands | `/help` or `/?`                  |
+| `/about`    | Display version information                     | `/about`                         |
+| `/stats`    | Display detailed statistics for current session | `/stats`                         |
+| `/settings` | Open settings editor                            | `/settings`                      |
+| `/auth`     | Change authentication method                    | `/auth`                          |
+| `/bug`      | Submit issue about Qwen Code                    | `/bug Button click unresponsive` |
+| `/copy`     | Copy last output content to clipboard           | `/copy`                          |
+| `/quit`     | Exit Qwen Code immediately                      | `/quit` or `/exit`               |
+
+### 1.6 Common Shortcuts
+
+| Shortcut           | Function                | Note                   |
+| ------------------ | ----------------------- | ---------------------- |
+| `Ctrl/cmd+L`       | Clear screen            | Equivalent to `/clear` |
+| `Ctrl/cmd+T`       | Toggle tool description | MCP tool management    |
+| `Ctrl/cmd+C`×2     | Exit confirmation       | Secure exit mechanism  |
+| `Ctrl/cmd+Z`       | Undo input              | Text editing           |
+| `Ctrl/cmd+Shift+Z` | Redo input              | Text editing           |
+
+### 1.7 CLI Auth Subcommands
+
+In addition to the in-session `/auth` slash command, Qwen Code provides standalone CLI subcommands for managing authentication directly from the terminal:
+
+| Command                                              | Description                                       |
+| ---------------------------------------------------- | ------------------------------------------------- |
+| `qwen auth`                                          | Interactive authentication setup                  |
+| `qwen auth qwen-oauth`                               | Authenticate with Qwen OAuth                      |
+| `qwen auth coding-plan`                              | Authenticate with Alibaba Cloud Coding Plan       |
+| `qwen auth coding-plan --region china --key sk-sp-…` | Non-interactive Coding Plan setup (for scripting) |
+| `qwen auth status`                                   | Show current authentication status                |
+
+> [!tip]
+>
+> These commands run outside of a Qwen Code session. Use them to configure authentication before starting a session, or in scripts and CI environments. See the [Authentication](../configuration/auth) page for full details.
+
+## 2. @ Commands (Introducing Files)
+
+@ commands are used to quickly add local file or directory content to the conversation.
+
+| Command Format      | Description                                  | Examples                                         |
+| ------------------- | -------------------------------------------- | ------------------------------------------------ |
+| `@<file path>`      | Inject content of specified file             | `@src/main.py Please explain this code`          |
+| `@<directory path>` | Recursively read all text files in directory | `@docs/ Summarize content of this document`      |
+| Standalone `@`      | Used when discussing `@` symbol itself       | `@ What is this symbol used for in programming?` |
+
+Note: Spaces in paths need to be escaped with backslash (e.g., `@My\ Documents/file.txt`)
+
+## 3. Exclamation Commands (`!`) - Shell Command Execution
+
+Exclamation commands allow you to execute system commands directly within Qwen Code.
+
+| Command Format     | Description                                                        | Examples                               |
+| ------------------ | ------------------------------------------------------------------ | -------------------------------------- |
+| `!<shell command>` | Execute command in sub-Shell                                       | `!ls -la`, `!git status`               |
+| Standalone `!`     | Switch Shell mode, any input is executed directly as Shell command | `!`(enter) → Input command → `!`(exit) |
+
+Environment Variables: Commands executed via `!` will set the `QWEN_CODE=1` environment variable.
+
+## 4. Custom Commands
+
+Save frequently used prompts as shortcut commands to improve work efficiency and ensure consistency.
+
+> [!note]
+>
+> Custom commands now use Markdown format with optional YAML frontmatter. TOML format is deprecated but still supported for backwards compatibility. When TOML files are detected, an automatic migration prompt will be displayed.
+
+### Quick Overview
+
+| Function         | Description                                | Advantages                             | Priority | Applicable Scenarios                                 |
+| ---------------- | ------------------------------------------ | -------------------------------------- | -------- | ---------------------------------------------------- |
+| Namespace        | Subdirectory creates colon-named commands  | Better command organization            |          |                                                      |
+| Global Commands  | `~/.qwen/commands/`                        | Available in all projects              | Low      | Personal frequently used commands, cross-project use |
+| Project Commands | `<project root directory>/.qwen/commands/` | Project-specific, version-controllable | High     | Team sharing, project-specific commands              |
+
+Priority Rules: Project commands > User commands (project command used when names are same)
+
+### Command Naming Rules
+
+#### File Path to Command Name Mapping Table
+
+| File Location                            | Generated Command | Example Call          |
+| ---------------------------------------- | ----------------- | --------------------- |
+| `~/.qwen/commands/test.md`               | `/test`           | `/test Parameter`     |
+| `<project>/.qwen/commands/git/commit.md` | `/git:commit`     | `/git:commit Message` |
+
+Naming Rules: Path separator (`/` or `\`) converted to colon (`:`)
+
+### Markdown File Format Specification (Recommended)
+
+Custom commands use Markdown files with optional YAML frontmatter:
+
+```markdown
+---
+description: Optional description (displayed in /help)
+---
+
+Your prompt content here.
+Use {{args}} for parameter injection.
+```
+
+| Field         | Required | Description                              | Example                                    |
+| ------------- | -------- | ---------------------------------------- | ------------------------------------------ |
+| `description` | Optional | Command description (displayed in /help) | `description: Code analysis tool`          |
+| Prompt body   | Required | Prompt content sent to model             | Any Markdown content after the frontmatter |
+
+### TOML File Format (Deprecated)
+
+> [!warning]
+>
+> **Deprecated:** TOML format is still supported but will be removed in a future version. Please migrate to Markdown format.
+
+| Field         | Required | Description                              | Example                                    |
+| ------------- | -------- | ---------------------------------------- | ------------------------------------------ |
+| `prompt`      | Required | Prompt content sent to model             | `prompt = "Please analyze code: {{args}}"` |
+| `description` | Optional | Command description (displayed in /help) | `description = "Code analysis tool"`       |
+
+### Parameter Processing Mechanism
+
+| Processing Method            | Syntax             | Applicable Scenarios                 | Security Features                      |
+| ---------------------------- | ------------------ | ------------------------------------ | -------------------------------------- |
+| Context-aware Injection      | `{{args}}`         | Need precise parameter control       | Automatic Shell escaping               |
+| Default Parameter Processing | No special marking | Simple commands, parameter appending | Append as-is                           |
+| Shell Command Injection      | `!{command}`       | Need dynamic content                 | Execution confirmation required before |
+
+#### 1. Context-aware Injection (`{{args}}`)
+
+| Scenario         | TOML Configuration                      | Call Method           | Actual Effect            |
+| ---------------- | --------------------------------------- | --------------------- | ------------------------ |
+| Raw Injection    | `prompt = "Fix: {{args}}"`              | `/fix "Button issue"` | `Fix: "Button issue"`    |
+| In Shell Command | `prompt = "Search: !{grep {{args}} .}"` | `/search "hello"`     | Execute `grep "hello" .` |
+
+#### 2. Default Parameter Processing
+
+| Input Situation | Processing Method                                      | Example                                        |
+| --------------- | ------------------------------------------------------ | ---------------------------------------------- |
+| Has parameters  | Append to end of prompt (separated by two line breaks) | `/cmd parameter` → Original prompt + parameter |
+| No parameters   | Send prompt as is                                      | `/cmd` → Original prompt                       |
+
+🚀 Dynamic Content Injection
+
+| Injection Type        | Syntax         | Processing Order    | Purpose                          |
+| --------------------- | -------------- | ------------------- | -------------------------------- |
+| File Content          | `@{file path}` | Processed first     | Inject static reference files    |
+| Shell Commands        | `!{command}`   | Processed in middle | Inject dynamic execution results |
+| Parameter Replacement | `{{args}}`     | Processed last      | Inject user parameters           |
+
+#### 3. Shell Command Execution (`!{...}`)
+
+| Operation                       | User Interaction     |
+| ------------------------------- | -------------------- |
+| 1. Parse command and parameters | -                    |
+| 2. Automatic Shell escaping     | -                    |
+| 3. Show confirmation dialog     | ✅ User confirmation |
+| 4. Execute command              | -                    |
+| 5. Inject output to prompt      | -                    |
+
+Example: Git Commit Message Generation
+
+````markdown
+---
+description: Generate Commit message based on staged changes
+---
+
+Please generate a Commit message based on the following diff:
+
+```diff
+!{git diff --staged}
+```
+````
+
+#### 4. File Content Injection (`@{...}`)
+
+| File Type    | Support Status         | Processing Method           |
+| ------------ | ---------------------- | --------------------------- |
+| Text Files   | ✅ Full Support        | Directly inject content     |
+| Images/PDF   | ✅ Multi-modal Support | Encode and inject           |
+| Binary Files | ⚠️ Limited Support     | May be skipped or truncated |
+| Directory    | ✅ Recursive Injection | Follow .gitignore rules     |
+
+Example: Code Review Command
+
+```markdown
+---
+description: Code review based on best practices
+---
+
+Review {{args}}, reference standards:
+
+@{docs/code-standards.md}
+```
+
+### Practical Creation Example
+
+#### "Pure Function Refactoring" Command Creation Steps Table
+
+| Operation                     | Command/Code                              |
+| ----------------------------- | ----------------------------------------- |
+| 1. Create directory structure | `mkdir -p ~/.qwen/commands/refactor`      |
+| 2. Create command file        | `touch ~/.qwen/commands/refactor/pure.md` |
+| 3. Edit command content       | Refer to the complete code below.         |
+| 4. Test command               | `@file.js` → `/refactor:pure`             |
+
+```markdown
+---
+description: Refactor code to pure function
+---
+
+Please analyze code in current context, refactor to pure function.
+Requirements:
+
+1. Provide refactored code
+2. Explain key changes and pure function characteristic implementation
+3. Maintain function unchanged
+```
+
+### Custom Command Best Practices Summary
+
+#### Command Design Recommendations Table
+
+| Practice Points      | Recommended Approach                | Avoid                                       |
+| -------------------- | ----------------------------------- | ------------------------------------------- |
+| Command Naming       | Use namespaces for organization     | Avoid overly generic names                  |
+| Parameter Processing | Clearly use `{{args}}`              | Rely on default appending (easy to confuse) |
+| Error Handling       | Utilize Shell error output          | Ignore execution failure                    |
+| File Organization    | Organize by function in directories | All commands in root directory              |
+| Description Field    | Always provide clear description    | Rely on auto-generated description          |
+
+#### Security Features Reminder Table
+
+| Security Mechanism     | Protection Effect          | User Operation         |
+| ---------------------- | -------------------------- | ---------------------- |
+| Shell Escaping         | Prevent command injection  | Automatic processing   |
+| Execution Confirmation | Avoid accidental execution | Dialog confirmation    |
+| Error Reporting        | Help diagnose issues       | View error information |