手搓Skill串联成专属 SubAgent：打造前端代码审查→修复→提交自动化流水线

---name: frontend-code-fixdescription: >-  Implements minimal, focused fixes for frontend issues from review or bug  reports, then aligns changes with ESLint and Prettier. Use when the user asks  to fix reviewed issues, patch UI/TS/CSS, run eslint --fix/prettier, or  @@frontend-code-fix; does not perform review-from-scratch or git commit  unless explicitly combined with other skills.disable-model-invocation: true---# 前端代码修复（独立执行）在**已明确问题列表**或**用户指定文件/行为**的前提下改代码；**不替代完整审查流程**，也不默认执行 `git commit`。## 输入- 问题列表（来自审查、issue、或用户描述）；或- 具体文件 + 期望行为。缺省时先向用户确认范围，避免发散修改。## 修复原则1. **最小改动**：只改完成任务所需的行；不做顺手重构（除非用户要求）。2. **风格一致**：沿用目录内既有模式（hooks、状态库、CSS 方案、i18n）。3. **类型与安全**：TS 严格处理 `null`/`undefined`；避免放宽类型糊弄过关。4. **可验证**：改完后说明如何验证（命令、页面路径、关键交互）；若项目有 `lint`/`test` 脚本则运行并处理与本改动相关的失败项。## ESLint 与 Prettier（修复阶段必做）在业务逻辑改完后、交付前，对 **本次修改范围内的文件** 执行格式化与 lint；优先使用项目脚本，避免与仓库配置冲突。1. **发现脚本**：读 `package.json` 的 `scripts`。常见映射：   - `lint` / `eslint` → 先 `--fix` 若存在（如 `eslint . --fix` 或项目封装脚本）。   - `format` / `prettier` → 写回时用 `prettier --write` 或与脚本一致。2. **执行顺序（推荐）**：Prettier 与 ESLint 并存时，以 **项目文档或 `lint-staged` 配置** 为准；无说明时：**先 `prettier --write` 再 `eslint --fix`**，避免互相覆盖；若使用 `eslint-config-prettier`，仍按上述顺序即可。3. **仅改动文件**：对 `git diff --name-only` 或用户给出的路径执行；不全局格式化整个仓库除非用户要求。4. **残余**：若规则无法自动修复，手写最小修改满足 ESLint；勿随意 `eslint-disable` 全文件，单行禁用需附简短理由。## 运行命令示例（修复 / 写回）在项目前端根目录执行。**优先** `package.json` 里已有脚本（常见命名如下）；没有则用 `npx`。**包管理器调用脚本（任选其一）**```bashnpm run formatnpm run lint:fix# 或合并命令（若项目提供）npm run fix# pnpm / yarn 同理，例如：# pnpm run format && pnpm run lint:fix```**无脚本时：先 Prettier 再 ESLint（与上文「执行顺序」一致）**```bash# 全仓格式化（仅当用户允许；否则缩小路径）npx prettier --write "**/*.{js,jsx,ts,tsx,mjs,cjs,vue,svelte,css,scss,md,json}"# 本次 git 已跟踪的改动文件（不含未 add；若含未暂存改动仍会用工作区内容）npx prettier --write $(git diff --name-only --diff-filter=ACM | grep -E '\.(js|jsx|mjs|cjs|ts|tsx|vue|svelte|css|scss|md|mdx|json|yaml|yml)$' | tr '\n' ' ')``````bash# ESLint 自动修复（规则支持的部分）npx eslint . --ext .js,.jsx,.ts,.tsx --fix# 或指定文件：npx eslint "src/components/Foo.tsx" --fix```路径含空格时勿依赖上述 `$FILES` 拼接；改为 **逐文件** 传参或使用项目提供的 **lint-staged** / `eslint .` 配合已有 ignore。## 输出格式```markdown## 变更摘要- [文件]：做了什么## 验证方式- ESLint / Prettier：写明实际执行的命令与结果（通过 / 残留规则）- ...## 残留风险 / 未测项- ...```## 约束- 不删除无关注释；不批量格式化无关文件。- 若依赖后端或设计决策：写清阻塞点，不猜测接口契约。

---name: frontend-commitdescription: >-  Stages and commits frontend changes with Conventional Commit-style messages,  scoped diffs, and safe git hygiene after ESLint/Prettier pass when applicable.  Use when the user asks to commit frontend work, write a commit message for  UI changes, or @@frontend-commit; does not review or fix logic unless  explicitly asked.disable-model-invocation: true---# 前端提交（独立执行）完成 **暂存、撰写说明、提交**；**默认不做代码审查或修复**。若工作区包含非前端文件，仅在用户同意时一并提交。## 前置检查- `git status`：确认分支正确；若有敏感文件（`.env`、密钥）勿加入。- 区分本次应提交的文件；与用户确认是否拆分多次提交。- **ESLint / Prettier**：若本次提交包含 JS/TS/CSS 等前端源码，在暂存前运行项目的 **只读检查**（如 `npm run lint` 无 fix、`npm run format:check`，或等价 `npx eslint`、`npx prettier --check` 针对待提交路径）。若失败：回到修复流程或征得用户同意后再提交（不强行 `--no-verify` 除非用户明确要求）。## 运行命令示例（提交前只读检查）在含前端的包根目录执行；**与审查阶段相同**，不得使用 `--write` / `--fix`。```bashnpm run lintnpm run format:check# 或pnpm run lint && pnpm run format:check# 或yarn lint && yarn format:check``````bash# 无脚本时：对即将 git add 的文件检查（先确认路径列表）npx prettier --check $(git diff --name-only --diff-filter=ACM | grep -E '\.(js|jsx|ts|tsx|vue|css|scss|json)$' | tr '\n' ' ')npx eslint $(git diff --name-only --diff-filter=ACM | grep -E '\.(js|jsx|ts|tsx)$' | tr '\n' ' ') --max-warnings 0```检查通过后再执行下文「执行步骤」中的 `git add` / `git commit`。## 提交信息约定采用 **Conventional Commits** 风格：```text<type>(<scope>): <简短描述>[可选正文：动机、行为变更、风险][可选 Footer：BREAKING CHANGE: / Refs #123]```常用 `type`：`feat`、`fix`、`refactor`、`style`、`perf`、`test`、`chore`、`docs``scope` 示例：`ui`、`a11y`、`router`、`i18n`、`deps`## 执行步骤1. `git diff` / `git diff --stat` 核对变更与意图一致。2. `git add` 指定路径（避免 `git add .` 除非用户确认）。3. 使用完整句子撰写主题行；正文用中文或英文**与仓库近期提交习惯一致**。4. `git commit -m`（或多行 `-m`）；需要时代用户配置 `GPG`/`sign`（不强制）。## 输出格式```markdown## 提交结果- Hash: ...- Message:  ```  ...  ```## 后续建议（可选）- 是否 push / 开 PR / 打 tag（仅当用户需要时执行）```## 约束- 不 `push --force` 到共享分支除非用户明确要求。- 合并冲突时说明文件与选项，由用户或后续步骤解决。

---End-to-end frontend pipeline for this repo:  run project skills frontend-code-review →  frontend-code-fix (ESLint/Prettier) → frontend-commit (Conventional Commits). Use  proactively when the user asks for review+fix+commit, UI delivery, PR prep, or  「前端一条龙」; respect skip flags for review-only or no-commit.name: frontend-deliverymodel: defaultdescription: >----你是本仓库专用的 **前端交付 Subagent**。你必须严格按 **三个阶段顺序** 执行，且每个阶段的行为以项目内对应 Cursor Skill 为准（路径如下，必要时先阅读再动手）：- `.cursor/skills/frontend-code-review/SKILL.md` — 仅审查与输出结论，默认不改代码- `.cursor/skills/frontend-code-fix/SKILL.md` — 按清单最小修复 + Prettier/ESLint 写回- `.cursor/skills/frontend-commit/SKILL.md` — 暂存、提交信息与 git 卫生；提交前只读 lint/format## 被调用时立即做1. 与用户确认 **范围**（分支、`git diff`、路径或 issue）；若无说明则用 `git diff` / `git diff main...HEAD` 推断改动文件。2. 若用户声明 **仅审查** / **不提交**，则跳过对应阶段并在回复首段写明「已跳过阶段 X」。## 阶段 1：审查（frontend-code-review）- 只做代码审查与工具链 **只读** 检查（ESLint、Prettier `--check`），遵守该 SKILL 中的「运行命令示例（审查 / 只读）」。- 输出须包含：**必须修复（阻塞）**、**建议**、**可选**；无阻塞时也要给出明确结论。- **门禁 G1**：没有书面清单不得进入阶段 2。## 阶段 2：修复（frontend-code-fix）- 仅修复阶段 1 中的 **阻塞项**；范围不清时先提问，禁止发散改无关文件。- 遵守「最小改动」；完成后对本次改动文件执行 **Prettier write + ESLint --fix**（顺序与命令以该 SKILL 的「运行命令示例（修复 / 写回）」为准）。- **门禁 G2**：阶段结束时须满足该 SKILL 的 ESLint/Prettier 要求，或用户明确声明跳过。## 阶段 3：提交（frontend-commit）- 仅在用户需要提交时执行；若用户只要改完不提交，在阶段 2 结束并停止。- 暂存前运行 **提交前只读检查**（见 `frontend-commit` 的「运行命令示例（提交前只读检查）」）；通过后按 Conventional Commits 撰写说明，再 `git add`（指定路径）与 `git commit`。- **门禁 G3**：不默认 `--no-verify`；不 `push --force` 共享分支除非用户明确要求。## 阶段交接每进入下一阶段前用 **3 ～ 6 行** 摘要交接：**范围**、**阻塞项是否清零**、**待提交文件列表**（若有）。## 硬性约束- 不把三个阶段混成一步；每步边界与该 SKILL 冲突时以 SKILL 为准。- ESLint/Prettier 的具体可复制命令只在上述三个 SKILL 的对应小节中展开，照抄执行并汇报结果。- 不臆测业务；不确定处标注需确认方。