feat(vscode): expose /skills as slash command with secondary picker (#2548)

* feat(vscode): expose /skills as slash command with secondary picker

Add a secondary completion picker for the /skills slash command in the
VSCode IDE companion, allowing users to browse and select skills from
a dropdown before sending.

Changes:
- CLI: add 'skills' to ALLOWED_BUILTIN_COMMANDS_NON_INTERACTIVE whitelist
- CLI: send available_skills_update via ACP with skill names/descriptions
- Extension: handle available_skills_update in session update handler
- Webview: implement secondary picker that triggers after selecting /skills
- Webview: allow spaces in completion trigger for /skills sub-queries

Closes #1562

Made-with: Cursor

* feat(vscode-ide-companion): embed skills in commands update metadata

- Move available skills from separate session update to _meta field of
  available_commands_update for more efficient delivery
- Simplify skill data to just skill names (string array)
- Add skillsCompletion utility for secondary picker logic
- Cache available skills in WebViewProvider for replay on webview ready
- Update all related types and handlers to support the new structure

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

* refactor(vscode-ide-companion): simplify skills picker flow

* refactor(vscode-ide-companion): extract skills completion utils to shared module

Move `isSkillsSecondaryQuery`, `shouldOpenSkillsSecondaryPicker`, and
`SKILL_ITEM_ID_PREFIX` from App.tsx and useCompletionTrigger.ts into a
shared `completionUtils.ts` file to eliminate duplication.

* fix(vscode-ide-companion): restore skills picker state on reload

Cache and replay available skills when the webview becomes ready again.

Clear stale skills when commands metadata does not include availableSkills.

* fix(vscode-ide-companion): replay slash commands after webview reload

Cache available commands in the webview provider.

Replay them on webviewReady so slash command state survives reloads.

* fix(vscode-ide-companion): import AvailableCommand from ACP SDK

* fix(vscode-ide-companion): fallback /skills to direct command

* test(vscode-ide-companion): cover skills secondary picker flow

* test(vscode-ide-companion): guard App mock initialization

* fix(vscode-ide-companion): remove duplicate AvailableCommand import

The auto-merge introduced a duplicate AvailableCommand in the
@agentclientprotocol/sdk import block, causing TS2300.

* fix(vscode-ide-companion): remove duplicate availableCommands replay in handleWebviewReady

The handleWebviewReady method was sending cachedAvailableCommands twice
on every webview-ready handshake, causing an unnecessary extra state
update in the webview.

---------

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

.qwen/agents/test-engineer.md

@@ -33,15 +33,15 @@ Your sole responsibility is to **reproduce bugs** and **verify fixes**.
 ## Critical constraints
 
 1.  **You must NEVER fix the bug.** Your job ends at confirming the bug exists
-   or confirming a fix works. You do not propose fixes, apply patches, or modify
-   source code in any way that changes the product's behavior.
+    or confirming a fix works. You do not propose fixes, apply patches, or modify
+    source code in any way that changes the product's behavior.
 
 2.  **You must NEVER use Edit or WriteFile on source files.** You have edit and
-   write_file tools for two purposes only: updating the issue file with your
-   report, and writing test scripts as a fallback reproduction method (step 3b
-   below). Any use of these tools on project source code is forbidden. If you
-   find yourself tempted to "just fix this one thing" — stop and report back
-   instead.
+    write_file tools for two purposes only: updating the issue file with your
+    report, and writing test scripts as a fallback reproduction method (step 3b
+    below). Any use of these tools on project source code is forbidden. If you
+    find yourself tempted to "just fix this one thing" — stop and report back
+    instead.
 
 ## Issue file
 
@@ -57,22 +57,23 @@ can read your findings without relying on the agent return message.
 Follow these steps:
 
 1.  **Understand the issue.** Read the issue file. Identify reported behavior,
-   expected behavior, and any reproduction steps the reporter included.
+    expected behavior, and any reproduction steps the reporter included.
 
 2.  **Study the feature.** Read the relevant documentation (`docs/`, READMEs)
-   and source code to understand how the feature is _supposed_ to work. This is
-   critical — you need enough context to assess complexity and design a
-   reproduction that actually targets the bug.
+    and source code to understand how the feature is _supposed_ to work. This is
+    critical — you need enough context to assess complexity and design a
+    reproduction that actually targets the bug.
 
 3.  **Reproduce the bug.** Always attempt E2E reproduction — no exceptions:
 
 a. **E2E reproduction (required first attempt).** Use the `e2e-testing` skill to
 learn how to run headless and interactive tests, then execute a reproduction:
+
 - **Headless mode**: for logic bugs, tool execution issues, output problems.
 - **Interactive mode (tmux)**: for TUI rendering, keyboard, visual issues.
 - Use the globally installed `qwen` command — this matches what the user
-     ran. Do NOT run `npm run build`, `npm run bundle`, or use
-     `node dist/cli.js` during reproduction.
+  ran. Do NOT run `npm run build`, `npm run bundle`, or use
+  `node dist/cli.js` during reproduction.
 
 b. **Test-script fallback.** Only if E2E reproduction is genuinely impractical
 (e.g., the bug is deep in internal logic with no observable CLI behavior, or the
@@ -89,14 +90,14 @@ The caller will tell you they've applied a fix and built the bundle, and give
 you the issue file path.
 
 1.  Read the issue file to get the issue details and your previous reproduction
-   report.
+    report.
 2.  Use `node dist/cli.js` (not `qwen`) — this tests the local changes.
 3.  Re-run the same reproduction steps that previously triggered the bug.
 4.  Confirm the bug is gone and the basic happy path still works.
 5.  If you originally reproduced via a test script, run that test again to
-   confirm it passes.
+    confirm it passes.
 6.  Update the `## Reproduction report` section of the issue file with the
-   verification result.
+    verification result.
 
 ## Output format
 

.qwen/commands/qc/code-review.md

@@ -5,11 +5,12 @@ description: Code review a pull request
 You are an expert code reviewer. Follow these steps:
 
 1.  If no PR number is provided in the args, use Bash(\"gh pr list\") to show
-   open PRs
+    open PRs
 2.  If a PR number is provided, use Bash(\"gh pr view <number>\") to get PR
-   details
+    details
 3.  Use Bash(\"gh pr diff <number>\") to get the diff
 4.  Analyze the changes and provide a thorough code review that includes:
+
 - Overview of what the PR does
 - Analysis of code quality and style
 - Specific suggestions for improvements

.qwen/commands/qc/commit.md

@@ -41,9 +41,9 @@ the user, then commit and push.
 - **If current branch is NOT main/master:**
 - Check if branch name matches the staged changes
 - If branch name doesn't match changes, ask user:
-    - "Current branch `<branch>` doesn't seem to match these changes."
-    - "Options: (1) Create a new branch, (2) Commit on current branch"
-    - Wait for user decision
+  - "Current branch `<branch>` doesn't seem to match these changes."
+  - "Options: (1) Create a new branch, (2) Commit on current branch"
+  - Wait for user decision
 
 ### 5. Generate commit message
 

.qwen/commands/qc/create-issue.md

@@ -17,30 +17,35 @@ The user provides a brief description of a feature request or bug report:
 ## Steps
 
 1.  **Understand the request**
+
 - Read the user's description carefully
 - Determine whether this is a feature request or a bug report
 
 2.  **Investigate the codebase**
+
 - Search for relevant code, files, and existing behavior related to the request
 - Build a thorough understanding of how the current system works
 - Identify any related issues or prior art if mentioned
 
 3.  **Draft the issue**
+
 - Write a markdown file for the user to review
 - Use the appropriate template:
-     - Feature request: follow @.github/ISSUE_TEMPLATE/feature_request.yml
-     - Bug report: follow @.github/ISSUE_TEMPLATE/bug_report.yml
+  - Feature request: follow @.github/ISSUE_TEMPLATE/feature_request.yml
+  - Bug report: follow @.github/ISSUE_TEMPLATE/bug_report.yml
 - Write from the user's perspective, not as an implementation spec
 - Keep the language clear and concise, AVOID internal implementation details
 
 4.  **Review with user**
+
 - Present the draft file to the user
 - Iterate on feedback until the user is satisfied
 - Do NOT submit until the user explicitly asks to
 
 5.  **Submit the issue**
+
 - When the user confirms, create the issue using `gh issue create`
 - Apply the appropriate labels:
-     - Feature request: `type/feature-request`, `status/needs-triage`
-     - Bug report: `type/bug`, `status/needs-triage`
+  - Feature request: `type/feature-request`, `status/needs-triage`
+  - Bug report: `type/bug`, `status/needs-triage`
 - Report back the issue URL

.qwen/commands/qc/create-pr.md

@@ -11,15 +11,18 @@ Create a well-structured pull request with proper description and title.
 ## Steps
 
 1.  **Review staged changes**
+
 - Review all staged changes to understand what has been done
 - Do not touch unstaged changes
 
 2.  **Prepare branch**
+
 - Create a new branch with proper name if current branch is main
 - Ensure all changes are committed
 - Push branch to remote
 
 3.  **Write PR description**
+
 - Use PR Template below
 - Summarize changes clearly
 - Include context and motivation
@@ -31,13 +34,14 @@ Create a well-structured pull request with proper description and title.
   Code](https://github.com/QwenLM/qwen-code)", with a line separator
 
 4.  **Set up PR**
+
 - Create PR title and body
 - Submit PR with gh command
 - **If a GitHub token is provided in the user's message**, use it by setting
   the `GH_TOKEN` environment variable:
-     ```bash
-     GH_TOKEN=<provided_token> gh pr create --title "..." --body "..."
-     ```
+  ```bash
+  GH_TOKEN=<provided_token> gh pr create --title "..." --body "..."
+  ```
 - If no token is provided, use the default `gh` authentication
 
 ## PR Template

.qwen/skills/qwen-code-claw/SKILL.md

@@ -65,27 +65,27 @@ To use acpx:
 
 1.  **Install acpx globally** (recommended) or use npx:
 
-   ```bash
-   npm install -g acpx@latest
-   ```
+```bash
+npm install -g acpx@latest
+```
 
 Or without installing:
 
-   ```bash
-   npx acpx@latest
-   ```
+```bash
+npx acpx@latest
+```
 
 2.  **Install the acpx skill** for full reference:
 
-   ```bash
-   npx acpx@latest --skill install acpx
-   ```
+```bash
+npx acpx@latest --skill install acpx
+```
 
 3.  **Read the acpx skill reference** for every command, flag, and workflow
-   pattern: See the [ACPX Reference](#acpx-reference) section below for details
+    pattern: See the [ACPX Reference](#acpx-reference) section below for details
 
 4.  **For complete CLI reference with all options and examples**:
-   https://raw.githubusercontent.com/openclaw/acpx/main/docs/CLI.md
+    https://raw.githubusercontent.com/openclaw/acpx/main/docs/CLI.md
 
 From now on, when you need to delegate work to Qwen Code, use `acpx` instead of
 spawning raw terminal sessions. For example:
@@ -96,7 +96,7 @@ npx acpx@latest qwen "refactor the auth module"
 npx acpx@latest qwen exec "one-shot: summarize this repo"
 ```
 
->  **Tip:** You should typically use the `--approve-all` flag to prevent task
+> **Tip:** You should typically use the `--approve-all` flag to prevent task
 > interruptions.
 
 ## Practical Workflows
@@ -207,17 +207,17 @@ Full reference: `docs/users/configuration/model-providers.md`.
 ### Key Features
 
 - Approval Mode: control tool execution permissions.
-   See `docs/users/features/approval-mode.md`.
+  See `docs/users/features/approval-mode.md`.
 - MCP: Model Context Protocol server integration.
-   See `docs/users/features/mcp.md`.
+  See `docs/users/features/mcp.md`.
 - Skills: reusable skill system via `/skill`.
-   See `docs/users/features/skills.md`.
+  See `docs/users/features/skills.md`.
 - Sub-agents: delegate tasks to specialized agents.
-   See `docs/users/features/sub-agents.md`.
+  See `docs/users/features/sub-agents.md`.
 - Sandbox: secure code execution environment.
-   See `docs/users/features/sandbox.md`.
+  See `docs/users/features/sandbox.md`.
 - Headless: non-interactive or CI mode.
-   See `docs/users/features/headless.md`.
+  See `docs/users/features/headless.md`.
 
 ## ACPX Reference
 
@@ -254,7 +254,7 @@ acpx [global options] <agent> prompt [options] [prompt text...]
 acpx [global options] <agent> exec [options] [prompt text...]
 ```
 
->  **Note:** If prompt text is omitted and stdin is piped, `acpx` reads prompt
+> **Note:** If prompt text is omitted and stdin is piped, `acpx` reads prompt
 > from stdin.
 
 ### Global Options

.qwen/skills/structured-debugging/SKILL.md

@@ -187,8 +187,7 @@ Then apply the fix, remove instrumentation, and verify with a clean run.
 
 ## Worked examples
 
--
-  `examples/headless-bg-agent-empty-stdout.md`
+- `examples/headless-bg-agent-empty-stdout.md`
   — pipe-captured runs all passed; the user's TTY printed nothing. The
   contradiction _was_ the bug. Illustrates _reproduction contradiction is data_
   and _instrument data, not code paths_.

.qwen/skills/terminal-capture/SKILL.md

@@ -32,13 +32,13 @@ node-pty (pseudo-terminal)
 Core files:
 
 - `integration-tests/terminal-capture/terminal-capture.ts`
-   Low-level PTY, xterm.js, and Playwright engine.
+  Low-level PTY, xterm.js, and Playwright engine.
 - `integration-tests/terminal-capture/scenario-runner.ts`
-   Scenario executor for config, interactions, and screenshots.
+  Scenario executor for config, interactions, and screenshots.
 - `integration-tests/terminal-capture/run.ts`
-   CLI entry point for batch scenario runs.
+  CLI entry point for batch scenario runs.
 - `integration-tests/terminal-capture/scenarios/*.ts`
-   Scenario configuration files.
+  Scenario configuration files.
 
 ## Quick Start
 
@@ -226,17 +226,17 @@ This tool is commonly used for visual verification during PR reviews.
 ## Troubleshooting
 
 - Playwright error `browser not found`
-   Cause: browser not installed.
-   Solution: `npx playwright install chromium`.
+  Cause: browser not installed.
+  Solution: `npx playwright install chromium`.
 - Blank screenshot
-   Cause: process starts slowly or build failed.
-   Solution: check build success and the spawn command.
+  Cause: process starts slowly or build failed.
+  Solution: check build success and the spawn command.
 - PTY-related errors
-   Cause: node-pty native module not compiled.
-   Solution: `npm rebuild node-pty`.
+  Cause: node-pty native module not compiled.
+  Solution: `npm rebuild node-pty`.
 - Unstable screenshot output
-   Cause: terminal output not fully rendered.
-   Solution: add scenario wait time.
+  Cause: terminal output not fully rendered.
+  Solution: add scenario wait time.
 
 ## Full ScenarioConfig Type