SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsstaged-changes-review

staged-changes-review

Coding & development

View repository

Updated 10-30 16:21

About this skill

Staged Changes Review

Checklist-driven, deterministic review of Git staged changes. Produces reproducible findings by combining grep-based scanning with closed-question semantic analysis.

Output Requirements

Important: This skill must output all analysis results and recommendations in Chinese.

  • Language: Always reply in Chinese
  • Encoding: UTF-8
  • Style: Professional and concise; findings must include code evidence

Workflow (8 Steps)

Execute steps in strict order: 0 → 0.5 → 1 → 2 → 2.5 → 3 → 4 → 5. Do not skip or reorder any step.

Step 0: Collect Changes

git diff --cached
git diff --cached --stat
git diff --cached --name-status

If no staged changes exist, output "No staged changes; review terminated." and stop.

Step 0.5: Detect Project Profile

Detect the project type once to determine which rule categories to activate.

# Detect framework
python3 -c "
import json, sys
try:
    with open('package.json') as f:
        d = json.load(f)
    deps = {**d.get('dependencies', {}), **d.get('devDependencies', {})}
    if 'next' in deps:
        print('react-nextjs')
    elif 'react' in deps:
        print('react-app')
    else:
        print('generic')
except:
    print('generic')
" 2>/dev/null || echo "generic"

# Count staged file types
git diff --cached --name-only | grep -cE '\.(tsx|jsx)$' || echo 0
git diff --cached --name-only | grep -cE '\.py$' || echo 0

Record the detected profile — it determines active rule categories:

Profile Condition Active Rule Categories
react-nextjs next in dependencies SEC + REACT + PERF + ASYNC + STR + LOGIC/BREAK + BIZ + REPO
react-app react but no next SEC + REACT + ASYNC + STR + LOGIC/BREAK + BIZ + REPO (001-007)
python-generic Python files majority, no package.json SEC + STR + LOGIC/BREAK + BIZ + REPO (001-006)
generic No package.json or detection failed SEC + STR + LOGIC/BREAK + BIZ + REPO (001-006)

REACT-* and PERF-* rules are skipped entirely for python-generic or generic profiles. REPO-007 requires react-nextjs or react-app; REPO-008 requires react-nextjs only. If detection fails, default to generic.

Step 1: Classify Files

Classify every staged file into priority tiers using the rules in references/review-rules.md §1.

  • Assign each file exactly one priority (P0–P4).
  • Skip P4 files entirely — do not read or scan them.
  • Sort remaining files by priority (P0 first, P3 last).
  • Record the file list for the report's "Review Scope" section.

Step 2: Deterministic Scan

For each file (P0 → P3 order), execute every applicable deterministic rule from references/review-rules.md §2.

Execution method:

  1. Use grep patterns from references/language-patterns.md matching the file's language.
  2. Run each grep against the staged diff (git diff --cached -- <file>) or the file itself.
  3. If a pattern matches, record a finding immediately — no subjective filtering.
  4. Use the severity from references/review-rules.md §4 — do NOT modify severity.

MANDATORY: Every rule × file combination must be executed or explicitly marked N/A (wrong file type or inactive profile). Do not skip rules because "they seem unlikely."

Step 2.5: Impact Scope Analysis

For P0/P1 files, run a one-time impact scope assessment and record results for the "Impact Scope" section.

# 1. New/modified exported symbols in staged diff
git diff --cached -U0 -- "*.ts" "*.tsx" | grep -E "^\+export (function|const|class|interface|type)"

# 2. API route changes
git diff --cached --name-only | grep -E "app/api/|pages/api/"

# 3. Server Action changes (security impact)
git diff --cached -- "*.ts" "*.tsx" | grep -E '^[+-].*("use server"|'"'"'use server'"'"')'

# 4. Environment variable changes
git diff --cached -- ".env*" 2>/dev/null | grep -E "^[+-][A-Z_]+" | head -10

For each exported symbol found (up to 5 symbols), check reference count:

# Replace SYMBOL_NAME with actual symbol
grep -rl "SYMBOL_NAME" --include="*.ts" --include="*.tsx" src/ 2>/dev/null | wc -l

If no impact scope items are detected, note "No significant impact scope changes" in the report.

Step 3: Semantic Review

For each file (P0 → P3 order), answer every applicable semantic question from references/review-rules.md §3 and §3b.

Execution method:

  1. Read the file's staged diff and surrounding context (use Read tool for full file when needed).
  2. For each semantic rule, answer the closed question with exactly one of:
    • YES — issue found. MUST provide: file:line + evidence snippet.
    • NO — reviewed, no issue found.
    • N/A — rule does not apply to this file type or change.
  3. Only YES answers produce findings. Use the severity from §4.

BIZ rule execution instructions:

  1. For P1 files, use git show HEAD:<path> to retrieve the pre-change version, and compare it with the staged version for before/after behavior analysis.
  2. BIZ findings must include the "Behavior Before Change", "Behavior After Change", and "Impact Scenarios" fields.
  3. Pure refactoring (logic-equivalent transformation) should not be reported as a behavior change.
  4. Sampling limit: When there are more than 10 P1 files, the BIZ rule analyzes only the first 5 files and notes "剩余 N 个文件未进行 BIZ 分析（采样限制）".

MANDATORY: Answer every question. Do not skip questions because context seems insufficient — answer N/A with a brief reason instead.

Step 4: Merge & Deduplicate

  1. Collect all findings from Steps 2 and 3.
  2. Generate a fingerprint for each finding: {ruleId}:{file}:{line}.
  3. Deduplicate by fingerprint — if the same fingerprint appears from both a deterministic and semantic rule, keep the one with higher severity.
  4. Group findings by severity: CRITICAL → HIGH → MEDIUM → LOW.
  5. Apply output budget limits from references/report-template.md §3.

Step 5: Generate Report

Output the report using the exact structure from references/report-template.md §2.

  1. Review Scope: file counts and rule counts.
  2. Impact Scope: impact scope analysis results.
  3. Business Impact Analysis: Summary table of BIZ findings (changed file / BIZ rule / behavior change summary). If there are no BIZ findings, output "未检测到用户可感知的业务行为变更".
  4. Findings Overview: severity summary table.
  5. Conclusion: auto-select from references/review-rules.md §5 based on highest severity found.
  6. Graded Findings: findings in references/report-template.md §1 format, grouped by severity. BIZ findings are grouped into the corresponding level by severity.
  7. File Review Matrix: per-file summary table.

Execution Constraints (MANDATORY)

These constraints are non-negotiable. Violating any constraint invalidates the review.

  1. No skipping: Every rule must be evaluated against every applicable file. Document N/A explicitly.
  2. No free-form analysis: Only report findings that match a defined rule ID. Do not invent new categories.
  3. Forced answers: Every semantic question must receive YES, NO, or N/A. Leaving a question unanswered is forbidden.
  4. Evidence lock: Every YES finding must cite a specific file:line and include a code snippet. Findings without evidence are invalid.
  5. Severity is immutable: Use the severity from the mapping table. Do not upgrade or downgrade based on subjective judgment.
  6. Conclusion is templated: The conclusion must be one of the four templates in review-rules.md §5. Do not write a custom conclusion.
  7. Fingerprint required: Every finding must include a fingerprint in {ruleId}:{file}:{line} format.

Context Budget Strategy

When staged changes are large (>500 lines or >15 files):

  • P0 files: Always read full content — security-critical.
  • P1 files: Read full diff. If a single file diff >200 lines, focus on: function signatures, exported symbols, error handling blocks, and security-sensitive patterns.
  • P2 files: Read diff only. Focus on SEC rules and BREAK-003/BREAK-004.
  • P3 files: Scan diff headers only. Apply STR rules only.
  • If total context would exceed capacity, process files strictly by priority and stop at capacity with a note: "Remaining N low-priority files not reviewed".

REACT/ASYNC rule sampling limit: For rules that require Read tool for semantic verification (REACT-001, REACT-003, ASYNC-001, ASYNC-002), if grep returns more than 5 matches, take the first 5 matches only and note "N unverified (sampling limit)". This prevents excessive Read tool calls.

Validator Interface Contract

This skill's output is consumed by staged-review-validator. The following fields are required for compatibility:

  • Finding title must include [ruleId] prefix (e.g., [SEC-003] SQL 拼接风险)
  • Each finding must include a 指纹 (Fingerprint) field
  • Severity uses 4 levels: CRITICAL / HIGH / MEDIUM / LOW
  • Report structure follows references/report-template.md §2
  • BIZ-* findings use the before/after format (including the "变更前行为", "变更后行为", "影响场景" fields), see references/report-template.md §1

References

  • references/review-rules.md — Rule definitions, file classification, severity mapping
  • references/report-template.md — Finding format, report structure, output budget
  • references/language-patterns.md — Language-specific grep patterns by rule ID