mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-04-29 04:00:36 +00:00
202be6ec7d
Some checks are pending
Qwen Code CI / Lint (push) Waiting to run
Qwen Code CI / Test (push) Blocked by required conditions
Qwen Code CI / Test-1 (push) Blocked by required conditions
Qwen Code CI / Test-2 (push) Blocked by required conditions
Qwen Code CI / Test-3 (push) Blocked by required conditions
Qwen Code CI / Test-4 (push) Blocked by required conditions
Qwen Code CI / Test-5 (push) Blocked by required conditions
Qwen Code CI / Test-6 (push) Blocked by required conditions
Qwen Code CI / Test-7 (push) Blocked by required conditions
Qwen Code CI / Test-8 (push) Blocked by required conditions
Qwen Code CI / Post Coverage Comment (push) Blocked by required conditions
Qwen Code CI / CodeQL (push) Waiting to run
E2E Tests / E2E Test (Linux) - sandbox:none (push) Waiting to run
E2E Tests / E2E Test (Linux) - sandbox:docker (push) Waiting to run
E2E Tests / E2E Test - macOS (push) Waiting to run
* 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>
51 lines
1.5 KiB
Markdown
51 lines
1.5 KiB
Markdown
---
|
|
description: Draft and submit a GitHub issue based on a user-provided idea
|
|
---
|
|
|
|
# Create Issue
|
|
|
|
## Overview
|
|
|
|
Take the user's idea or bug description, investigate the codebase to understand
|
|
the full context, draft a GitHub issue for review, and submit it once approved.
|
|
|
|
## Input
|
|
|
|
The user provides a brief description of a feature request or bug report:
|
|
{{args}}
|
|
|
|
## 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
|
|
- 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`
|
|
- Report back the issue URL
|