commit-review

WeChat Mini Program native development code submission review

This skill is used to conduct a comprehensive architecture and code quality review before code submission, ensuring compliance with the project's key constraints and best practices.

When to use

Use this skill in the following scenarios:

• Before preparing to submit code (before git commit)
• During code review
• When the user explicitly requests code review
• Keywords: review, 评审, 检查, commit, 提交

Review checklist

🔴 Key architectural constraints (must be followed)

1. Runtime module externalization

The most critical architectural constraint - the runtime module must remain externally referenced and must never be bundled.

Check items:

• Are all references to import ... from 'runtime' or import ... from 'runtime/...' correct
• Whether runtime externalization is correctly configured in vite.config.ts
• No attempt has been made to modify the runtime externalization configuration
• runtime is not included in optimizeDeps.include

2. Dependency installation rules

All new dependencies must be installed as devDependencies

Check items:

• Whether there are newly added dependencies in package.json (should be empty or contain only necessary runtime dependencies)
• Whether all newly installed packages used pnpm i -D command

Correct approach:

# ✅ 正确
pnpm i -D package-name

# ❌ 错误
pnpm i package-name

3. TypeScript mandatory use

All logic files must use TypeScript (.ts); using .js is prohibited

Check items:

• Whether newly added or modified pages/components use .ts files
• Basic type checking to ensure types are correct, with special attention that component props and function parameter types must not use any
• No new .js files have been created (unless they are configuration files)
• Whether type definitions are complete

File structure:

pages/page-name/
├── page-name.ts      ✅ 使用 TypeScript
├── page-name.json
└── page-name.wxml

components/comp-name/
├── comp-name.ts      ✅ 使用 TypeScript
├── comp-name.json
└── comp-name.wxml

4. Tailwind CSS mandatory use

All styles must use Tailwind CSS; creating .wxss files is prohibited

Check items:

• No new .wxss files have been created
• All styles use Tailwind class names in .wxml
• The correct rpx units are used (Tailwind automatically converts rem to rpx)

Correct approach:

<!-- ✅ 正确：使用 Tailwind CSS -->
<view class="flex items-center justify-between px-4 py-2 bg-white rounded-lg">
  <text class="text-base font-medium text-gray-900">标题</text>
</view>

<!-- ❌ 错误：创建 .wxss 文件 -->

🟡 Component development standards

5. Component configuration

All components must set the correct styleIsolation

Check items:

• Whether the component's .json file includes "styleIsolation": "apply-shared"
• Whether the component is correctly declared as "component": true

Correct configuration:

{
  "component": true,
  "styleIsolation": "apply-shared",
  "usingComponents": {}
}

🟢 Performance best practices

6. setData optimization

Use data paths and batch updates

Check items:

• Whether data path updates are used:this.setData({ 'list[0].text': 'new' })
• Whether multiple setData calls are merged
• setData is not called in a loop

Optimization example:

// ❌ 错误：多次调用
this.setData({ name: 'John' })
this.setData({ age: 25 })

// ✅ 正确：合并调用
this.setData({
  name: 'John',
  age: 25
})

// ✅ 正确：使用数据路径
this.setData({ 'list[0].text': 'new' })

7. Component vs Page

Prefer using Component() over Page()

Check items:

• Whether new pages use the Component() constructor
• Only use Page() when necessary

Recommended approach:

// ✅ 推荐：使用 Component
Component({
  data: {},
  methods: {}
})

// ⚠️ 仅在必要时使用 Page
Page({
  data: {},
  onLoad() {}
})

🔵 Common issue checks

8. iOS Date Parsing

iOS does not support the 'YYYY-MM-DD' format

Check items:

• Whether the date string uses .replace(/-/g, '/') for processing

Correct approach:

// ❌ 错误：iOS 会解析失败
new Date('2024-01-01')

// ✅ 正确：兼容 iOS
new Date('2024-01-01'.replace(/-/g, '/'))

10. Icon Usage Standards

iconfont must be used; image files are prohibited

Check items:

• Whether icons use the <text class="icon icon-xxx"></text> format
• No image files such as .png/.jpg have been created for icons

Correct approach:

<!-- ✅ 正确：使用 iconfont -->
<text class="icon icon-arrow-right text-gray-400"></text>

<!-- ❌ 错误：使用图片 -->
<image src="/images/arrow.png"></image>

📦 Build and Release

11. Build Artifact Check

Ensure the correctness of the three output directories

Check items:

• dist/ - Main build output (includes miniprogram_npm)
• dist_miniprogram/ - NPM package distribution (excludes pages, app.js, miniprogram_npm)
• dist_plugin/ - Plugin package (includes plugin.json)

12. Plugin Release Preparation

The dist directory must be cleaned before release

Check items:

• Whether the appid in project.config.json has been updated
• Whether the provider in miniprogram/app.json has been updated
• Whether dist/app.json has been replaced with the plugin configuration
• Whether only necessary files are retained in the dist directory

🔒 Security Check

13. Security Vulnerabilities

Check for common security issues

Check items:

• No command injection risk
• No XSS vulnerabilities (whether user input is correctly escaped)
• No sensitive information leakage (API key, token, etc.)

📝 Code Quality

14. Code Simplicity

Avoid over-engineering

Check items:

• No features have been added that were not requested
• No unnecessary refactoring
• No utility functions have been created for one-off operations
• No unnecessary error handling has been added
• No unused type definitions or comments have been added

15. Backward Compatibility

Avoid compatibility hacks

Check items:

• No unused variables have been renamed to _var
• No // removed comments have been added for deleted code
• No unused types have been re-exported
• Unused code has been completely removed

Review Process

1. Read changed files

   git diff --cached --name-only
   git diff --cached
   

2. Check the checklist item by item

   • Verify item by item according to the above checklist
   • Mark 🔴 critical issues (must be fixed)
   • Mark 🟡 warning issues (recommended to fix)
   • Mark 🟢 optimization suggestions (optional)

3. Generate review report

   • List all discovered issues
   • Provide specific fix suggestions
   • Give code examples

4. Fix confirmation

   • If there are issues, require another review after fixing
   • If passed, allow submission

Review Report Template

## 代码评审报告

### 📊 概览
- 变更文件数：X
- 新增行数：+X
- 删除行数：-X

### 🔴 关键问题（必须修复）
1. [问题描述]
   - 文件：path/to/file.ts:行号
   - 原因：[说明]
   - 修复建议：[具体方案]

### 🟡 警告问题（建议修复）
1. [问题描述]
   - 文件：path/to/file.ts:行号
   - 建议：[优化方案]

### 🟢 优化建议（可选）
1. [建议描述]

### ✅ 评审结论
- [ ] 通过，可以提交
- [ ] 需要修复后重新评审

Usage Example

# 用户准备提交代码
git add .

# 触发评审
"请评审我的代码"
"review my changes"
"检查代码是否符合规范"

Notes

1. Strictly enforce critical constraints - Issues marked 🔴 must be fixed
2. Provide specific suggestions - Not only point out the problem, but also provide a solution
3. Cite specific locations - Use file:line format to cite code locations
4. Stay objective - Review based on specifications, do not make subjective judgments
5. Prioritize - Address critical issues first, then handle optimization suggestions