Back to Details

check

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Check

检查

Read-only verification of the agent's current work against a specific question. Produces a verdict-first answer backed by evidence from git state and codebase context.
Write
and 
Edit
are intentionally excluded from allowed-tools. This skill MUST NOT modify any files.
针对特定问题对Agent当前工作进行只读验证。基于git状态和代码库上下文的证据，先给出结论性回答。
允许使用的工具中刻意排除了Write和Edit。本技能绝对不能修改任何文件。

Workflow

工作流程

Follow all 4 steps sequentially.
按顺序执行以下4个步骤。

Step 1: Parse the Question

步骤1：解析问题

  1. Extract the question text from everything after 
    /check
    .
    • /check does the new endpoint handle errors?
      -> question is "does the new endpoint handle errors?"
    • /check
      (bare, no argument) -> must clarify
  2. Classify the question:
    • Verification -- expects YES / NO / PARTIAL (e.g., "is X done?", "does Y handle Z?", "are tests passing?")
    • Explanation -- expects a short description (e.g., "what changed in auth?", "how does the new caching work?")
    • General -- anything else; answer directly
  3. Clarification gate -- only ask using 
    AskUserQuestion
    if:
    • Bare 
      /check
      with no argument at all
    • Question references something outside the codebase that you cannot inspect (deployment environment, external system state, production data)
    Do NOT ask for clarification when the question is broad but interpretable. Instead, state your interpretation in the output and proceed.
  1. 从
    /check
    之后的内容中提取问题文本。
    • /check does the new endpoint handle errors?
      -> 问题为“does the new endpoint handle errors?”
    • /check
      （无参数）-> 必须进行澄清
  2. 对问题进行分类：
    • 验证类 -- 期望得到YES/NO/PARTIAL的回答（例如：“is X done?”、“does Y handle Z?”、“are tests passing?”）
    • 解释类 -- 期望得到简短描述（例如：“what changed in auth?”、“how does the new caching work?”）
    • 通用类 -- 其他类型；直接回答
  3. 澄清门槛 -- 仅在以下情况使用
    AskUserQuestion
    进行询问：
    • 仅输入
      /check
      且无任何参数
    • 问题涉及你无法检查的代码库外部内容（如部署环境、外部系统状态、生产数据）
    若问题宽泛但可解读，请勿要求澄清。而是在输出中说明你的解读并继续执行。

Step 2: Gather Evidence

步骤2：收集证据

Run these evidence-gathering steps. Use parallel tool calls where possible.
执行以下证据收集步骤。尽可能使用并行工具调用。

Always run (git state):

必须执行（git状态）：

bash
git status --short
bash
git diff
bash
git diff --staged
bash
git log --oneline -10
Edge case -- no git repo: If git commands fail, skip them. Use file reads and Grep only. This is not an error; state "Not a git repository -- checked files directly." in the output.
Edge case -- no changes: If all git commands return empty, that is a valid finding. The answer may be "nothing has changed."
bash
git status --short
bash
git diff
bash
git diff --staged
bash
git log --oneline -10
边缘情况 -- 非git仓库： 如果git命令执行失败，跳过这些命令。仅使用文件读取和Grep工具。这不属于错误，需在输出中说明“Not a git repository -- checked files directly.”。
边缘情况 -- 无变更： 如果所有git命令返回空结果，这是有效的发现。回答可为“nothing has changed.”。

Conditionally run (based on the question):

条件执行（基于问题类型）：

Question typeAction
Names specific files or pathsRead those files
Asks "how does X work" or "what does X do"Grep for X, read relevant files
Asks "do tests pass" or "are tests green"Run the test suite via Bash (read-only -- do NOT fix failures)
Asks about a function, class, or symbolGrep for its definition and usages
Asks about recent changes to a specific area
git log --oneline -20 -- {path}
and 
git diff -- {path}
问题类型操作
指定具体文件或路径读取这些文件
询问“how does X work”或“what does X do”搜索X相关内容，读取相关文件
询问“do tests pass”或“are tests green”通过Bash运行测试套件（只读 -- 请勿修复测试失败问题）
询问函数、类或符号相关问题搜索其定义和用法
询问特定区域的近期变更
git log --oneline -20 -- {path}
和 
git diff -- {path}

Step 3: Synthesize (conditional delegation)

步骤3：综合分析（条件委托）

Evaluate the complexity of the evidence gathered:
  • Simple (4 or fewer files to consider, single code path): Answer directly from the evidence. Skip to Step 4.
  • Complex (5+ files, multi-hop code paths, cross-module question): Spawn a single 
    Task
    agent (
    subagent_type: general-purpose
    ) with the following prompt structure:
You are a senior engineer reviewing recent work in a codebase.
评估收集到的证据的复杂度：
  • 简单（需考虑的文件不超过4个，单一代码路径）：直接根据证据回答。跳至步骤4。
  • 复杂（5个及以上文件、多跳代码路径、跨模块问题）：生成一个
    Task
    代理（
    subagent_type: general-purpose
    ），并使用以下提示结构：
你是一名资深工程师，正在审查代码库中的近期工作。

Question

问题

{the user's question}
{用户的问题}

Evidence

证据

{paste the git diff output, file contents, and any other gathered evidence}
{粘贴git diff输出、文件内容及其他收集到的证据}

Task

任务

Analyze the evidence and answer the question. Be specific:
  • Reference exact file paths and line numbers
  • For verification questions, state YES / NO / PARTIAL with justification
  • For explanation questions, describe what changed and why it matters
  • Note any gaps, risks, or incomplete work you observe
Keep your answer concise -- bullets over paragraphs.
undefined
分析证据并回答问题。请做到具体：
  • 引用确切的文件路径和行号
  • 对于验证类问题，说明YES/NO/PARTIAL并给出理由
  • 对于解释类问题，描述变更内容及其重要性
  • 指出你观察到的任何空白、风险或未完成的工作
保持回答简洁 -- 使用项目符号而非段落。
undefined

Step 4: Deliver the Answer

步骤4：交付回答

Output in this exact format:
markdown
undefined
严格按照以下格式输出：
markdown
undefined

Check: {question, truncated to ~60 chars if needed}

检查：{问题，若过长则截断至约60字符}

Verdict: YES | NO | PARTIAL | {direct answer for non-verification questions}
{One sentence expanding the verdict -- what makes it yes/no/partial, or the key takeaway.}
Evidence:
  • {file:line}
    -- {specific supporting detail}
  • {file:line}
    -- {specific supporting detail}
  • {up to 4 bullets total}
Could elaborate on: {1-2 follow-up angles the user might care about} (optional -- omit if the answer is complete) Suggestions: {1-2 actionable items if gaps were found} (optional -- omit if verdict is a clean YES)
undefined
结论： YES | NO | PARTIAL | {非验证类问题的直接回答}
{一句话扩展结论 -- 说明为何是YES/NO/PARTIAL，或核心要点。}
证据：
  • {文件:行号}
    -- {具体支持细节}
  • {文件:行号}
    -- {具体支持细节}
  • {最多4个项目符号}
可进一步说明： {1-2个用户可能关心的后续方向} （可选 -- 若回答完整则省略） 建议： {若发现空白则给出1-2个可操作项} （可选 -- 若结论为明确的YES则省略）
undefined

Format rules

格式规则

  • Verdict line is the most important output. A senior manager skimming should get the answer from that line alone.
  • No preamble -- do not start with "Let me check..." or "I'll look into...". Go straight to the output.
  • Use specific file paths and line numbers over vague descriptions like "the auth module."
  • Be direct about gaps. "PARTIAL -- error handling added for network errors but not for timeouts" is better than "mostly done."
  • If the question was interpreted (broad but not ambiguous), state the interpretation: 
    **Interpreted as:** "Did the recent changes add input validation to the /users endpoint?"
  • Omit the optional sections rather than padding them with filler.
  • 结论行是最重要的输出内容。 资深管理者浏览时应能仅通过该行得到答案。
  • 无需开场白 -- 不要以“Let me check...”或“I'll look into...”开头。直接输出结果。
  • 优先使用确切的文件路径和行号，而非模糊描述如“the auth module”。
  • 直接指出空白。例如“PARTIAL -- 已为网络错误添加错误处理，但未处理超时情况”比“基本完成”更好。
  • 若问题被解读（宽泛但无歧义），需说明解读内容：
    **解读为：** "Did the recent changes add input validation to the /users endpoint?"
  • 可选部分若没有内容则省略，不要填充无关信息。

Guidelines

指导原则

  • This skill is strictly read-only. Never suggest running a write operation and never attempt to fix issues found during checking.
  • Prefer evidence from 
    git diff
    (what actually changed) over file reads (current state) when both are available.
  • For "do tests pass" questions, run the test command and report the result. Do not attempt to fix failing tests.
  • If the evidence is ambiguous, say so. "PARTIAL -- cannot confirm without running the integration suite" is a valid verdict.
  • Keep the total output under 30 lines. This is a spot-check, not a full audit.
  • 本技能为严格只读。绝不建议执行写入操作，也绝不能在检查过程中尝试修复发现的问题。
  • 当同时有git diff（实际变更内容）和文件读取（当前状态）的证据时，优先使用git diff的证据。
  • 对于“do tests pass”类问题，运行测试命令并报告结果。请勿尝试修复失败的测试。
  • 若证据存在歧义，需明确说明。例如“PARTIAL -- 若不运行集成测试套件则无法确认”是有效的结论。
  • 总输出行数控制在30行以内。这是抽查，而非全面审计。