Claude Code 工作流 Skills(ask-matt)

/ask-matt 是一套 Claude Code skills 组成的工作流地图，核心是把"有一个想法"到"代码上线"串成一条主线，中间穿插两条 on-ramp（bug 堆积、超大不确定的项目）和几个独立可用的工具型 skill。

主线：idea → ship

1. /grill-with-docs：在一个具体的工作目录里，通过访谈把想法磨清楚，产出留存在仓库里的 CONTEXT.md（领域词汇表）和 ADR（架构决策记录）。如果不在工作目录里（纯粹在磨一个方案、一段文字），换成无状态版本 /grill-me。
2. 需要跑起来才能回答的问题：通过 /handoff 把问题带到一个独立目录，用 /prototype 写一次性验证代码回答，再 /handoff 把结论带回主线程。
3. 分流：是不是要跨多个 session 的大型 build？
   • 是 → /to-spec 把讨论收敛成一份可执行 spec，再 /to-tickets 拆成一个个"tracer bullet"票据，每张票据声明自己的 blocking 依赖边。本地任务用 .scratch/<feature>/issues/ 下的文件手动按依赖顺序做；接了真实 issue tracker（这里用的是 GitHub Issues）时，依赖边落成 GitHub 的原生 issue dependencies，谁的 blocker 都关掉了就可以认领。之后对每张票据跑 /implement，跑完一张就 /clear 掉上下文——每张票据都是自包含的，上一张的上下文可以直接丢弃。
   • 否 → 直接在当前上下文里跑 /implement。

/implement 内部会驱动 /tdd（一次一个红-绿切片），完工后跑 /code-review（Standards + Spec 两个维度的并行审查）再提交。

GitHub Issues 作为 tracker 时的约定

项目里的 docs/agents/issue-tracker.md 定义了这套流程如何映射到 gh CLI：

• 依赖关系用 GitHub 原生的 issue dependencies（gh api .../issues/<child>/dependencies/blocked_by），而不是纯文本约定。
• 一张票据被认为"完成"，收尾动作是：gh issue comment <n> 写结论，然后 gh issue close <n>。

排查记录：明明代码都写完了，issue 却一直显示 Blocked

现象

多张票据（骨架 #2、账户管理 #3、分类管理 #4……）对应的代码都已经在本地 commit 里实现完成，但 GitHub 网页上这几个 issue 全部还是 open，下游票据（#5 ~ #9）也因为依赖链没断开，全部显示红色 Blocked。

排查过程

1. 先确认依赖关系本身没问题：gh api repos/<owner>/<repo>/issues/3/dependencies/blocked_by 返回的 blocker 确实是 #2，且 #2 的 state 是 open——依赖机制工作正常，问题在于上游 issue 没关。

2. 查 #2/#3/#4 的 timeline（gh api .../issues/<n>/timeline），发现完全没有 commented 或 closed 事件，只有 labeled、blocked_by_added、cross-referenced 这些自动产生的事件。也就是说不是关闭失败，而是收尾这一步从来没被执行过。

3. 检查 commit message，发现只有最早的骨架票据用了 GitHub 认的关闭关键字：

   093e8ac 项目骨架与健康检查闭环
   
   ...
   Closes #2

   后面几张票据的 commit message 只是在标题后面带了个 (#3) (#4) 这种引用写法，不是关闭关键字，本来就不会触发自动关闭。

4. 但奇怪的是连 Closes #2 这条也没能让 #2 关闭。再查 git status，才发现根因：

   On branch main
   Your branch is ahead of 'origin/main' by 5 commits.

   所有提交都只停留在本地，从来没有 git push 过。

结论

GitHub"提交信息里写 Closes #N 自动关闭 issue"这个机制，只有 GitHub 服务端真正看到这个 commit 时才会触发——要么是这个 commit 被推送到了默认分支，要么是通过引用了该 issue 的 PR 被合并。只要没有 git push，这条 commit 对 GitHub 来说根本不存在，Closes #N 写了也是白写。

所以这次的现象其实是两层问题叠加：

• /implement 收尾目前只做到"本地 commit"，既没有 git push，也没有在没写关闭关键字的票据上手动 gh issue close。
• 只要上游 issue 不关闭，下游所有票据的 blocked_by 依赖就会一直挂着，级联显示 Blocked，跟代码是否真的写完了没有关系。

后续动作

把本地积压的 commit 一次性 git push 到远程（这样带 Closes #N 的那条会立刻生效），再对没写关闭关键字的票据补一遍 gh issue comment + gh issue close，链路就会正常解锁。

小结

用这类"实现完成后自动关票"的工作流时，git push 是关闭动作能不能触发的前提，而不是一个可以拖到最后再统一做的收尾动作——本地积压太久，会让所有下游依赖误报 Blocked，容易被误判成流程或权限问题。