|
| 1 | +--- |
| 2 | +description: 讨论一轮 patch 小迭代 — 确认后产出【开发工作总结 + 稳定格式的迭代 Issue】到聊天框(只规划,不执行,不开 issue) |
| 3 | +argument-hint: "[可选: 本轮 patch 主题/线索,留空则自动扫描候选]" |
| 4 | +--- |
| 5 | + |
| 6 | +# /patch — 小迭代规划(规划者模式) |
| 7 | + |
| 8 | +你现在是**规划者**,不是执行者。本轮你**不修改任何文件、不碰版本号、不建 tag、不调 `gh`**。 |
| 9 | + |
| 10 | +## 输入 |
| 11 | + |
| 12 | +`$ARGUMENTS` —— 本轮 patch 的主题或线索。为空时,主动扫描发现候选 patch。 |
| 13 | + |
| 14 | +## 流程 |
| 15 | + |
| 16 | +### 1. 扫描现状 |
| 17 | + |
| 18 | +- **累积计数**(累积制核心): 运行 |
| 19 | + `git log $(git describe --tags --abbrev=0)..HEAD --oneline` |
| 20 | + 得到自上次 tag 以来的 patch 提交列表与数量 —— 用户判断"何时升 minor"的依据。 |
| 21 | +- 按主题定位相关位置;若涉及内容,读对应 `todo/01x-vol*.md` 确认这个 patch 服务于哪条 next-step(仅作上下文)。 |
| 22 | +- ⚠️ 项目 Python 脚本一律用 `.venv/bin/python`(有 PreToolUse hook 强制)。 |
| 23 | +- 必要时做 web search 核查事实(准确性优先,token 成本其次)。 |
| 24 | + |
| 25 | +### 2. 判定类型并打标(仅用于聊天讨论,不进 Issue) |
| 26 | + |
| 27 | +| 标签 | 含义 | label 建议 | |
| 28 | +|------|------|-----------| |
| 29 | +| 内容 (feat) | 写新内容的一个片段。**完成一部分内容也算 patch** | feature | |
| 30 | +| 修缮 (fix) | 错别字 / 注释错 / 代码缩进或缺行 / 事实性小错 | bug | |
| 31 | +| 批量 (chore) | lint / frontmatter / 404 等机械修复(跨多文件也归此类) | documentation | |
| 32 | +| 示例 (build) | 代码示例编译 / 行为修复 | bug | |
| 33 | +| 工具链 (chore) | 脚本 / CI / 构建配置小修 | enhancement | |
| 34 | + |
| 35 | +### 3. 粒度与边界(累积制 —— patch 是开发的原子单位) |
| 36 | + |
| 37 | +- **patch 是所有开发工作的原子单位**,涵盖全部类型,**包括写新内容的一个片段**。不会因为"动了学习路径"或"写的是新内容"就升级 minor。 |
| 38 | +- **不设文件数 / 行数硬上限,也不设类型升级线**。诉求太大就**拆成多个 patch**,不升级 minor。 |
| 39 | +- **何时升 minor,纯粹由用户手工判定,与 patch 类型无关。** |
| 40 | + |
| 41 | +### 4. 提案 → 讨论 → 确认(核心是讨论) |
| 42 | + |
| 43 | +- 先用**一句话**讲清这轮打算做什么,作为讨论起点(类型/进度等上下文口头带过即可,**别堆列表**)。 |
| 44 | +- 与用户**来回讨论打磨**,直到用户**明确确认**。 |
| 45 | +- **保持灵活,不搞死板**:不强制列具体文件、不强制验收标准 —— 讲明白就行。 |
| 46 | +- **未确认前,不产出 Issue。** |
| 47 | + |
| 48 | +### 5. 确认后,产出两样东西到聊天框(讨论的最终产物) |
| 49 | + |
| 50 | +**(a) 本轮确认的开发工作** —— 一句话总结聊定的内容。 |
| 51 | + |
| 52 | +**(b) 迭代 Issue(Markdown)** —— 套用 `.claude/templates/iteration-issue.md`(极简版:标题 + 一句话 + 一段"本轮打算做什么"),用 ` ```markdown ` 代码块包裹。用户微调后**自行**送 GitHub。 |
| 53 | + |
| 54 | +★ **(a)(b) 都必须通俗易懂**:用大白话写,少术语、别堆结构化清单,让没参与讨论的人也能一眼看懂这轮要干啥。 |
| 55 | + |
| 56 | +输出后停下。 |
| 57 | + |
| 58 | +## 硬约束 |
| 59 | + |
| 60 | +- ❌ 不直接执行任何文件修改。只产出讨论结果。 |
| 61 | +- ❌ 不碰版本 bump / CHANGELOG / git tag(用户自理)。 |
| 62 | +- ❌ **不调 `gh issue create`,不开 issue**。 |
| 63 | +- ✅ 全程讨论驱动;Issue 仅在用户确认后产出。 |
| 64 | +- ✅ **输出通俗易懂**:用大白话写,别堆术语 —— 用户要能看懂自己收到的 Issue。 |
0 commit comments