code-review
Reviews the changes, identifies critical and high-priority issues, generates review summaries, and collects metrics data for local use. Use this when users need to code review or analyzing code changes for quality issues.
What this skill does
# Code Review and Metric Collection
Review the changes and save the metrics data to a local temporary file.
## Script Directory
**Agent Execution Instructions**:
1. Determine this SKILL.md file's directory path as `SKILL_DIR`
2. Script path = `${SKILL_DIR}/scripts/<script-name>.sh`
| Script | Purpose |
| -------------------- | ----------------------------------------------------------------------------------------- |
| `collect-metrics.sh` | Collect git statistics and code review metrics to a local temporary file |
| `show-diff.sh` | Show git diff with exclusions |
| `security-scan.sh` | **Frontend only** — Automated security scan: detects secrets, XSS, eval, hardcoded tokens |
## Workflow
Copy this checklist and check off items as you complete them:
```
- [ ] Step 1: Git Repo verification & Changes confirmation
- [ ] Step 2: Code Review
- [ ] 2.1 Load guidelines
- [ ] 2.2 Security scan (optional — frontend projects only)
- [ ] 2.3 Analyze changes
- [ ] 2.4 Output Result
- [ ] Step 3: User feedback & Validation
- [ ] Step 4: Collect metrics ⚠️ REQUIRED
```
### Step 1: Git Repo verification & Changes confirmation
Ensure if is in a git repository directory and existing changes to review (staged, unstaged, and untracked files):
```bash
if ! git rev-parse --git-dir > /dev/null 2>&1; then
echo "Error: Not a git repository. This command requires git version control."
exit 1
fi
echo "Success: Git repository verified."
if [ -z "$(git status --porcelain)" ]; then
echo "No changes detected. Working tree is clean."
exit 1
else
echo "Changes detected."
fi
```
### Step 2: Code Review
**2.1 Load guidelines**
1. Load `references/guidelines.md` as the base set of rules.
2. Check if `AGENTS.md` exists in the project root. If so, load its content.
3. If `AGENTS.md` is found, extract rules relevant to code review and **merge them into the review standard**.
4. **Priority rule**: When project conventions conflict with `references/guidelines.md`, project conventions override.
5. If no convention files are found, proceed with base guidelines only — do not fail or warn.
6. Record which convention file(s) were loaded and their relevant sections/lines for source attribution in the review output.
**2.2 Security scan** _(optional — frontend projects only)_
> ⚠️ This step is designed for **frontend tech stacks** (JavaScript / TypeScript / React / Vue / Angular). Skip it for backend, infrastructure, or other non-frontend projects.
If applicable, run automated security detection BEFORE manual review. Results feed into CRITICAL findings in Step 2.3.
```bash
bash ${SKILL_DIR}/scripts/security-scan.sh
```
This detects:
- `eval()` / `new Function()` — arbitrary code execution
- `innerHTML` / `dangerouslySetInnerHTML` — XSS vectors
- Hardcoded tokens, passwords, API keys
- Sensitive data in `localStorage`
- `console.log` / `console.debug` left in production code
- HTTP URLs (non-localhost)
- `document.write()` — blocking + XSS
Any match is automatically classified as CRITICAL or HIGH and included in the final output.
**2.3 Analyze changes**
1. Get staged, unstaged, and untracked changes using Bash:
```bash
git status HEAD --short && bash ${SKILL_DIR}/scripts/show-diff.sh`
```
2. Analyze code changes to identify issues and store details (FilePath, Line, Suggestion) for subsequent output.
3. Set initial counts: `CRITICAL_ISSUES_COUNT`, `HIGH_PRIORITY_ISSUES_COUNT`.
**2.4 Output Result**
Show categorized issues to the user, exactly follow one of the two templates:
#### Template A (any findings)
```markdown
## Code review Skill Output
### 🚨 CRITICAL (Must fix)
#### <brief description of CRITICAL issue>
- FilePath: <path>#<line>
- Suggested fix: <brief description of suggested fix>
- Rule source: "AGENTS.md §<Section/line N>" _(show only when the rule comes from AGENTS.md)_
... (repeat for each CRITICAL issue) ...
---
### ⚠️ HIGH PRIORITY (Should fix)
#### <brief description of HIGH PRIORITY issue>
- FilePath: <path>#<line>
- Suggested fix: <brief description of suggested fix>
- Rule source: "AGENTS.md §<Section/line N>" _(show only when the rule comes from AGENTS.md)_
... (repeat for each HIGH PRIORITY issue) ...
---
### 💡 SUGGESTIONS (Consider)
#### <brief description of SUGGESTIONS issue>
- FilePath: <path>#<line>
- Suggested fix: <brief description of suggested fix>
- Rule source: "AGENTS.md §<Section/line N>" _(show only when the rule comes from AGENTS.md)_
... (repeat for each SUGGESTIONS issue) ...
```
#### Template B (no issues)
```markdown
## Code review Skill Output
🎉 Great! No issues found.
```
### Step 3: User feedback & Validation
1. If any issues found, ask the user: "Do you have any objections to the review results?" And two options are provided: `1. Yes, I have objections`、`2. No, proceed to the next step`
2. If the user choose "Yes":
1. Provide a numbered list of all CRITICAL and HIGH PRIORITY issues.
2. Ask the user: "Please select the numbers of the issues you disagree with and briefly explain why (e.g., '1-this is a test file, 3-intentional technical debt')"
3. Parse the user's response to identify which specific CRITICAL and HIGH PRIORITY issues were rejected.
4. Extract the user's reason for each rejected item.
5. Calculate `REJECTED_CRITICAL_COUNT` and `REJECTED_HIGH_COUNT`.
6. Format the rejected details into a single-line string `REJECTION_DETAILS` (Format: `[Level]Issue brief=>User reason;[Level]Issue brief=>User reason`).
3. If no issues found or no objections:
- `REJECTED_CRITICAL_COUNT=0`
- `REJECTED_HIGH_COUNT=0`
- `REJECTION_DETAILS=""`
### Step 4: Collect metrics ⚠️ REQUIRED
```bash
bash ${SKILL_DIR}/scripts/collect-metrics.sh \
"<Brief summary of changes (single-line only, within 100 words)>" \
"<Detailed review summary (single-line only)>" \
"$CRITICAL_ISSUES_COUNT" \
"$HIGH_PRIORITY_ISSUES_COUNT" \
"$REJECTED_CRITICAL_COUNT" \
"$REJECTED_HIGH_COUNT" \
"$REJECTION_DETAILS"
```
## Notes
- Never modify the code after review
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.