|
|
@@ -0,0 +1,137 @@
|
|
|
+---
|
|
|
+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:
|
|
|
+
|
|
|
+```text
|
|
|
+<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
|
|
|
+
|
|
|
+```text
|
|
|
+feat(hdApp): 订单列表支持按配送日期筛选
|
|
|
+
|
|
|
+- 新增日期选择器与列表查询参数 deliveryDate
|
|
|
+- 空态与加载态与现有列表页保持一致
|
|
|
+- API: order/list 增加 deliveryDate 可选参数
|
|
|
+- Config: none
|
|
|
+- Breaking Changes: none
|
|
|
+```
|
|
|
+
|
|
|
+```text
|
|
|
+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
|
ouyang