mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-04-28 11:41:04 +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>
82 lines
2.3 KiB
Markdown
82 lines
2.3 KiB
Markdown
---
|
|
description: Commit staged changes with an AI-generated commit message and push
|
|
---
|
|
|
|
# Commit and Push
|
|
|
|
## Overview
|
|
|
|
Generate a clear, concise commit message based on staged changes, confirm with
|
|
the user, then commit and push.
|
|
|
|
## Steps
|
|
|
|
### 1. Check repository status
|
|
|
|
- Run `git status` to check:
|
|
- Are there any staged changes?
|
|
- Are there unstaged changes?
|
|
- What is the current branch?
|
|
|
|
### 2. Handle unstaged changes
|
|
|
|
- If there are unstaged changes, notify the user and list them
|
|
- Do NOT add or commit unstaged changes
|
|
- Proceed only with staged changes
|
|
|
|
### 3. Review staged changes
|
|
|
|
- Run `git diff --staged` to see all staged changes
|
|
- Analyze the changes in depth to understand:
|
|
- What files were modified/added/deleted
|
|
- The nature of the changes (feature, fix, refactor, docs, etc.)
|
|
- The scope and impact of the changes
|
|
|
|
### 4. Handle branch logic
|
|
|
|
- Get current branch name with `git branch --show-current`
|
|
- **If current branch is `main` or `master`:**
|
|
- Generate a proper branch name based on the changes
|
|
- Create and switch to the new branch: `git checkout -b <branch-name>`
|
|
- **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
|
|
|
|
### 5. Generate commit message
|
|
|
|
- Types: feat, fix, docs, style, refactor, test, chore
|
|
- Guidelines:
|
|
- Be clear and concise
|
|
- Reference issues if mentioned in changes
|
|
- Include scope in parentheses when applicable (e.g., `fix(insight):`,
|
|
`feat(auth):`)
|
|
- Add bullet points for detailed changes if it addes more value, otherwise do
|
|
not use bullets
|
|
- Include a footer explaining the purpose/impact of the changes
|
|
|
|
**Format:**
|
|
|
|
```
|
|
<type>(<scope>): <short description>
|
|
- <detail point 1> (optional)
|
|
- <detail point 2> (optional)
|
|
- ...
|
|
|
|
This <explains the why/impact of the changes>.
|
|
```
|
|
|
|
### 6. Present the result and confirm with user
|
|
|
|
- Present the generated commit message
|
|
- Show which branch will be used
|
|
- Ask for confirmation: "Proceed with commit and push?"
|
|
- Wait for user approval
|
|
|
|
### 7. Commit and push
|
|
|
|
- After user confirms:
|
|
- `git commit -m "<commit-message>"`
|
|
- `git push -u origin <branch-name>` (use `-u` for new branches)
|