SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场verify-and-ship

verify-and-ship

编程与开发

查看项目

更新于 10-15 14:31

技能介绍

用途

verify-and-ship 是一个用于 AI 编码智能体的技能，目标是在代码实现完成后，对改动进行验证并把工作交付出去。它覆盖从验收标准核对、质量检查、变更日志更新，到提交、推送以及创建或更新 PR/MR 的完整收尾流程。

主要能力

1. 验收标准验证（关键）

使用 issue tracker 的 get_issue 工具获取当前 issue 详情，从 issue 描述中提取全部验收标准，并逐条确认实现是否满足。如果没有显式标准，则依据 issue 标题和描述中的隐含需求进行验证。

2. 质量检查

根据改动行为、风险和现有覆盖情况选择验证方式。验证是必需的，但并非每次改动都需要新增自动化测试或运行全量套件。应遵循仓库特定的检查与 CI 门禁。

  • 直接验证：对于常规发布脚本、打包/构建元数据、CI、文档和说明性编辑，优先使用语法检查、安全 dry run、产物检查、隔离安装冒烟测试或一致性审查。在 PR 中记录所执行的命令/结果或审查内容，不必仅为展示工作而新增测试文件或验证报告。
  • 自动化测试：运行相关的现有测试。仅当某个回归测试能捕获具体的重大失败且其保护价值足以支撑维护成本时，才新增或保留该测试。例如发布错误产物、意外移动稳定标签、接受无效发布证据等。需说明每个新测试捕获的失败。不要添加针对文档措辞或源文本的脆弱断言、镜像实现的测试，或为低风险编辑搭建复杂脚手架。仅凭脚本文件名既不能要求测试，也不能豁免重大行为的保护。
  • 范围：当共享行为、失败或未解决风险需要时扩大测试范围；不要自动运行全量套件或生成覆盖率报告。一旦足够的检查通过，除非有改动或新证据，否则不要重复运行。应调查相关失败，而不是对未改动的命令反复重试。如实报告任何未解决的失败。
  • Lint、类型、构建：运行与改动文件相关以及仓库要求的检查，修复引入的失败。
  • 审查：检查正确性、范围和可维护性，包括所提议的测试是否提供有用的保护。

如果仓库使用 F1，在调用 drive 或请求证据前，先应用其规范的 skills/f1-test-drive/SKILL.md 适用性策略。不适用 F1 的改动需要按比例检查并在 PR 中简要说明，无需 F1 运行或报告。不要从本技能推断出 F1 要求。保留针对重大失败的现有保护措施。

3. 变更日志更新

检查项目是否存在变更日志文件：

ls -la CHANGELOG.md CHANGELOG.internal.md 2>/dev/null || echo "NO_CHANGELOG"

如果存在，则与基础分支做 diff，检测本分支已添加的条目：

# See what changelog lines this branch has added compared to the base branch
# Replace <base_branch> with the actual base branch from the issue context
git diff <base_branch> -- CHANGELOG.md CHANGELOG.internal.md 2>/dev/null

处理已有条目：

  • 如果 diff 显示本分支已为当前 issue（匹配 issue 标识符）添加了变更日志条目，则就地更新该条目（例如补充 PR/MR 链接或完善描述），不要添加重复条目。
  • 如果 diff 显示本分支为其他 issue 添加了条目，或完全没有条目，则新增一条。

添加或更新条目：

  • 将条目放在 ## [Unreleased] 下合适的子章节（### Added、### Changed、### Fixed、### Removed）
  • 聚焦最终用户影响，简洁但描述清晰
  • 包含 Linear issue 标识符和 PR/MR 链接（格式：(ISSUE-ID, #NUMBER)）
  • 遵循 Keep a Changelog 格式

4. 提交与推送

  • 暂存所有相关改动（包括变更日志更新）
  • 按项目提交约定，使用清晰、描述性的提交信息
  • 推送到远程仓库

5. 创建或更新 PR/MR

根据仓库上下文（issue 上下文中的 <github_url> 或 <gitlab_url>）确定平台，并使用相应工具。

GitHub（当存在 <github_url> 时）：

git push -u origin HEAD
gh pr view --json url,number 2>/dev/null || gh pr create --draft --base [base_branch from context] --title "[descriptive title]" --body "Work in progress"

GitLab（当存在 <gitlab_url> 时）：

git push -u origin HEAD
glab mr view 2>/dev/null || glab mr create --draft --target-branch [base_branch from context] --title "[descriptive title]" --description "Work in progress"

PR/MR 描述：

  • 指派归属：如果指派上下文中存在 <github_username>，在正文顶部添加 Assignee: @username (Display Name)。如果只有 linear 个人资料 URL，则使用 Assignee: Display Name。
  • 变更摘要、实现方式和已执行的测试
  • 链接到 Linear issue
  • Cyrus 标记：在正文末尾包含 <!-- generated-by-cyrus --> 作为隐藏 HTML 注释
  • 交互提示：在标记之前添加以下内容，使用系统提示 <agent_context> 块中的 <github_bot_username> 或 <gitlab_bot_username>。如果 <agent_context> 不存在，默认使用 cyrusagent：
---
> **Tip:** I will respond to comments that @ mention @<bot_username> on this PR/MR. You can also submit a review with all your feedback at once, and I will automatically wake up to address each comment.

从标题中移除任何 "WIP:" 或 "Draft:" 前缀。检查 <agent_guidance>——仅当指引未要求保持草稿状态时，才将 PR/MR 标记为就绪。

确认 PR/MR 的目标基础分支与 issue 上下文中的 <base_branch> 一致。

使用方式

该技能以 SKILL.md 形式提供，供 AI 编码智能体在完成代码改动后按步骤执行。它依赖 issue tracker 工具（get_issue）、git、gh 或 glab 等命令行工具，以及仓库自身的检查与 CI 配置。

适用场景

适用于 AI 智能体在实现 issue 后需要验证质量并交付代码的工作流，尤其是需要核对验收标准、按比例选择测试、更新变更日志并创建 PR/MR 的场景。

限制

验证是必需的，但新增自动化测试和全量套件运行并非每次改动都必需。不要添加脆弱的文档措辞断言或镜像实现的测试。不要自动运行全量套件或生成覆盖率报告。不要从本技能推断 F1 要求。应如实报告未解决的失败。关于收费、价格、平台支持范围等具体信息，资料中暂未提供。