From issuesmith
按 Issue Task Checklist 逐项实现 — 先读 Issue,拆解任务,强制 TDD,每次变更都验证,使用内置 todo 列表实时追踪进度
How this skill is triggered — by the user, by Claude, or both
Slash command
/issuesmith:issuesmith-implementThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
读 Issue。拆任务。先写测试。实现。验证。提交。更新 todo 列表。重复。完成的 checklist 项由 `/ism:finish` 在 PR 描述中列出,不直接修改 Issue。
读 Issue。拆任务。先写测试。实现。验证。提交。更新 todo 列表。重复。完成的 checklist 项由 /ism:finish 在 PR 描述中列出,不直接修改 Issue。
支持两种模式:
/ism:implement):任务间暂停确认,完成后询问是否进入 finish/ism:finish 内部调用):任务间不暂停,完成后自动衔接 finish 流程Issue 是唯一真相来源。 每一行代码都必须追溯到 Issue 的 Goal 和 Acceptance Criteria。任务进度用内置 todo 列表实时追踪(TUI 可见),完成的 checklist 项由 /ism:finish 在创建 PR 时写入 PR 描述。每次声称"完成"都必须有验证证据支撑。
违反这些规则的字面含义,就是违反其精神。
不在 worktree 内不实现。
不读完 Issue 不写代码。
不看到测试失败不写实现。
不追踪任务进度不算任务完成。
没有新鲜的验证证据不声称完成。
跳过任何一步?从头开始这个任务。
只要写代码就必须遵守:
例外(需征得你的搭档同意):
心想"就这一次跳过 Issue 吧"?打住。这是自我合理化。
┌─────────────────────────────────────────────────────┐
│ ISSUE-FIRST 循环 │
├─────────────────────────────────────────────────────┤
│ │
│ [前置校验] → 读 ISSUE → 拆解任务 → [TDD 循环] → 验证│
│ ↑ │ │
│ └── 更新 ISSUE ←────┘ │
│ │
└─────────────────────────────────────────────────────┘
实现代码必须在隔离的 worktree 中执行,不能在主仓库目录或 main 分支上直接修改。
校验方法:
git worktree list
核对当前目录是否是 worktree 且不是主 worktree(主 worktree 通常指向 main 或 master 分支)。
$ git branch
当前在**主仓库目录**且分支是 `main`。阻止执行。
</Bad>
**校验不通过时:**
不要终止,也不要让用户复制粘贴命令。**直接调用 `issuesmith-start` skill(自动模式)**,自动完成:
- 读取 Issue → 推导分支名 → 确认(仅手动模式)→ 创建 worktree → 安装依赖
worktree 创建成功后,无缝进入步骤 1,继续实现流程。
如果用户未提供 Issue 编号,先列出 open Issues 让用户选择,再执行 `issuesmith-start`。
**手动创建 worktree 的情况:** 如果用户手动执行了 `git worktree add` 创建了 worktree 并在其中工作,校验同样会通过(当前目录不是主 worktree)。允许继续。
### 步骤 1:读 Issue
触碰任何代码之前,先获取 Issue 完整上下文:
```bash
gh issue view <N> --json title,body,labels
如果用户没给 Issue 编号,先列出来:
gh issue list --state open --json number,title,labels --limit 20
消化每一个部分:
[x] vs 未勾选 [ ]有哪里不清楚?停下来问。 不要猜。
找到第一个未勾选的任务。展示进度。
进度: 3/8 完成, 开始任务 4: 添加 filterTasks 工具函数。
全部完成了?通告完成,进入步骤 8。
自动模式: 展示进度但不暂停询问,立即进入步骤 3 拆解任务。
把任务拆成一口大小的子步骤。每个子步骤只做一件事 — 创建一个文件、写一个函数、添加一个测试。
``` 任务 4: 添加 filterTasks 工具函数每步一个动作。测试在代码之前。一次只做一件事。
</Good>
<Bad>
任务 4: 添加 filterTasks 工具函数
实现在前测试在后。一步里混了多个动作。"处理边界"是占位符,不是步骤。
</Bad>
**拆解仅存于对话中。绝不写入本地文件。**
**必须将子步骤写入内置 todo 列表:** 拆解完成后,立即使用内置的 `TodoWrite` 工具将每个子步骤创建为独立的 todo 项(状态 `pending`)。这确保用户能实时看到进度和每一步的状态变化。每完成一个子步骤,立即将其标记为 `completed`。
### 步骤 4:TDD 循环
对每个产出代码的子步骤,遵循 RED-GREEN-REFACTOR 循环:
**RED — 写失败测试**
写一个最简单的测试来展示期望行为。一个行为。清晰命名。真实代码。
test('filterTasks 大小写不敏感匹配标题', () => { const tasks = [{ title: '买牛奶' }, { title: '写代码' }]; expect(filterTasks(tasks, '牛奶')).toHaveLength(1); });
**验证 RED — 看着它失败(必修)**
```bash
npm test -- --testPathPattern=filterTasks
确认:测试失败了(不是报错),失败信息符合预期,失败原因是功能缺失(不是拼写错误)。
测试通过了? 你在测已有行为。修测试。 测试报错? 修错误,重跑到正确失败为止。
GREEN — 最小代码
写最简单的代码让测试通过。不多不少。
function filterTasks(tasks, query) {
return tasks.filter(t => t.title.includes(query));
}
不加功能。不改其他代码。不在测试范围之外"优化"。
验证 GREEN — 看着它通过(必修)
npm test -- --testPathPattern=filterTasks
确认:测试通过,其他测试仍通过,输出干净无警告。
测试失败? 修代码,不修测试。 其他测试失败? 马上修。别往前推。
REFACTOR — 清理
仅在通过之后:去重、改善命名、提取辅助函数。保持测试全绿。不加行为。
声称任何任务完成之前,先过验证关卡:
1. 确认:什么命令能证明这个任务完成?
2. 运行:执行完整命令(全新、完整运行)
3. 读取:完整输出,检查退出码,数失败数
4. 验证:输出是否证实了你的声称?
5. 确认之后:再做出声称
# 运行项目的测试和 lint 命令(根据项目自动检测:npm test、pytest、cargo test 等)
<project-test-command> && <project-lint-command>
不准说"应该能过"或"看起来对了"。运行命令。读取输出。然后才做声称。
只暂存此任务相关的文件。写描述性提交信息:
git add <files>
git commit -m "feat: 添加 filterTasks 工具函数,支持大小写不敏感匹配"
一个任务 = 一次提交。不攒一堆。不写"WIP"或"fix stuff"。
每完成一个顶层 Task Checklist 项,立即在 todo 列表中将其标记为 completed。用户的 TUI 中会实时看到进度变化。
不在此步骤操作 Issue — Issue checklist 的最终记录由 ism:finish 在创建 PR 时写入 PR 描述。
展示进度:
任务 4 完成。进度: 4/8 tasks done。
下一个任务:展示后回到步骤 2(重读 Issue,找下一个任务)。
手动模式: 展示下一个任务名并询问"继续吗?"。用户确认后回到步骤 2。
自动模式: 不询问,展示进度后自动回到步骤 2 继续下一任务。
全部完成 → 做最终验证:
全部 8/8 任务完成。
最终验证:
<运行项目测试命令,如: npm test、pytest、cargo test> → 全部通过
手动模式: 询问"是否进入 /ism:finish?",用户确认后进入。
自动模式: 不询问,完成后直接进入 /ism:finish 流程——运行最终验证 → AC 逐项检查 → 清理检查 → 推送 → 创建 PR → 自检 review → CI 等待 → 合并 → 清理 worktree。
| 借口 | 真相 |
|---|---|
| "我记得 Issue 里写了什么" | 记忆不是证据。重读。 |
| "太简单了不用测" | 简单代码也会坏。测试只要 30 秒。 |
| "我之后再写测试" | 测试立即通过什么都证明不了。 |
| "我之后更新 Issue" | ism:finish 在 PR 描述中列出。对话中追踪进度。 |
| "之后再测试结果一样" | 后写测试 = "这段代码干什么?" 先写测试 = "这段代码应该干什么?" |
| "应该能过" | 运行验证。"应该" ≠ "确实"。 |
| "拆解是我自己看的" | 不值得写下来的不是计划。 |
| "就这一次跳过 Issue" | Issue 是你的合同。跳过就是毁约。 |
| "最后一起提交" | 小步提交 = 可回溯的台阶。大堆提交 = 不可恢复的废墟。 |
| "本地放个 plan 文件无所谓" | 本地 plan 不小心提交后变成过期文档。留在对话里。 |
出现任何一条:停下来,纠正,再继续。
标记任何任务完成之前:
不能全打勾?你跳了某一步。退回去。
开始任务:
✅ [读 Issue] → "任务 4: 添加 filterTasks。3/8 完成。正在拆解..."
❌ 不确认 Issue 直接跳去写代码
TDD:
✅ 写测试 → 跑(失败)→ 写代码 → 跑(通过)→ 提交
❌ 写代码 → 写测试 → 跑(通过)→ "TDD 完成"
验证:
✅ [跑 npm test] [看见: 34/34 通过] "全部测试通过"
❌ "应该能过" / "看着没问题"
更新 todo 列表:
✅ [TodoWrite标记completed] → "任务 4 已完成,进度 4/8"
❌ "等全部做完再统一更新 todo"
Bug 修复的回归测试:
✅ 写重现 bug 的测试 → 看着它失败(证明 bug 存在)→ 修复 → 看着它通过(证明修复有效)
❌ 修 bug → 写测试(立即通过,什么也证明不了)
| 问题 | 解法 |
|---|---|
| Issue 描述有歧义 | 停。问用户。别猜。 |
| 不知道怎么测 | 先写断言。先写你想要的 API。 |
| 测试太复杂 | 设计太复杂。简化接口。 |
| 拆解不了 | 任务太大。让用户拆分 Issue 任务。 |
| 验证反复失败 | 别硬推。停下来查根因。 |
| 范围超出 Non-goals | 提醒用户 Non-goals。建议新建 Issue。 |
以下情况立即停止实现:
问清楚再写,比写错了再改快得多。
本 skill 可独立使用(手动模式),也可由 /ism:finish 内部调用(自动模式):
/ism:start — 为此实现创建隔离 worktree/ism:finish — 调用本 skill 实现未完成任务(自动模式),实现完成后收尾并创建 PR;也可独立调用/ism:explore — 创建 Issue 前探索问题空间/ism:create — 创建本 skill 实现的 Issue手动模式:全部任务完成后询问是否进入 /ism:finish。
自动模式:全部任务完成后直接进入 /ism:finish 流程,不询问。
Issue 是真相来源。测试是证据。验证是门禁。Issue checklist 是记分板。
这些不可协商。
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub membphis/issuesmith --plugin issuesmith