菜单
打开一个 pull request 并把它推进到干净合并。当 commit 已干净、代码可供 review 时使用——open（检测 base、同步推送、撰写结构化 PR body、gh 创建）然后 land（盯 CI、处理 review 反馈、解决冲突，全绿时 squash-merge）。在 PR 合并或真正受阻之前不要交还控制权。不涉及 commit、code review 与发布事务。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | pr |
| description | 打开一个 pull request 并把它推进到干净合并。当 commit 已干净、代码可供 review 时使用——open（检测 base、同步推送、撰写结构化 PR body、gh 创建）然后 land（盯 CI、处理 review 反馈、解决冲突，全绿时 squash-merge）。在 PR 合并或真正受阻之前不要交还控制权。不涉及 commit、code review 与发布事务。 |
你是作者。分支已提交、工作可供 review。本技能走完一个 PR 的两段人生：open 把分支变成结构化的 pull request，land 把它盯到干净合并。本文件是索引；操作细节在 references/。
核心原则： PR 是一次 review 请求，不是工作的倾倒——title、body、diff 各自独立成章，reviewer 不读你的会话也应能理解这次改动。开了之后，agent 的职责是坚持到底：只要还有可处理的工作（待修的 CI 失败、待回的 comment、待解的冲突），就不交还控制权；仅当 PR 已合并、或某事真正卡住并需要人类决策时才停。
main），且目标是「把它合掉」。WIP、fixup! 或 Phase N 式 commit message 的分支——先理清历史。/harness-stack:pr-watch。按顺序进行：先 open，再 land。
| 阶段 | 参考 | 做什么 |
|---|---|---|
| Open | references/open.md | 检测 base、同步并推送、撰写 title/body、gh 创建 PR |
| Land | references/land.md | 盯 CI / review / head 漂移，处理反馈与冲突，全绿时 squash-merge |
FDD 主流程 step 1（规划与拆解）。覆盖两段——plan（与用户弄清需求、经 investigator 调查代码库、定出 milestone、写出 plan.md 并呈现）与 features（把 milestone 拆成 features.json 并过 coverage 闸）。中间的 contract 段交给 harness-stack:fdd-validation-contract。由 harness-stack:fdd 调用。
构建新特性的主流程编排器。契约优先的多 agent 架构——捕获一个 plan，定义可测试的断言，拆解为多个 feature，再用全新上下文的 implementer/reviewer/validator subagent 驱动一个里程碑设闸的执行循环。当一处改动触及多个文件、有多条验收标准、或跨越多个 feature 时使用。主流程分三步，分发给 fdd-planning（含 fdd-validation-contract）/ fdd-execution / fdd-validate。
为一个 plan 撰写 validation contract——把 definition of done 落成一组可测试、用户可观测的 assertion（VAL-<AREA>-NNN），带 persona 与声明的 Evidence。它是 fdd step 1（规划）里的 contract 阶段。契约通过逐 area 的 investigation subagent 与若干轮 adversarial review 构建，而非一人独写。产出 .harness-runtime/plans/<slug>/validation-contract.md，并经由 fdd init-state 播种 validation-state.json。在项目内首次使用时，还会 bootstrap 项目级约定文档 docs/user-test-patterns.md。
规范 git 工作流实践。任何代码改动都适用。在提交、开分支、解决冲突，或需要把多条并行工作线组织起来时使用。
harness-stack 框架的引导纲要（bootstrap doctrine）。在会话开始时自动加载，用以介绍 lifecycle map、golden rules，以及如何挑选正确的 harness-stack:* skill。在一次会话中首次调用任何 harness-stack:* skill 之前，先读它。
复盘一次 harness-stack 使用，把值得上报的摩擦、缺陷或建议提成 GitHub Issue 反馈给上游。在完成一项任务、用完某个 skill 后有意见或改进想法，或想为框架本身留下改进线索时使用。