用途：从开始到完成实现一个具体 issue。该技能独立于 Ralph，不从 AFK 队列中选取任务、不进行重复迭代，也不假设存在包装脚本；它执行用户给出的 issue 或上下文中已有的 issue。
输入：接受本地 issue 路径（如 docs/issues/<change>/<issue>.md）、相关本地 issue 文件夹、粘贴的 issue 文本、上下文中已有的 GitHub/Linear/跟踪器 issue，或当前对话中描述的 bug 或任务。若目标不明确，只问一个简洁问题确认；若清晰则直接进行。
流程：1）理解 issue，提取要解决的问题、验收标准、明确的非目标、阻塞项/依赖/HITL 要求、预期测试或验证步骤；若标记为阻塞或需要人工输入，先停下询问，除非用户已提供缺失决策。2）检查当前状态，探索仓库验证 issue 与现实是否一致，包括现有行为与失败测试、邻近实现模式、受影响的公共接口与边界、描述行为的现有测试，以及 README、包脚本、CI 配置、Makefile、任务文件或解决方案文件中的项目专用命令；探索程度与 issue 成比例，不重构无关代码。3）检查当前外部文档，对第三方框架、库、SDK、API、CLI 工具、云服务、端点、配置选项或语法，按仓库要求的文档查找流程获取最新文档；在要求 ctx7 的仓库中使用 npx ctx7@latest library <name> "<specific question>" 或 npx ctx7@latest docs <libraryId> "<specific question>"；不要对通用编程概念或项目本地业务逻辑使用外部文档查找。4）实现并编写聚焦测试，尽量测试先行：用失败测试复现 issue 或找到现有失败测试，实现满足 issue 的最小连贯改动，测试尽量保持在公共边界，避免实现细节断言，除非项目该层已如此使用；若 issue 太小无需新测试，在最终回复中说明原因。5）验证，运行最相关的反馈回路：针对改动行为的定向测试、涉及共享行为时的更广测试套件、仓库期望的构建/类型检查/lint/格式化命令；若因缺少服务、依赖、凭据或沙箱限制无法运行，清楚记录阻塞。6）更新 issue 记录：若来自本地 Markdown 文件，仅在验收标准满足且验证已运行或阻塞可接受时移入 done/；若未完成，追加简短进度说明，包含已完成工作、验证状态和剩余阻塞；若来自跟踪器且工具可用，仅在用户要求时更新，否则总结应发布的内容。7）适时提交：仅在用户要求提交或 issue 工作流明确期望提交时提交，提交信息包含改动内容、关键决策、运行的测试或验证、剩余阻塞；不要包含无关的未跟踪文件。
最终回复：报告实现了什么、更改的文件、运行的验证及结果、issue 更新或剩余阻塞，保持简洁，不要粘贴大段 diff。
限制：不负责 issue 选择、队列管理或重复迭代；外部文档查找仅限第三方技术；提交需用户要求或工作流明确期望；无法运行的验证需记录阻塞。