@jaydennleemc/qwen-code-local 0.12.3-beta.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +203 -0
- package/README.md +465 -0
- package/dist/bundled/review/SKILL.md +118 -0
- package/dist/cli.js +457269 -0
- package/dist/sandbox-macos-permissive-closed.sb +32 -0
- package/dist/sandbox-macos-permissive-open.sb +25 -0
- package/dist/sandbox-macos-permissive-proxied.sb +37 -0
- package/dist/sandbox-macos-restrictive-closed.sb +93 -0
- package/dist/sandbox-macos-restrictive-open.sb +96 -0
- package/dist/sandbox-macos-restrictive-proxied.sb +98 -0
- package/dist/vendor/ripgrep/COPYING +3 -0
- package/dist/vendor/ripgrep/arm64-darwin/rg +0 -0
- package/dist/vendor/ripgrep/arm64-linux/rg +0 -0
- package/dist/vendor/ripgrep/x64-darwin/rg +0 -0
- package/dist/vendor/ripgrep/x64-linux/rg +0 -0
- package/dist/vendor/ripgrep/x64-win32/rg.exe +0 -0
- package/package.json +136 -0
|
@@ -0,0 +1,118 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: review
|
|
3
|
+
description: Review changed code for correctness, security, code quality, and performance. Use when the user asks to review code changes, a PR, or specific files. Invoke with `/review`, `/review <pr-number>`, or `/review <file-path>`.
|
|
4
|
+
allowedTools:
|
|
5
|
+
- task
|
|
6
|
+
- run_shell_command
|
|
7
|
+
- grep_search
|
|
8
|
+
- read_file
|
|
9
|
+
- glob
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
# Code Review
|
|
13
|
+
|
|
14
|
+
You are an expert code reviewer. Your job is to review code changes and provide actionable feedback.
|
|
15
|
+
|
|
16
|
+
## Step 1: Determine what to review
|
|
17
|
+
|
|
18
|
+
Based on the arguments provided:
|
|
19
|
+
|
|
20
|
+
- **No arguments**: Review local uncommitted changes
|
|
21
|
+
- Run `git diff` and `git diff --staged` to get all changes
|
|
22
|
+
- If both diffs are empty, inform the user there are no changes to review and stop here — do not proceed to the review agents
|
|
23
|
+
|
|
24
|
+
- **PR number or URL** (e.g., `123` or `https://github.com/.../pull/123`):
|
|
25
|
+
- Run `gh pr view <number>` to get PR details
|
|
26
|
+
- Run `gh pr diff <number>` to get the diff
|
|
27
|
+
|
|
28
|
+
- **File path** (e.g., `src/foo.ts`):
|
|
29
|
+
- Run `git diff HEAD -- <file>` to get recent changes
|
|
30
|
+
- If no diff, read the file and review its current state
|
|
31
|
+
|
|
32
|
+
## Step 2: Parallel multi-dimensional review
|
|
33
|
+
|
|
34
|
+
Launch **four parallel review agents** to analyze the changes from different angles. Each agent should focus exclusively on its dimension.
|
|
35
|
+
|
|
36
|
+
### Agent 1: Correctness & Security
|
|
37
|
+
|
|
38
|
+
Focus areas:
|
|
39
|
+
|
|
40
|
+
- Logic errors and edge cases
|
|
41
|
+
- Null/undefined handling
|
|
42
|
+
- Race conditions and concurrency issues
|
|
43
|
+
- Security vulnerabilities (injection, XSS, SSRF, path traversal, etc.)
|
|
44
|
+
- Type safety issues
|
|
45
|
+
- Error handling gaps
|
|
46
|
+
|
|
47
|
+
### Agent 2: Code Quality
|
|
48
|
+
|
|
49
|
+
Focus areas:
|
|
50
|
+
|
|
51
|
+
- Code style consistency with the surrounding codebase
|
|
52
|
+
- Naming conventions (variables, functions, classes)
|
|
53
|
+
- Code duplication and opportunities for reuse
|
|
54
|
+
- Over-engineering or unnecessary abstraction
|
|
55
|
+
- Missing or misleading comments
|
|
56
|
+
- Dead code
|
|
57
|
+
|
|
58
|
+
### Agent 3: Performance & Efficiency
|
|
59
|
+
|
|
60
|
+
Focus areas:
|
|
61
|
+
|
|
62
|
+
- Performance bottlenecks (N+1 queries, unnecessary loops, etc.)
|
|
63
|
+
- Memory leaks or excessive memory usage
|
|
64
|
+
- Unnecessary re-renders (for UI code)
|
|
65
|
+
- Inefficient algorithms or data structures
|
|
66
|
+
- Missing caching opportunities
|
|
67
|
+
- Bundle size impact
|
|
68
|
+
|
|
69
|
+
### Agent 4: Undirected Audit
|
|
70
|
+
|
|
71
|
+
No preset dimension. Review the code with a completely fresh perspective to catch issues the other three agents may miss.
|
|
72
|
+
Focus areas:
|
|
73
|
+
|
|
74
|
+
- Business logic soundness and correctness of assumptions
|
|
75
|
+
- Boundary interactions between modules or services
|
|
76
|
+
- Implicit assumptions that may break under different conditions
|
|
77
|
+
- Unexpected side effects or hidden coupling
|
|
78
|
+
- Anything else that looks off — trust your instincts
|
|
79
|
+
|
|
80
|
+
## Step 3: Aggregate and present findings
|
|
81
|
+
|
|
82
|
+
Combine results from all four agents into a single, well-organized review. Use this format:
|
|
83
|
+
|
|
84
|
+
### Summary
|
|
85
|
+
|
|
86
|
+
A 1-2 sentence overview of the changes and overall assessment.
|
|
87
|
+
|
|
88
|
+
### Findings
|
|
89
|
+
|
|
90
|
+
Use severity levels:
|
|
91
|
+
|
|
92
|
+
- **Critical** — Must fix before merging. Bugs, security issues, data loss risks.
|
|
93
|
+
- **Suggestion** — Recommended improvement. Better patterns, clearer code, potential issues.
|
|
94
|
+
- **Nice to have** — Optional optimization. Minor style tweaks, small performance gains.
|
|
95
|
+
|
|
96
|
+
For each finding, include:
|
|
97
|
+
|
|
98
|
+
1. **File and line reference** (e.g., `src/foo.ts:42`)
|
|
99
|
+
2. **What's wrong** — Clear description of the issue
|
|
100
|
+
3. **Why it matters** — Impact if not addressed
|
|
101
|
+
4. **Suggested fix** — Concrete code suggestion when possible
|
|
102
|
+
|
|
103
|
+
### Verdict
|
|
104
|
+
|
|
105
|
+
One of:
|
|
106
|
+
|
|
107
|
+
- **Approve** — No critical issues, good to merge
|
|
108
|
+
- **Request changes** — Has critical issues that need fixing
|
|
109
|
+
- **Comment** — Has suggestions but no blockers
|
|
110
|
+
|
|
111
|
+
## Guidelines
|
|
112
|
+
|
|
113
|
+
- Be specific and actionable. Avoid vague feedback like "could be improved."
|
|
114
|
+
- Reference the existing codebase conventions — don't impose external style preferences.
|
|
115
|
+
- Focus on the diff, not pre-existing issues in unchanged code.
|
|
116
|
+
- Keep the review concise. Don't repeat the same point for every occurrence.
|
|
117
|
+
- When suggesting a fix, show the actual code change.
|
|
118
|
+
- Flag any exposed secrets, credentials, API keys, or tokens in the diff as **Critical**.
|