# Maycur AI Code Manager

> 代码管理（AI 平台）。bug-killer 重构 P1——负责 git 流程：复用 code-analyzer 的 repos/ → 切 bugfix 分支（origin/master 起点）→ 移交 code-dever → commit/push/MR（全部用户确认）。触发词：代码管理、bugfix 分支、commit、push MR、code-manager。

- Skill: `jeandoom/maycur-ai-code-manager` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jeandoom/maycur-ai-code-manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jeandoom/maycur-ai-code-manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Jeandoom (https://skillmd.com/u/jeandoom)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/jeandoom/maycur-ai-code-manager

---


# maycur-ai-code-manager — 代码管理

maycur-ai-coder 插件第一个 skill——负责 bug 修复链路的 git 流程。所有写操作（commit/push/MR/merge）必须经用户确认。

## Claude vs 脚本分工

| 角色 | 职责 |
|------|------|
| **Claude** | 读 clue/root-cause → 复用 repos/ → 切 bugfix 分支 → 移交 code-dever → commit/push/MR（全部确认） |
| **无 Python 脚本** | 编排 git 操作是 Claude 强项，复用 opser/gitlaber |
| **opser** | 返回部署分支（用于**读懂生产代码版本**，不作为 bugfix 起点） |
| **gitlaber** | `fetch/pull` 拉代码（不用 `file/commits` 在线查） |

## 双重分支模型（关键）

| 用途 | 分支来源 | 工具 |
|------|---------|------|
| **读懂生产代码版本**（code-analyzer 用） | opser 返回的部署分支 | git checkout 部署分支 |
| **bugfix 分支起点**（code-manager 创建） | **`origin/master`**（主干，固定） | git checkout -b bugfix-xxx origin/master |

**为什么不同**：生产部署的可能是 master/release/hotfix 分支，但修复必须回到主干 master 走标准 review 流程；避免修复直接落在 release 分支导致下次发布遗漏。

## bugfix 分支命名规范

格式：`bugfix-{tbId?-2-5-单词-slug}`（`tbId?` 可选：若上游 `clue/clue.md` 含 TB ID 则前置）

示例：
- 有 TB ID（`task12345678`）：`bugfix-task12345678-login-npe-check`
- 有 TB ID（短 id）：`bugfix-task4567-null-save-guard`
- 无 TB ID（对话/用户描述场景）：`bugfix-login-npe-check`

**TB ID 来源**：读 `clue/clue.md` 的元信息字段（bug-clue-analyzer 写入），缺失则省略 `tbId` 段。

**slug 来源**：root-cause.md 的根因一句话提取 2-5 个关键词。

**创建前 AskUserQuestion 让用户确认/修改完整分支名**（含 tbId 段 + slug 段）。

## 核心流程

### 阶段 ①：准备代码（read-only，无需用户确认）

```bash
# 1. 从 clue.md 拿 env + 项目名
# 2. opser 确认部署分支（仅用于读懂生产代码版本）
python <opser-dir>/scripts/opser.py git-info --project <P> --env <E>

# 3. 复用 code-analyzer 的 repos/{project}/（若已存在）
#    若不存在 → gitlaber fetch 拉取（用部署分支）
python <gitlaber-dir>/jihulab.py fetch <group/project> --branch <opser部署分支>
```

**关键**：阶段 ① 与 code-analyzer 代码准备流程重复，**优先复用现有 repos/**，不重复拉。

### 阶段 ②：创建 bugfix 分支（本地，需用户确认分支名）

```bash
cd <bug_dir>/repos/{project}

# 1. 拉取 origin/master 最新代码
git fetch origin master

# 2. 拼装候选分支名：
#    - 读 clue/clue.md 拿 TB ID（若有）
#    - 读 root-cause.md 拿根因关键词作为 slug
#    - 格式：bugfix-{tbId?-2-5-单词-slug}
# 3. AskUserQuestion 确认分支名（用户可改 tbId 段或 slug 段）

# 4. 从 origin/master 切 bugfix 分支（本地）
git checkout -b bugfix-{tbId?-slug} origin/master
```

**此阶段完成后，移交控制权给 `maycur-ai-code-dever` 做 Edit**（明确暂停点）。

### 阶段 ③：commit（code-dever Edit 完成后，需用户确认）

code-dever 完成所有 Edit 并写完 `reports/02-修复报告.md` 后，回到 code-manager：

```bash
cd <bug_dir>/repos/{project}

# 1. git status + git diff 展示给用户
# 2. AskUserQuestion 确认 commit：
#    - commit message（建议模板：[bug-{id}] {根因一句话}）
#    - 是否包含所有改动 / 选择性 add
# 3. 用户确认后执行：
git add <files>
git commit -m "<message>"
```

### 阶段 ④：push（需用户确认）

```bash
# 1. AskUserQuestion 确认 push：
#    - 目标 remote（默认 origin）
#    - 是否设置 upstream（首次 push）
# 2. 用户确认后执行：
git push -u origin bugfix-{tbId?-slug}
```

### 阶段 ⑤：创建 MR（需用户确认）

```bash
# 1. AskUserQuestion 确认 MR 参数：
#    - title: [bug-{id}] {根因一句话}
#    - target branch: master（固定）
#    - reviewers: 用户指定
#    - labels: bug/bugfix
# 2. 用 gitlaber 创建 MR（或 GitLab API 直接调）
# 3. MR url 回写到 reports/02-修复报告.md
```

### 阶段 ⑥（可选）：合并 MR（需用户确认）

**不自动合并**。仅在用户显式要求时：

```bash
# AskUserQuestion 确认合并（merge source=bugfix / target=master / squash? / delete-source-branch?）
# 调 GitLab API merge
```

## 用户确认清单（硬约束）

| 操作 | 确认内容 | 默认拒绝时的行为 |
|------|---------|----------------|
| **创建 bugfix 分支** | 分支名（tbId?+slug） | 用户改后再次确认 |
| **commit** | message + 文件列表 | 取消 commit，回退给 code-dever 调整 |
| **push** | remote + upstream 设置 | 取消 push，保留本地 commit |
| **创建 MR** | title + target + reviewers | 取消 MR，保留已 push 的分支 |
| **合并 MR** | merge strategy + squash + delete-source | 拒绝即不合并 |

**任何一步用户拒绝 → 流程暂停**，不静默跳过。

## 执行流程

1. 接收 `{bug_dir}` 或独立模式用户输入
2. **模式探测**：检查 `{bug_dir}/root-cause/root-cause.md`
   - 存在 → 编排模式，复用 repos/ + 读 root-cause 拿方案
   - 不存在 → 独立模式，AskUserQuestion 收集项目/env/改动描述
3. **阶段 ①** 准备代码（复用 code-analyzer 的 repos/，无需用户确认）
4. **阶段 ②** 创建 bugfix 分支（AskUserQuestion 确认分支名）
5. **暂停，移交 `maycur-ai-code-dever`** 做 Edit
6. code-dever 完成后回到 code-manager
7. **阶段 ③** commit（AskUserQuestion 确认 message + 文件）
8. **阶段 ④** push（AskUserQuestion 确认 remote）
9. **阶段 ⑤** 创建 MR（AskUserQuestion 确认 title/target/reviewers）
10. MR url 回写 `reports/02-修复报告.md`
11. **阶段 ⑥（可选）** 合并 MR（用户显式要求才执行）
12. 流程结束

## 独立模式

| 模式 | 触发 | 输入来源 |
|------|------|---------|
| **编排模式** | bug-killer 调度 | 读 `bugs/bug-{id}/` 上游全部物料 |
| **独立模式** | 用户单独调用 | 用户直接给项目名 + env + 改动描述（或已 Edit 的工作区路径） |

独立模式若用户给本地已修改的工作区（如 `D:\code\xxx`，已切到 bugfix 分支且 Edit 过），跳过阶段 ①②，直接进阶段 ③ commit。

## 边界

- 不做代码 Edit（code-dever 职责）
- 不做根因分析（root-cause-analyzer 职责）
- 不做无确认的 commit/push/merge（硬约束）
- 不做在线代码查询（用 gitlaber fetch/pull 强制本地化）
- 不预设 MR target（固定 master，不跟随部署分支）

## 依赖

- **opser**（`opser.py git-info`）：项目环境→部署 git 分支
- **gitlaber**（`jihulab.py fetch/pull`）：代码拉取
- **code-analyzer**（上游）：`code/code-analysis.md` + `repos/{project}/`
- **root-cause-analyzer**（上游）：`root-cause/root-cause.md`（commit message + MR title 来源）
- **code-dever**（协作）：阶段 ② 完成后移交，阶段 ③ 之前等回