按 GitHub Issue 实现代码：先写本地计划待批准…

当收到 GitHub Issue 编号或 URL 的实现请求，需要从读 Issue、写计划、获批、编码到安全审查、测试和 Conventional Commits 提交全流程落地时使用。

适用场景

解决思路

1. 从 Issue URL 或编号获取内容：执行 `gh issue view <url-or-number>`。
2. sandbox 等网络不可达时，不用 `gh issue view`，改为让用户直接（粘贴或文件）提供 Issue 正文，并把它作为 Issue 内容继续 Step 2 及之后。
3. 基于 Issue 内容调查相关代码，并在 `_/local-plans/` 创建详细计划文件。
4. 并行调查：变更对象文件现状（Glob / Grep / Read）；可复用的既有组件/工具；相关 API endpoint；类似实现模式。
5. 计划文件名：`<issue-number>-<issue-slug>.md`，例如 `_/local-plans/42-add-auth.md`。
6. 计划必须包含 Context：Issue 背景、目的、为什么需要此变更。
7. 计划必须包含 Approach：实现方针；有选项时写采用理由。
8. 计划必须包含 File Changes 表格：文件路径与变更内容，如 `src/...` 添加、`lib/...` 修改。
9. 计划必须包含 Reuse：复用的既有实现路径与用途。
10. 计划必须包含 Test Plan：动作确认步骤、边缘情况确认的 checklist。
11. 将计划文件内容展示给用户，等待用户批准后再开始实现；不得在未批准时开始实现。
12. 按 CLAUDE.md 或项目规约实现代码。
13. 大范围变更时使用 `isolation: "worktree"` 安全实施。
14. 注释方针：代码注释不要只写“做什么”，而要写“为什么存在／从包・服务视角看对象的角色”。
15. 注释需让后续读者（含 Claude）明确其他文件/服务/调用方/被调用方视角，即该符号被谁调用、承担哪个边界。
16. 若仓库存在 `.claude/rules/code-comment-style.md`（由 `init-claude` 部署），遵循其详细注释规约；不存在则遵循上述要点。
17. Step 5 必须用 Agent 工具做安全审查。
18. 安全审查项：OWASP Top 10；API key/secret 硬编码；输入验证；XSS 可能性。
19. 若发现安全问题，先修复再进入下一步。
20. 执行项目测试命令。
21. 测试失败时先调查根本原因再修正。
22. 调试方针：若存在 `.claude/rules/debugging.md`，遵循其 4 阶段；不存在则按以下要点。
23. 调试要点：先精读错误消息/stack trace，再写修正代码。
24. 调试要点：同一处失败 3 次即判断为架构问题，不再追加修复尝试，向用户报告状况。
25. Step 7 使用 `create-commit` skill 按 Conventional Commits 格式创建提交。
26. out-of-scope 处理：实现中发现应处理但当前范围外的事项（未处理改善、别功能、技术债、后续作业）时，不要放置，必须追踪。
27. out-of-scope 追踪 1：用 `gh issue list --state open --search "${KEYWORD}"` 搜索是否已有覆盖该对象的 open Issue；关键词用 `"${KEYWORD}"` 引号包裹。
28. out-of-scope 追踪 2：向用户提示 out-of-scope 项、已有 Issue 有无、处理方案（给既有 Issue 评论 or 新建 Issue）；获批后执行，未确认不得操作 Issue。
29. out-of-scope 追踪 3：若已有 Issue，执行 `gh issue comment "${ISSUE_NUMBER}" --body "$(cat <<'EOF' ... EOF)"` 添加评论；评论包含“检测背景”“相关文件・符号”（如 `src/path/to/file.ts` — 对象函数名/类名）、“从包・服务视角看的角色・影响范围”（边界、调用方/被调用方）、“着手时注意事项・依赖关系”（依赖包、顺序约束等）。
30. out-of-scope 追踪 4：若无既有 Issue，若引入 `create-issue-tree` 则用它（用 `--root <根 issue 编号>` 关联既有根）；未引入则用 `create-issue`，在合适父 Issue 下起票；标题用 Conventional Commits 格式。
31. out-of-scope 追踪 5：在原 PR 本文或输出报告中写明“排除项”和“切分目标 Issue 编号”（提交创建后写也可以）。
32. out-of-scope 安全注意：传给 `gh` 的关键词/评论正文中变量用 `"${var}"` 引号包裹，正文用 HEREDOC（`<<'EOF'`）传递，防止注入。
33. 验证：新执行测试/构建命令，确认完整输出和退出码后再声明完成；若仓库存在 `.claude/rules/verification.md`，遵循其 5 段 gate。
34. 验证：禁止用“应该行”“大概能跑”等推测词主张完成；引用测试输出/退出码作为证据后再宣布完成。示例：`npm test` 执行，22 件全过，失败 0（退出码 0）。
35. 常见失败规避：不要跳过 Step 3 的等待批准；严格按“计划提示→批准→实现”顺序。
36. 常见失败规避：测试失败不要未调查原因就当猜测修正；有 `.claude/rules/debugging.md` 按其 4 阶段，否则按 Step 6 要点（调查→分析→假说→修正）。
37. 常见失败规避：安全未解决的问题不得提交；Step 5 发现问题必须修到可进入 Step 6。
38. 常见失败规避：不得用上次测试结果为根据宣布完成；测试必须新执行，确认退出码和完整输出。
39. 注意事项：未经用户批准不得开始实现。
40. 注意事项：安全未解决不得提交。
41. 注意事项：大变更分步骤提交。
42. sandbox：计划、实现、测试、Step 7 提交可在 sandbox 执行（仅 workspace 写入、无网络操作）。
43. sandbox：`gh issue view` 可用 Step 1 替代路径省略；out-of-scope 追踪中的 `gh issue list`、`gh issue comment`、`create-issue-tree`/`create-issue` 新起票若选择执行需要网络。
44. sandbox：本 skill 流程中需要网络的只有 `gh issue view` 和可选的 out-of-scope 追踪；二者都可省略。
45. sandbox：本流程不含 `git push`；提交后要反映到远端需另用 `create-pr` 等后续 skill。
46. sandbox：要执行这些网络命令时，按命令单位禁用 sandbox。

适用边界 · 注意事项

• 没有 GitHub Issue/编号/URL/正文，且不需要按 Issue 驱动实现时。
• 需要完全非交互式、无法等待用户批准计划时（流程强制先获批）。
• 完全离线且必须执行 `gh issue view` 或 out-of-scope 的 Issue 搜索/评论/起票等网络步骤、不能省略时。