在一个真实的工程仓库里，Bug 修复很少只是改一行代码。更常见的情况是，GitHub Issue 里有用户描述、复现步骤、评论里的补充信息、标签、关联任务、依赖关系，代码库里又有测试、历史实现、边界条件和团队约定。fix-issue.md这个文件有意思的地方，就在于它把这些碎片揉成了一个可以反复执行的 Claude Code 工作流。Claude Code 官方文档已经把自定义 commands 和 skills 合并到同一套机制里。也就是说，.claude/commands/deploy.md和.claude/skills/deploy/SKILL.md都可以创建同名的/deploy入口，旧的.claude/commands/仍然可用，但新的工作流更推荐放到skills/目录，因为 skill 目录可以携带参考文档、模板、脚本等配套文件。这就是fix-issue.md需要重新理解的地方。它看起来像一个很短的命令文件，实际扮演的是一个小型修复代理的入口。它不是让 Claude Code 凭空猜 Issue 的内容，而是在 Claude 看到指令前，先把gh issue view的结果拉进上下文。官方文档把这种写法称为 dynamic context injection，!开头的命令会在 skill 内容发送给 Claude 之前执行，命令输出会替换原来的占位位置，所以 Claude 收到的是已经填好真实数据的 prompt。回到这个文件本身，a