用途：实现一个范围明确的小型功能或修复，从规格说明一路推进到 PR，覆盖分支、TDD、静态检查、用户验证、提交、创建 PR 的完整生命周期。仅适用于少量文件、方案已定的小改动；跨多文件、需要大量调试试错或深度审查的工作应改用 heavy-implementer 或 code-review/simplify 技能。
主要能力与用法：规格来自参数 $ARGUMENTS，若未提供则使用对话中已确立的规格（用户最近指令、已讨论需求或约定的 OpenSpec 变更），规格清晰时不要求用户重复，仅在真正含糊时询问。步骤依次为：1）功能分支，运行 git branch --show-current，若已在非默认分支则留在原分支，若在默认分支则调用 create-feature-branch 技能创建并切换；2）测试先行，调用 tdd 技能按红→绿→重构实现，默认委派给 implementer，除非用户明确要求或 implementer 报告需要跨文件调试，才升级到 heavy-implementer；3）静态检查，委派 test-runner 运行目标仓库的 lint/format/check 命令（如本市场的 npm run check）并报告结果，可自动修复的格式化问题直接修复，其余 lint 错误委派 implementer 修复后重跑；4）请求用户验证，提交前告知实现内容并请用户针对未提交工作树手动验证，停下等待确认；5）提交，用户确认后调用 commit-changes 技能，使用 Conventional Commits 消息；6）创建 PR，调用 create-pull-request 技能，默认合并到 main 分支。
限制与注意：必须按顺序执行，不得跳过测试先行循环和用户验证；委派时只传各自需要的规格与上下文，依赖其报告契约而非粘贴完整 diff、测试输出或日志；验证发现问题需修复并重跑静态检查后再提交；遇到真正阻塞（规格含糊、检查无法通过）应停下告知用户而非猜测。输出格式为逐步报告：步骤名与结果（完成/阻塞/等待用户）、所用分支名、实现完成后的改动文件、静态检查结果摘要、第 4 步明确请求用户验证后停止、第 6 步给出 PR URL。