Stats
Actions
Tags
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