Back to Details

verify-and-ship

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Verify and Ship

验证与交付

After implementing your changes, follow these steps to verify quality and ship the work.
在完成代码变更后，请按照以下步骤验证质量并交付工作成果。

1. Acceptance Criteria Validation (CRITICAL)

1. 验收标准验证（至关重要）

Use the issue tracker 
get_issue
tool to fetch the current issue details. Extract ALL acceptance criteria from the issue description and verify each one is satisfied by the implementation. If no explicit criteria exist, validate against the implied requirements from the issue title and description.
使用问题追踪工具 
get_issue
获取当前问题的详细信息。从问题描述中提取所有验收标准，并验证每项标准是否已被实现满足。如果没有明确的验收标准，则根据问题标题和描述中的隐含要求进行验证。

2. Quality Checks

2. 质量检查

Run all applicable quality checks:
  • Tests — Run the full test suite. If tests fail, fix the issues and re-run. Retry up to 3 times. If you cannot resolve failures after 3 attempts, proceed and note the failures in your summary.
  • Linting — Run linting tools and fix any issues found.
  • Type checking — Run TypeScript type checking (if applicable) and fix any errors.
  • Code review — Review your changes for quality, consistency, and best practices. Remove any debug code, console.logs, or commented-out sections.
运行所有适用的质量检查：
  • 测试 — 运行完整的测试套件。如果测试失败，修复问题后重新运行，最多重试3次。如果3次尝试后仍无法解决失败问题，请继续后续步骤并在总结中记录失败情况。
  • 代码检查 — 运行代码检查工具并修复所有发现的问题。
  • 类型检查 — 运行TypeScript类型检查（如适用）并修复所有错误。
  • 代码评审 — 检查你的变更是否符合质量、一致性和最佳实践要求。移除所有调试代码、console.log语句或注释掉的代码段。

3. Changelog Update

3. 更新变更日志

Check if the project has changelog files:
bash
ls -la CHANGELOG.md CHANGELOG.internal.md 2>/dev/null || echo "NO_CHANGELOG"
If changelog files exist, diff against the base branch to detect entries already added by this branch:
bash
undefined
检查项目是否包含变更日志文件：
bash
ls -la CHANGELOG.md CHANGELOG.internal.md 2>/dev/null || echo "NO_CHANGELOG"
如果存在变更日志文件，与基准分支对比差异，检测当前分支已添加的条目：
bash
undefined

See what changelog lines this branch has added compared to the base branch

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

Replace <base_branch> with the actual base branch from the issue context

git diff <base_branch> -- CHANGELOG.md CHANGELOG.internal.md 2>/dev/null

**Handling existing entries:**
- If the diff shows this branch already added a changelog entry for the current issue (matching the issue identifier), **update that entry in-place** (e.g., to add the PR/MR link or refine the description). Do NOT add a duplicate entry.
- If the diff shows this branch added changelog entries for a different issue or no entries at all, add a new entry.

**Adding or updating entries:**
- Place entries under `## [Unreleased]` in the appropriate subsection (`### Added`, `### Changed`, `### Fixed`, `### Removed`)
- Focus on end-user impact — be concise but descriptive
- Include the Linear issue identifier and PR/MR link (format: `([ISSUE-ID](linear_url), [#NUMBER](PR_OR_MR_URL))`)
- Follow [Keep a Changelog](https://keepachangelog.com/) format
git diff <base_branch> -- CHANGELOG.md CHANGELOG.internal.md 2>/dev/null

**处理现有条目：**
- 如果差异显示当前分支已为该问题添加了变更日志条目（匹配问题标识符），**就地更新该条目**（例如，添加PR/MR链接或优化描述）。请勿添加重复条目。
- 如果差异显示当前分支为其他问题添加了条目，或未添加任何条目，则添加新条目。

**添加或更新条目：**
- 将条目放在`## [Unreleased]`下的对应子部分（`### Added`、`### Changed`、`### Fixed`、`### Removed`）中
- 聚焦于对终端用户的影响——简洁且具有描述性
- 包含Linear问题标识符和PR/MR链接（格式：`([ISSUE-ID](linear_url), [#NUMBER](PR_OR_MR_URL))`）
- 遵循[Keep a Changelog](https://keepachangelog.com/)格式

4. Commit and Push

4. 提交与推送

  • Stage all relevant changes (including changelog updates)
  • Commit with clear, descriptive messages following the project's commit conventions
  • Push to the remote repository
  • 暂存所有相关变更（包括变更日志更新）
  • 遵循项目的提交规范，使用清晰、具有描述性的提交信息
  • 推送到远程仓库

5. Create or Update PR/MR

5. 创建或更新PR/MR

Determine the platform from the repository context (
<github_url>
or 
<gitlab_url>
in the issue context). Use the appropriate tool for the platform.
根据仓库上下文确定平台（问题上下文中的
<github_url>
或
<gitlab_url>
），使用对应平台的工具。

GitHub (when 
<github_url>
is present)

GitHub（当存在
<github_url>
时）

bash
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"
bash
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 (when 
<gitlab_url>
is present)

GitLab（当存在
<gitlab_url>
时）

bash
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"
bash
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 Description

PR/MR描述

Update the PR/MR with a comprehensive description:
  • Assignee attribution: If 
    <github_username>
    is available in the assignee context, add 
    Assignee: @username ([Display Name](linear_profile_url))
    at the top of the body. If only a linear profile URL is available, use 
    Assignee: [Display Name](linear_profile_url)
    .
  • Summary of changes, implementation approach, and testing performed
  • Link to the Linear issue
  • Cyrus marker: Include 
    <!-- generated-by-cyrus -->
    as a hidden HTML comment at the end of the body
  • Interaction tip: Add this at the end (before the marker), using the bot username from 
    <github_bot_username>
    or 
    <gitlab_bot_username>
    in the 
    <agent_context>
    block of the system prompt. If 
    <agent_context>
    is not present, default to 
    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.
Remove any "WIP:" or "Draft:" prefix from the title. Check 
<agent_guidance>
— only mark the PR/MR as ready if guidance does NOT specify keeping them as drafts.
Verify the PR/MR targets the correct base branch from 
<base_branch>
in the issue context.
为PR/MR添加全面的描述：
  • 经办人信息：如果经办人上下文中包含
    <github_username>
    ，在描述顶部添加
    Assignee: @username ([Display Name](linear_profile_url))
    。如果仅提供了Linear个人资料链接，则使用
    Assignee: [Display Name](linear_profile_url)
  • 变更总结：说明变更内容、实现方式以及已执行的测试
  • 问题链接：添加Linear问题的链接
  • Cyrus标记：在描述末尾添加隐藏的HTML注释
    <!-- generated-by-cyrus -->
  • 交互提示：在标记之前添加以下内容，使用系统提示中
    <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的目标基准分支是否与问题上下文中的
<base_branch>
一致。