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.
运行所有适用的质量检查：
  • Tests（测试） — 运行完整测试套件。如果测试失败，修复问题后重新运行，最多重试3次。如果3次尝试后仍无法解决失败问题，请继续后续步骤并在总结中记录失败情况。
  • Linting（代码检查） — 运行代码检查工具并修复所有发现的问题。
  • Type checking（类型检查） — 运行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

查看当前分支相较于基准分支添加了哪些变更日志条目

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

将 <base_branch> 替换为问题上下文里的实际基准分支

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

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

**添加或更新条目规则：**
- 将条目放在 `## [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问题链接：关联对应的Linear问题
  • Cyrus标记：在正文末尾添加隐藏HTML注释 
    <!-- generated-by-cyrus -->
  • 交互提示：在标记前添加以下内容，使用系统提示中 
    <agent_context>
    块里的 
    <github_bot_username>
    或 
    <gitlab_bot_username>
    作为机器人用户名。如果不存在 
    <agent_context>
    ，默认使用 
    cyrusagent
    ： 
    ---
> **提示：** 在此PR/MR中@提及@<bot_username>，我会回复相关评论。你也可以一次性提交所有反馈进行评审，我会自动处理每条评论。
移除标题中的"WIP:"或"Draft:"前缀。查看 
<agent_guidance>
— 只有当指导中未指定保持草稿状态时，才将PR/MR标记为就绪。
验证PR/MR的目标基准分支是否与问题上下文里的 
<base_branch>
一致。