implement-publish

实施并发布

根据规范完成实现和独立的本地审查，然后将其发布为且仅为一个拉取请求。发布意味着推送经过审查的分支并创建或更新其拉取请求，绝不合并或部署。已发布的审查由 review-code-publish 负责。

在用户指示、用户指定的任何实现技能以及仓库约定范围内，实施方法、调查、步骤安排、工具和额外验证均由你选择。

确定交付事项

确定 Forge、源仓库和目标仓库、基准分支，以及此更改涉及的所有问题、工单和书面规范，包括根据请求、分支和提交推断出的内容。如存在 docs/agents/issue-tracker.md 等文件，请使用其中的仓库跟踪配置。在进行任何外部写入之前，先消除会造成重大影响的歧义，同时继续进行独立的本地工作。

如果未安装 review-code 技能，请在实施前报告 missing-dependency: review-code。

在适合作为拉取请求头的分支上工作，绝不要在基准分支上工作。不要更改问题状态、标签或指派对象。

实施并保留证据

完成所请求的功能并提交。运行仓库为受影响功能及其依赖项记录的检查。根据更改的风险选择进一步检查和验收测试；如果影响范围不确定，应进行更广泛的验证。

在 review-code 的 references/rubric.md 中的「Supplied checks」部分下保留简洁的证据摘要；该部分负责规定其格式和复用规则。为每项验收测试记录验收标准、方法和观察结果，以及任何尚未完成的必要工作及其原因。更改后，更新摘要，注明哪些证据仍然适用、哪些已被替代。切勿仅为填写摘要而重新运行检查。

在本地审查

在通过门禁之前，所有内容都保留在本地。

使用一个全新上下文的审查者，它未看过实现对话，并且可以调度 review-code 的验证器。遵循调用方指定的审查者等级，并在每次继续时保持所选等级不变。

在调度或继续审查之前，选择一条能在你保持活动状态时返回完整结果的路径：前台返回结果，或调度后使用受支持的等待方式。确认消息或 Agent 标识符不代表审查已完成。若没有这样的路径，则不要调度任何内容，并报告 review-wait-unavailable，注明阶段、缺少的操作和待处理工作。切勿更改全局运行时设置来获得此路径。

向审查者说明，需对本地 base-to-head 范围以 mode: one-shot 调用 review-code。提供仓库、明确的 base 和已提交的 head、所有规范来源，以及包含缺口的证据摘要：只陈述观察结果和产物，不提供实现理由或正确性主张。要求返回已完成的状态、覆盖情况，以及 record.json、payload.json、batch.json 和 report.md 的路径。

阅读 report.md，并在门禁下验证记录，然后再接受它。按顺序保留每条已接受记录的绝对路径。根据代码和规范评估发现；修复有依据的缺陷、验证并提交。只有在有证据的情况下才能驳回某项发现；存在争议的 must-fix 会阻止流程继续，直到审查结果明确。

修复或出现新信息后，即使代码未更改，也要通过恢复已完成的审查者或使用另一个隔离的审查者来继续审查。提供最新已接受记录作为 prior_record、未更改的 base 和规范来源、此前审查的提交 SHA 和最终提交 SHA、已修复的发现 ID，以及说明保留或失效原因的更新证据。

review-code 负责审查范围、发现分类、沿用的确认项、未解决的问题和验证器核算。其验证额度由多次继续共用：更换工作者、工作失败或修复都不会带来新的额度，替换审查者也不能绕过待处理工作。在 review-code-record/1 之前生成的记录不能作为 prior_record；应改为说明执行完整的 base-to-head 审查，不提供 prior_record，并让其覆盖情况注明较早的记录。

门禁

根据已提交的 head、按顺序排列的所有已接受记录以及记录本身，验证每条返回的记录：

python3 <skill root>/scripts/render_review.py --check --head <committed head> --lineage <each accepted record> --lineage <candidate record> <private-dir>

<skill root> 是记录中 record.paths.skill_root 的值。非零退出状态表示报告缺失、记录无效、head 不一致，或继续审查时基于较早的已接受记录分叉。丢弃该记录，并从最新已接受的记录继续。

退出状态为 0 表明产物可用，且与 head 和历史记录相符，并不代表已批准。只有当最终记录的检查指明你将要推送的提交，并打印 status Approved 和 coverage complete 时，才可发布：这表示没有尚未完成的必需审查工作、证据或验证。

Needs Information、Changes Requested 和 Incomplete 都意味着不得发布。解决审查者提出的需求并继续审查；未得到答复的问题绝不构成发布授权。获批后可以保留 consider 类发现。之后的任何提交都必须经过审查。如果无法满足门禁，说明原因并在发布前停止。

发布

推送已审核的提交。查找一个开放的拉取请求，其源仓库和目标仓库及分支均匹配，并更新其正文或创建一个。确认在已审核的提交上恰好有一个匹配的开放拉取请求。

遵循仓库的标题和正文惯例。否则，撰写一份可在一分钟内读完的简报，包含 ## Why、## Scope、## Tradeoffs、## Blast Radius 和 ## Verification，省略空白部分。根据实际关系链接所有规范来源和 issue，说明部分实现尚待完成的工作，并对已完成的 issue 使用代码托管平台的关闭语法，或注明平台不支持该语法。保留每项验证结果对应的提交、输入状态和差距。将大量证据作为链接提供，并给出性能声明的前后测量值。

每项外部写入操作只尝试一次。结果不明确时，先读取目标，再重试一次，然后报告尚未解决的失败，不要再次写入。

最后提供拉取请求 URL、提交、分支、规范来源、审核结果、剩余的可选发现或问题，以及任何失败。