verify

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Every change must be verified before declaring completion, including documentation-only changes.
If
$ARGUMENTS
is provided (
auto
,
minimal
,
code
,
proof
,
proto
,
full
), use it as a hint to prioritize relevant scopes. If
$ARGUMENTS
is absent or ambiguous, use automatic scope detection.
所有变更在宣布完成前都必须经过验证,包括仅涉及文档的变更。
如果提供了
$ARGUMENTS
(可选值:
auto
minimal
code
proof
proto
full
),可将其作为优先级参考来筛选相关范围。如果
$ARGUMENTS
不存在或含义模糊,则使用自动范围检测。

Blast-radius analysis (always first)

影响范围分析(始终优先执行)

Before selecting test commands, run the blast-radius detector script:
bash
python3 "$SKILL_DIR/scripts/blast_radius.py"
The script reads
.blast-radius.yaml
from the repo root for project-specific configuration (core crates, risk areas, commands). Without that file it still works using built-in Rust workspace defaults.
See
blast-radius.example.yaml
in this skill's directory for the full config schema with comments.
The script returns JSON with these fields:
  • changed_files
  • affected_modules
  • risk_flags
  • docs_only
  • recommended_scopes
  • recommended_commands
  • broad_impact
Use
recommended_commands
as the source of truth. Run them in the order listed.
If the script is unavailable or fails, use this fallback procedure:
  1. List changed files (staged and unstaged). If there are no local changes, compare against
    main
    if available.
  2. Map changed paths to affected areas:
    • proto/
    • crates/<crate-name>/
    • docs-only changes (
      docs/
      ,
      README.md
      , markdown/adoc/rst/txt prose)
  3. Run
    cargo check --workspace --tests --all-features
    (always).
  4. If runtime code changed, run
    cargo nextest run --workspace
    .
在选择测试命令前,先运行影响范围检测脚本:
bash
python3 "$SKILL_DIR/scripts/blast_radius.py"
该脚本会读取代码库根目录下的
.blast-radius.yaml
文件获取项目专属配置(核心crate、风险区域、命令)。即使没有该文件,它也能基于内置的Rust工作区默认规则运行。
可查看本skill目录下的
blast-radius.example.yaml
文件,获取带注释的完整配置schema。
脚本会返回包含以下字段的JSON:
  • changed_files
  • affected_modules
  • risk_flags
  • docs_only
  • recommended_scopes
  • recommended_commands
  • broad_impact
请以
recommended_commands
的内容为准,按列出的顺序执行。
如果脚本不可用或运行失败,请使用以下备用流程:
  1. 列出已暂存和未暂存的变更文件。如果没有本地变更,可在可用的情况下与
    main
    分支对比。
  2. 将变更路径映射到受影响区域:
    • proto/
    • crates/<crate-name>/
    • 仅文档变更(
      docs/
      README.md
      、markdown/adoc/rst/txt类文本)
  3. 始终执行
    cargo check --workspace --tests --all-features
  4. 如果运行时代码发生了变更,执行
    cargo nextest run --workspace

Docs-only branch

仅文档分支

If blast-radius reports
docs_only: true
:
  • Run
    recommended_commands
    from blast-radius output.
  • Skip runtime-heavy scopes (
    code
    ,
    proof
    ,
    proto
    ) unless the user explicitly requested them via
    $ARGUMENTS
    .
如果影响范围检测返回
docs_only: true
  • 执行影响范围输出中的
    recommended_commands
  • 跳过运行时开销大的范围(
    code
    proof
    proto
    ),除非用户通过
    $ARGUMENTS
    明确要求执行。

Scopes

执行范围

Run all matching scopes (scopes are cumulative).
minimal
always runs. Additional scopes come from blast-radius output, optionally constrained by
$ARGUMENTS
.
The exact commands for each scope are determined by blast-radius based on the project's
.blast-radius.yaml
configuration. Always prefer
recommended_commands
from the JSON output over manually constructing commands.
If
$ARGUMENTS
explicitly requests additional scopes beyond what blast-radius recommended, run the standard Rust verification for those scopes:
  • minimal:
    cargo check --workspace --tests --all-features
  • code:
    cargo nextest run --workspace
  • full: all of the above plus any scope-specific commands from blast-radius
运行所有匹配的范围(范围是累加的)。
minimal
范围始终执行。额外的范围来自影响范围检测的输出,可选择通过
$ARGUMENTS
进行约束。
每个范围的具体命令由影响范围检测基于项目的
.blast-radius.yaml
配置决定。始终优先使用JSON输出中的
recommended_commands
,不要手动拼接命令。
如果
$ARGUMENTS
明确要求了影响范围检测推荐之外的额外范围,请为这些范围执行标准的Rust验证:
  • minimal:
    cargo check --workspace --tests --all-features
  • code:
    cargo nextest run --workspace
  • full: 以上所有命令,外加影响范围检测返回的所有范围专属命令

Fix-and-rerun protocol

修复重跑规则

  • If checks fail, attempt focused fixes for failures plausibly caused by your changes, then rerun checks.
  • Stop after 2 fix-and-rerun cycles, or if failures appear unrelated to your changes.
  • Hand control back with a brief summary of what passed, what failed, and what you tried.
  • 如果检查失败,请尝试针对性修复由你的变更大概率导致的问题,然后重新运行检查。
  • 最多进行2次修复重跑循环,如果失败看起来和你的变更无关也请停止。
  • 交还控制权,简要说明哪些通过、哪些失败,以及你尝试过的操作。

Reporting

报告要求

Always report:
  • Exact command(s) run.
  • Whether each passed or failed.
  • If failed: the relevant error output.
  • Blast-radius result summary and chosen scope rationale.
始终报告以下内容:
  • 执行的准确命令。
  • 每条命令的通过/失败状态。
  • 如果失败:相关的错误输出。
  • 影响范围检测结果摘要和选择执行范围的理由。