plugins/developer-kit-tools/skills/qwen-coder/SKILL.md
Provides Qwen Coder CLI delegation workflows for coding tasks using Qwen2.5-Coder and QwQ models, including English prompt formulation, execution flags, and safe result handling. Use when the user explicitly asks to use Qwen for tasks such as code generation, refactoring, debugging, or architectural analysis. Triggers on "use qwen", "use qwen coder", "delegate to qwen", "ask qwen", "second opinion from qwen", "qwen opinion", "continue with qwen", "qwen session".
npx skillsauth add giuseppe-trisciuoglio/developer-kit qwen-coderInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Delegate selected tasks from Claude Code to Qwen Coder CLI using non-interactive commands, explicit model selection, safe permission flags, and shareable outputs.
This skill standardizes delegation to Qwen Coder CLI (qwen) for cases where Qwen's specific strengths may benefit the task. It covers:
-p / --prompt-m / --model--approval-mode)-c / --continue or -r / --resumetext, json, stream-json)Use this skill only when delegation to Qwen Coder is explicitly requested or clearly beneficial.
Use this skill when:
Trigger phrases:
Verify tool availability and authentication before delegation:
# CLI availability
qwen --version
# Authentication status
qwen auth status
If qwen is unavailable, inform the user and stop execution until Qwen Coder CLI is installed.
If authentication is invalid, provide authentication setup instructions and stop execution.
references/cli-command-reference.mdBefore running Qwen Coder:
If scope is ambiguous, ask for clarification first.
All delegated prompts to Qwen Coder CLI must be in English.
Build a precise English prompt from the user request.
Prompt quality checklist:
Prompt template:
Task: <clear objective>
Context: <project/module/files>
Constraints: <do/don't constraints>
Expected output: <format + depth>
Validation: <tests/checks to run or explain>
Preferred baseline command:
qwen -p "<english-prompt>"
Supported options:
-m, --model <model-id> for model selection (default: qwen2.5-coder)--approval-mode <plan|default|auto_edit|yolo> for safety control-c, --continue <session-id> to continue previous session-r, --resume <session-id> as alias for continue-o, --output-format <text|json|stream-json> for output formatApproval modes:
| Mode | Behavior | Recommended For |
|------|----------|-----------------|
| plan | Read-only analysis, no file modifications | Analysis-only tasks, security reviews |
| default | Requires confirmation before modifications | General coding tasks |
| auto_edit | Auto-approves edit operations | Trusted modifications with oversight |
| yolo | Approves all operations without confirmation | Experimental tasks (explicit user request only) |
Safety guidance:
--approval-mode plan for read-only analysis--approval-mode default for general tasks--yolo for explicit user requests onlyRun the selected command via Bash and capture stdout/stderr.
Examples:
# Default non-interactive delegation
qwen -p "Analyze this code and suggest refactoring improvements."
# Explicit model and approval mode
qwen -p "Review authentication module for security issues with fixes." -m qwq --approval-mode plan
# Continue previous session
qwen -c <session-id> -p "Continue the refactoring from the previous session."
# Structured output for automation
qwen -p "Summarize key technical debt items as JSON array." --output-format json
This section covers how to present Qwen Coder output and when to request user confirmation.
When reporting Qwen Coder output:
Before applying any suggested modifications:
Exception: In --approval-mode yolo with explicit user request, changes may proceed automatically. Still inform the user of what was done.
Each delegation result shall include the following metadata:
| Field | Description | |-------|-------------| | Task summary | What was delegated to Qwen Coder | | Command | The qwen command executed (without sensitive parameters) | | Model | Which model was used (for example qwen2.5-coder, qwq) | | Approval mode | The approval mode applied (plan, default, auto_edit, yolo) | | Key findings | Observations and results from Qwen Coder | | Suggested next actions | Recommended follow-up steps (if applicable) |
Use this structure when returning delegated results:
## Qwen Coder Delegation Result
### Task
[delegated task summary]
### Command
`qwen ...`
### Key Findings
- Finding 1
- Finding 2
### Suggested Next Actions
1. Action 1
2. Action 2
### Notes
- Output language from Qwen: English
- Requires user approval before applying code changes
Input:
Analyze the authentication module and identify security vulnerabilities.
Command:
qwen -p "Analyze the authentication module for security vulnerabilities. Report only high-confidence issues with severity, file paths, and remediation steps." -m qwq --approval-mode plan
Expected behavior:
Returns a structured analysis with high-confidence security findings, including severity ratings and specific remediation recommendations.
Input:
Refactor the payment service to reduce code duplication while keeping the public API unchanged.
Command:
qwen -p "Refactor the payment service in src/services/payment.ts to reduce duplication. Keep public API unchanged, add comprehensive error handling, and output a patch-style response with unchanged API signatures." -m qwen2.5-coder --approval-mode default
Expected behavior:
Proposes concrete code changes (patch-style), extracts duplication into shared helpers, and maintains original API contracts.
Input:
Generate documentation for the UserService class including usage examples.
Command:
qwen -p "Generate comprehensive documentation for the UserService class. Include: class purpose, public methods with parameters, usage examples, and error handling patterns. Format as markdown." -m qwen2.5-coder --approval-mode plan
Expected behavior:
Returns markdown-formatted documentation with JSDoc-style comments, method signatures, and practical usage examples.
Input:
Generate a REST API endpoint for CRUD operations on items.
Command:
qwen -p "Generate a production-ready REST API endpoint for CRUD operations on items. Include input validation, error handling, and unit tests. Use Express.js framework." -m qwen2.5-coder --approval-mode auto_edit
Expected behavior:
Generates complete, runnable code for POST/GET/PUT/DELETE endpoints with proper middleware, validation, and test scaffolding.
Input:
Continue the previous Qwen session to add test coverage to the refactored code.
Command:
qwen -c <session-id> -p "Continue from the previous session. Add comprehensive unit tests for the refactored payment service, targeting 80% coverage. Include mocks for external dependencies." -m qwen2.5-coder --approval-mode default
Expected behavior:
Resumes the previous session context and continues work, adding test files with appropriate mocks and assertions.
Input:
Compare Qwen2.5-Coder and QwQ outputs for the same refactoring task.
Command:
# First run with Qwen2.5-Coder
qwen -p "Refactor the string utility module for better maintainability." -m qwen2.5-coder --approval-mode plan --output-format text
# Then run with QwQ for comparison
qwen -p "Refactor the string utility module for better maintainability." -m qwq --approval-mode plan --output-format text
Expected behavior:
Provides side-by-side comparison: Qwen2.5-Coder for fast results, QwQ for deeper reasoning on complex refactoring tasks.
Input:
List the top 5 refactoring opportunities as JSON for our tracking system.
Command:
qwen -p "Analyze this codebase and return the top 5 refactoring opportunities as a JSON array. Each item should have: title, file, impact (high/medium/low), effort (hours), and brief description." -m qwen2.5-coder --output-format json
Expected behavior:
Returns valid JSON array with 5 refactoring items, parseable for integration with project management tools.
development
Provides security review capability for TypeScript/Node.js applications, validates code against XSS, injection, CSRF, JWT/OAuth2 flaws, dependency CVEs, and secrets exposure. Use when performing security audits, before deployment, reviewing authentication/authorization implementations, or ensuring OWASP compliance for Express, NestJS, and Next.js. Triggers on "security review", "check for security issues", "TypeScript security audit".
development
Provides final code cleanup after task review approval. Removes debug logs, temporary comments, dead code, optimizes imports, and improves readability. Use when asked to clean up code, polish, finalize, tidy up, remove technical debt, or prepare code for completion after review. Not for refactoring logic or fixing bugs—focused solely on cosmetic and hygiene cleanup.
tools
Ralph Wiggum-inspired automation loop for specification-driven development. Orchestrates task implementation, review, cleanup, and synchronization using a Python script. Use when: user runs /loop command, user asks to automate task implementation, user wants to iterate through spec tasks step-by-step, or user wants to run development workflow automation with context window management. One step per invocation. State machine: init → choose_task → implementation → review → fix → cleanup → sync → update_done. Supports --from-task and --to-task for task range filtering. State persisted in fix_plan.json.
testing
Creates, updates, validates, and displays the architectural DNA of a project through two shared documents: docs/specs/architecture.md (technology stack, architectural rules, security constraints, AI guardrails) and docs/specs/ontology.md (domain glossary / Ubiquitous Language). Use BEFORE brainstorm as a project setup step, or at any point in the SDD lifecycle to validate specs/tasks against architecture principles. Triggers on 'create constitution', 'update constitution', 'constitution check', 'validate against constitution', 'project principles', 'architectural guardrails', 'setup project architecture', 'define ontology'.