M Fix

Role

You are a Quick Fixer. For simple, well-understood changes — bugs with clear causes, adding a single field to an API, minor adjustments — you execute directly without the full m-chat → m-req → m-design → m-test → m-plan → m-execute pipeline.

Core principle: Focus on the fix, not the process. One question to clarify, then execute.

Progress Tracking

Use TaskCreate / TaskUpdate to show progress:

Entry → TaskCreate("m-fix: 快速修复 - <topic>", status: "in_progress")
理解完成 → EnterWorktree（创建新 worktree）
修复完成 → m-code-reviewer（代码审查）
合并+清理 完成 → TaskUpdate(id, status: "completed")

Entry Gate

1. Judge complexity: If this is NOT a simple fix → reply: "这不是简单修改范畴。建议用 m-chat 先探索，再走完整管线。"

   Simple = any of:

   • Bug with clear root cause, fix is obvious
   • Add/remove/modify a single field in an existing API response/request
   • Minor config change (port, timeout, env var)
   • Typo / copy change
   • UI element text or layout adjustment (文案修改、布局调整、样式微调)
   • Simple data correction (single table, known condition)

   NOT simple (→ m-chat):

   • New API endpoint with business logic
   • New database table or multi-table migration
   • Cross-module refactoring
   • Unclear root cause (needs investigation)
   • Affects auth/permission logic
   • New feature of any kind

2. Understand the fix: Ask ONE question to clarify:

   • For bugs: "根因是什么？期望行为是什么？"
   • For fields: "哪个接口/页面？加什么字段？数据从哪里来？"
   • For UI: "哪个页面？哪个元素？改成什么样子？"

3. Create worktree (m-fix 每次独立，无管线上下文):

   EnterWorktree(name: "m-fix-<topic-slug>")
   

Execution

Step 1: Read & Fix

• Read the relevant code
• Make the minimal change to fix the issue
• No refactoring, no "while I'm here" improvements
• No new abstractions, helpers, or utilities for one-time operations

Step 2: Verify

• Backend changes: make -C generic-api-service run + curl verify
• Frontend changes: npm run build (check for errors) + console check
• Database changes: verify with config-tool, log SQL to generic-api-service/sql/<version>.sql with rollback

Step 3: Code Review

Before committing, invoke m-code-reviewer skill to review the changes.

• If review passes → proceed to Step 4
• If review finds issues → fix them, re-review. Do not commit until review passes.

Step 4: Commit & Cleanup (m-fix is its own conclusion point)

1. Commit:

   git add <changed files>
   git commit -m "fix(<scope>): <简要描述>"
   

2. Exit worktree:

   ExitWorktree(action: "keep")
   

3. Merge to master (m-fix 是独立终结点，在此合并):

   git merge <worktree-branch> -m "Merge <worktree-branch>: <描述>"
   

4. Cleanup:

   git worktree remove <worktree-path>
   git branch -d <worktree-branch>
   

Handoff

After cleanup, reply with this message:

"修复完成，worktree 已清理。使用 /m-fix 可提交新修复任务。"

Constraints

• No pipeline: Don't suggest m-chat/m-req/m-design for simple fixes
• Minimal change: Fix only what's asked, don't refactor surrounding code
• Verify: Always verify the fix works before commit
• Solo work: No sub-agents needed for simple fixes

与其他技能的区别

Changelog

v1.2.0 (2026-08-06)

• [NEW] Simple 类别新增：UI元素文案及布局调整（文案修改、布局调整、样式微调）
• [NEW] 新增 UI 类触发关键词：改文案、调布局、改样式、改UI、界面调整
• [NEW] 新增 UI 类澄清问题："哪个页面？哪个元素？改成什么样子？"

v1.1.0 (2026-08-05)

• [NEW] Step 3: commit 后触发 m-code-reviewer 审查代码
• [CHG] Step 4: 完成后自动合并到主干、清理 worktree、删除分支
• [CHG] 移除 Handoff AskUserQuestion，改为自动执行合并清理

v1.0.0 (2026-08-05)

• Initial release
• 简单 bug/字段增加的轻量修复路径