front-end/.cursor/skills/review-and-commit/SKILL.md

---

name: review-and-commit

description: Analyze local Git changes in this front-end monorepo, review Vue2/uni-app implementation quality and risk, run proportionate validation, and create a Conventional Commit with a detailed intent-focused body. Use when the user asks to analyze/review code changes and commit them, create a commit from the current working tree, inspect changes before committing, or says "分析改动及提交 Commit".

Review and Commit

Review the exact change set before creating one intentional, traceable commit. Treat invocation with an explicit commit request as authorization to stage and commit only the relevant local changes, never to push.

Repository Context

This is a multi-product front-end monorepo (uni-app mobile/tablet + desktop Vue). Before reviewing, read AGENTS.md and applicable .cursor/rules/ files.

Products (use as commit scope when clear): hdApp, ghsApp, mallApp, hdPad, ghsPad, hd, ghs.

Each product is independent — do not mix unrelated product changes in one commit unless the user intended a cross-product change.

Workflow

1. Read AGENTS.md and follow project-specific validation and architecture rules.
2. Inspect git status --short, staged and unstaged diffs, diff statistics, and recent commit style.
3. Account for untracked files explicitly because git diff omits their contents. List and read every relevant untracked file.
4. Determine the intended change set. Preserve unrelated user changes and existing staged state. If unrelated changes cannot be separated safely, stop and ask for scope clarification.
5. Identify the target product(s) from changed paths. Flag accidental cross-product edits.
6. Review for correctness, security, compatibility, layering, error handling, and accidental generated or secret files. Identify API wrapper, configuration, dependency, and breaking changes.
7. Do not commit known blocking defects. Report the concrete defect and ask whether to fix it unless the user already authorized implementation. Do not silently rewrite the user's changes merely to make the commit pass.
8. Run proportionate checks for the affected stack (see Validation below).
9. Stage exact paths belonging to the change; avoid git add -A when the worktree contains unrelated files.
10. Before committing, inspect the complete staged diff with git diff --cached. If output is truncated, inspect it per file or in chunks until every staged line is reviewed. Re-run git diff --cached --check.
11. Create the commit and verify it with git show plus git status --short. Never push, amend, reset, or discard changes unless explicitly requested.

Front-End Review Checklist

Apply checks relevant to the changed files:

uni-app / Vue 2

• Use <view>, <text>, <image> — not HTML tags (<div>, <span>, etc.).
• Use uni-app APIs (uni.request, uni.navigateTo) — not Web-only APIs (window, document, localStorage).
• Options API only (Vue 2); no Composition API / <script setup> unless the target project already uses it.
• Lifecycle: page (onLoad, onShow, …) vs app (onLaunch, …) used correctly.
• Styles use upx; avoid gap in flex layouts — use margin instead (see .cursor/rules/style-compatibility.mdc).
• Conditional compilation (#ifdef MP-WEIXIN, #ifdef APP-PLUS, #ifdef H5) where platform behavior differs.

Configuration & Routing

• config.js, ext.json, ext-production.json, manifest.json, pages.json — confirm no secrets, no accidental dev-only values destined for production.
• pages.json route/subPackage entries consistent with new or moved pages.
• Environment switches (change.bat, ext.json vs ext-production.json) not committed in a broken intermediate state.

API & Data

• Front-end wrappers under src/api/** (uni-app) or src/service/** (desktop Vue) match expected request/response shape.
• For API-related commits, note if backend contract alignment was verified; do not claim backend parity unless checked.
• Auth tokens, shop/user isolation, and error handling preserved.

Code Quality

• New or materially changed files/functions include Simplified Chinese comments per .cursor/rules/chinese-code-comments.mdc.
• No unrelated refactors bundled into the same commit.
• No debug console.log left in production paths unless intentional.

Validation

Run checks proportional to the change — do not run unrelated broad fixes.

Change type	Suggested checks
.vue / .js / .ts edits	read_lints on changed files; git diff --check
pages.json / routing	Verify paths exist; spot-check referenced page files
Config files	Manual review for secrets and environment correctness
Dependency / build config	Targeted install or syntax check only if changed

Do not automatically run npm run build:mp-weixin — the user normally keeps dev/build running. Run build only when explicitly requested or when a specific validation need is identified.

Distinguish static/local validation from end-to-end verification. Do not claim tests or builds passed unless they were run successfully.

Commit Message

Use Conventional Commits:

<type>(<scope>): <concise purpose>

- <key intent or behavior change>
- <key intent or behavior change>
- API: <front-end request/response contract changes or none>
- Config: <config.js, ext.json, manifest.json, pages.json changes or none>
- Breaking Changes: <details or none>

Choose a precise type: feat, fix, refactor, perf, style, test, docs, build, ci, or chore.

• scope: product name when clear (hdApp, ghsApp, …) or functional area (order, auth).
• Subject: one clear sentence describing purpose and behavior — never vague subjects like update, fix, or changes alone.
• Include API, Config, and Breaking Changes lines when relevant; state none / 无 when an explicit audit trail is useful.

Examples

feat(hdApp): 订单列表支持按配送日期筛选

- 新增日期选择器与列表查询参数 deliveryDate
- 空态与加载态与现有列表页保持一致
- API: order/list 增加 deliveryDate 可选参数
- Config: none
- Breaking Changes: none

fix(ghsApp): 修复 APP 端 flex 间距不生效

- 将 gap 替换为 margin-top 并处理首项归零
- API: none
- Config: none
- Breaking Changes: none

Scope and Safety

• Do not include unrelated modified, staged, or untracked files.
• Do not expose secrets from diffs in the final response; stop if credentials or sensitive data are detected.
• Do not claim tests passed unless they were run successfully.
• Respect repository rules: this skill authorizes commit only when the user explicitly requests it.
• Never push unless explicitly requested.

Handoff

Report:

1. Commit hash and subject
2. Behavioral summary (which product(s), what changed for users/developers)
3. Validations run and their results
4. API / Config / Breaking Changes status
5. Remaining risks or uncommitted work
6. Whether the worktree is clean
7. Confirm no push was performed