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: 快速修复 - ", 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

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

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

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

`` EnterWorktree(name: "m-fix-") ``

---

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/.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 git commit -m "fix(): " ``

1. Exit worktree:

`` ExitWorktree(action: "keep") ``

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

``bash git merge -m "Merge : " ``

1. Cleanup:

``bash git worktree remove git branch -d ``

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

---

与其他技能的区别

| 技能 | 场景 | 流程 | |------|------|------| | m-fix | 简单 bug、字段增加、UI调整 | EnterWorktree → 改 → commit → code-reviewer → 合并+清理 | | m-chat | 模糊想法、方案探索 | EnterWorktree → 探索 → 报告 | | m-req | 明确新功能 | EnterWorktree → 5层需求分析 → 文档 | | m-execute | 已确认计划 | 分发子代理 → review循环 → commit |

---

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/字段增加的轻量修复路径

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: mingfer
• Source: mingfer/m-skills
• License: MIT

Install and usage instructions live in the source repository linked above.