Code Review and Metric Collection
Review the changes and save the metrics data to a local temporary file.
Script Directory
Agent Execution Instructions:
- Determine this SKILL.md file's directory path as
SKILL_DIR - 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):
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
- Load
references/guidelines.mdas the base set of rules. - Check if
AGENTS.mdexists in the project root. If so, load its content. - If
AGENTS.mdis found, extract rules relevant to code review and merge them into the review standard. - Priority rule: When project conventions conflict with
references/guidelines.md, project conventions override. - If no convention files are found, proceed with base guidelines only — do not fail or warn.
- 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 executioninnerHTML/dangerouslySetInnerHTML— XSS vectors- Hardcoded tokens, passwords, API keys
- Sensitive data in
localStorage console.log/console.debugleft 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
- Get staged, unstaged, and untracked changes using Bash:
git status HEAD --short && bash ${SKILL_DIR}/scripts/show-diff.sh` - Analyze code changes to identify issues and store details (FilePath, Line, Suggestion) for subsequent output.
- 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
- 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 - If the user choose "Yes":
- Provide a numbered list of all CRITICAL and HIGH PRIORITY issues.
- 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')"
- Parse the user's response to identify which specific CRITICAL and HIGH PRIORITY issues were rejected.
- Extract the user's reason for each rejected item.
- Calculate
REJECTED_CRITICAL_COUNTandREJECTED_HIGH_COUNT. - Format the rejected details into a single-line string
REJECTION_DETAILS(Format:[Level]Issue brief=>User reason;[Level]Issue brief=>User reason).
- If no issues found or no objections:
REJECTED_CRITICAL_COUNT=0REJECTED_HIGH_COUNT=0REJECTION_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