Code Review

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

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):

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 ${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:

   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)

## 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)

## 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 ${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