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