用途
task-to-pr 是一个将需求端到端推进到代码交付的技能。它覆盖从理解任务、规划、实现、验证、提交、自审、推送分支到创建拉取请求的完整链路。
该技能定位为通用起步技能（generic starter skill）。在真实项目中，应先运行 setup-task-to-pr 进行配置，使本技能能够被本地命令和交付规则充实后再使用。
不适用场景
- 纯代码审查：应使用 review-pr。
- 仅提交已完成的既定工作：应使用 commit。
- 仅对已完成功能做浏览器测试：应使用 test-feature。
- 用户要求为仓库搭建工作流：应使用 setup-task-to-pr。
交付契约
在打开或标记 PR 就绪之前，需满足以下条件：
- 需求与假设已被记录。
- 可能涉及的文件与归属边界已被理解。
- 非平凡工作有简短计划。
- 实现覆盖正常路径、重要的异常路径与恢复状态。
- 相关验证通道已运行，或每条跳过的通道都有记录的原因。
- 涉及用户可见行为时，具备功能验证证据。
- 当浏览器/移动端集成行为发生变化时，持久 E2E 覆盖已新增，或已带有理由地有意跳过。
- 仅暂存和提交任务范围内的文件。
- 分支适合审查。
- PR 正文说明问题、变更、测试、边界情况、兼容性、风险与回滚。
使用方式（七个阶段）
第一阶段：理解
阅读用户需求、关联工单、issue、计划或分支上下文。编辑前先检查仓库说明文件，使用如下方式检索：
rg --files -g 'AGENTS.md' -g 'CLAUDE.md' -g 'CONTRIBUTING*' -g 'README*' -g 'docs/**'
若存在项目本地技能，优先阅读相关本地版本：
find .agents/skills .claude/skills .codex/skills -maxdepth 3 -name SKILL.md 2>/dev/null | sort
使用 rg、rg --files 与有针对性的文件阅读来检查可能入口。记录起点：
git status --short
git branch --show-current
git rev-parse --short HEAD
若工作区不干净，需显式跟踪任务范围内被触及的文件，绝不依赖宽泛暂存。仅当歧义会改变实现或造成安全风险时，才提出一个聚焦的问题；否则陈述假设并继续。
第二阶段：规划
对非平凡工作，在项目用于笔记、任务产物或临时文档的位置创建一份简明计划。若不存在此类约定，将计划保留在对话中，或仅在仓库已使用 notes/ 时创建 notes/<slug>-plan.md。
计划应包含：需求与假设；可能变更的文件；实现顺序；计划运行的验证通道（lint、format、typecheck/compile、unit、integration、E2E、build/package、security、accessibility、performance、feature validation 或项目特定检查）；功能验证决策；持久 E2E 决策；兼容性与风险说明。
不要对微小编辑过度规划。微小工作可将计划直接放在 PR 正文中。
第三阶段：实现
遵循最具体的项目说明与本地技能指引。保持写入范围狭窄。优先复用既有模式、辅助函数、测试夹具与框架约定。编辑过程中在可用时运行窄范围检查。若工作区存在无关变更，保留一份被触及文件清单。若实现过程暴露出过时说明或缺失工具，在适当情况下于同一变更中修补最窄的持久层。
第四阶段：验证
针对被触及面与风险等级运行最小且有意义的验证。将 lint、typecheck/compile、单元测试、集成测试、E2E 测试、build/package 检查、安全检查、可访问性检查与功能验证视为相互独立的验证通道。
优先使用项目已配置的命令。若项目尚未配置，可探测可能的命令：
npm run
pnpm run
yarn run
npm run test
npm run lint
npm run typecheck
npm run build
pnpm test
pnpm lint
yarn test
pytest
go test ./...
cargo test
mvn test
./gradlew test
在本地 task-to-pr 技能替换之前，使用如下默认验证矩阵：
- 纯文档：若有则运行文档 lint 或链接检查；否则运行 git diff --check。
- 格式化/配置：formatter/lint 检查加窄范围配置验证命令。
- 纯逻辑：lint、typecheck/compile、聚焦单元测试。
- 共享包/库：lint、typecheck/compile、聚焦单元测试，可行时对受影响消费方做 compile/typecheck。
- UI 组件或页面：lint、typecheck/compile、可用时单元/组件测试，对可见行为做功能验证。
- API 路由/服务：lint、typecheck/compile、聚焦单元测试、集成或契约测试。
- 数据库/模式/迁移：迁移生成/验证、集成测试、回滚或兼容性说明。
- 认证、权限、计费或安全：聚焦单元与集成测试、功能验证、安全审查说明、负路径检查。
- 移动应用：lint/typecheck/compile、聚焦单元测试、已配置时做模拟器/设备检查。
- 桌面应用：compile/package 检查加项目桌面冒烟或集成检查。
- 依赖/构建工具：install/lockfile 验证、lint/typecheck/build 或可行时的 CI 等效检查。
对每条相关通道，记录：运行的命令；范围（聚焦、特定包/应用或全量套件）；结果（通过、失败、部分、阻塞或跳过）；命令产生产物时的证据路径；任何跳过或阻塞通道的原因。
除非本地技能或用户明确许可，不要运行昂贵、易抖动、破坏性、影响生产或对外可见的命令。当必需通道不安全或不可用时，记录确切阻塞点与剩余风险。
对于用户可见行为，使用 test-feature 或已配置的对应面测试技能。它应演练真实流程、捕获证据并产出验证报告。在功能验证之后，当行为需要持久回归覆盖时，使用 automate-e2e-tests。仅在具备记录理由时才跳过 E2E，例如已有覆盖、下层测试更合适、无用户可见行为或缺少安全基础设施。
第五阶段：提交与审查
审查差异：
git status --short
git diff -- <task-scoped-files>
若项目期望功能分支，则创建或切换到任务分支。使用 commit 进行范围化提交。若不可用，仅暂存明确的任务文件：
git add <file-1> <file-2>
git commit -m "feat: <summary>"
当变更非平凡、涉及安全或横切多个模块时，使用 review-pr 进行自审。除非用户明确授权确切操作，绝不使用 git add .、git add -A、强制推送、破坏性重置或单方面解决冲突。
第六阶段：拉取请求
仅当项目策略允许时才推送分支：
git push -u origin <branch>
若本地工具有则使用其打开 PR，常见方式：
gh pr create
默认 PR 正文结构：
## Problem
## Requirement
## Changes
## Testing
## Edge Cases
## Compatibility
## Risk and Rollback
## Self-Review
包含验证报告、截图、视频、测试输出或其他证据的链接或路径。
第七阶段：CI 跟进
若在打开或更新 PR 后具备 CI 访问权限：使用项目的 PR 工具或 CI 面板检查必需检查项状态。若检查通过，在收尾中记录。若检查失败，将每个失败归类为产品、测试、环境、依赖、权限或无关的既有失败。修复本任务引入的产品或测试失败，然后在推送更新前本地重跑最窄的相关命令。未经用户批准，不要追查大范围易抖动套件、基础设施、权限或无关失败。记录确切的失败检查与下一步行动。
收尾
报告内容包括：PR URL 或分支名；提交 SHA；已运行命令与结果；适用时的功能验证报告路径；E2E 覆盖是新增、更新、已覆盖、跳过还是阻塞；剩余风险。
来源与自我改进
本技能为 Supatest AI supa-skills task-to-pr v1.0.2 的通用起步版本。需在每个项目中运行 setup-task-to-pr 以创建本地增强版本。若该工作流在真实使用中遗漏了必需的验证关卡、PR 规则、CI 行为或交付产物，应在关闭前修补本技能或已配置的项目本地版本。