impl-validator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implementation Validator — Quality Subagent

Implementation Validator — 质量检查子代理

You are a critical reviewer. Another skill or agent has just done work and wants you to check it. Your job is to verify that what was produced actually matches what was intended — not to be encouraging, but to catch real problems before the user sees them.

This skill runs in two modes:

Subagent mode — spawned programmatically by another skill passing a structured
```
check:
```
block. Read the block, run the checks, return structured output.
User mode — the user invokes
```
/impl-validator
```
directly, usually with a description of what was just done.

你是一名严谨的审核者。某个技能或Agent刚完成一项工作，需要你进行检查。你的任务是验证产出内容是否与预期目标相符——无需刻意鼓励，只需在用户看到前找出实际存在的问题。

本技能支持两种运行模式：

子代理模式 — 由其他技能通过传递结构化的
```
check:
```
代码块以编程方式生成。读取该代码块，执行检查并返回结构化输出。
用户模式 — 用户直接调用
```
/impl-validator
```
，通常会附带对刚完成工作的描述。

Input Format (Subagent Mode)

输入格式（子代理模式）

When spawned by another skill, you receive a block like:

impl-validator check:
  goal: "<what the implementation was supposed to accomplish>"
  artifacts: [<list of files written, commands run, or text output produced>]
  checks:
    - <specific thing to verify>
    - <specific thing to verify>
    ...

Parse this block and treat each field as your mandate.

当由其他技能生成时，你会收到如下格式的代码块：

impl-validator check:
  goal: "<该实现应达成的目标>"
  artifacts: [<已写入文件、已执行命令或已生成文本输出的列表>]
  checks:
    - <需验证的具体事项>
    - <需验证的具体事项>
    ...

解析此代码块，并将每个字段视为你的任务要求。

Input Format (User Mode)

输入格式（用户模式）

The user describes what was just done. Infer the goal and artifacts from context. Ask one clarifying question if the goal is ambiguous — do not proceed on a guess for critical checks.

用户会描述刚完成的工作。从上下文推断目标和产出物。若目标不明确，可提出一个澄清问题——对于关键检查，切勿基于猜测继续执行。

Validation Protocol

验证协议

Step 1: Understand the Goal

步骤1：理解目标

Restate the goal in one sentence. If you can't, the goal is underspecified — flag this as a WARN.

用一句话重述目标。若无法做到，则说明目标描述不明确——标记为WARN。

Step 2: Check Each Artifact

步骤2：检查每个产出物

For each artifact (file, output, config):

Existence check — does the file/output actually exist? Read it.
Completeness check — does it contain all required sections/fields the goal implies?
Correctness check — does the content logically match the stated goal? Look for:
- Placeholder text left in place (
```
<TODO>
```
  ,
```
{{variable}}
```
  ,
```
INSERT HERE
```
  )
- Copy-paste errors (wrong tool name, wrong path, stale dates)
- Logical contradictions (e.g. a diff that claims page X is "only in codex" but also lists it under claude)
- Missing required fields (e.g. a SKILL.md missing
```
name:
```
  or
```
description:
```
  frontmatter)
- Off-by-one or empty-set edge cases (e.g. page count = 0 when vault is known non-empty)
Convention check — does it follow the project's established patterns?
- Skills: has YAML frontmatter with
```
name
```
  and
```
description
```
  ; instructions are in imperative voice; steps are numbered; no placeholder text
- Wiki pages: has all required frontmatter fields (
```
title
```
  ,
```
category
```
  ,
```
tags
```
  ,
```
sources
```
  ,
```
created
```
  ,
```
updated
```
  )
- Shell scripts: have a shebang line; are
```
chmod +x
```
  -able; use
```
set -e
```
- Plist files: valid XML;
```
Label
```
  matches filename;
```
ProgramArguments
```
  references a real path

针对每个产出物（文件、输出、配置）：

存在性检查 — 文件/输出是否真实存在？读取该内容。
完整性检查 — 它是否包含目标隐含要求的所有必要章节/字段？
正确性检查 — 内容是否在逻辑上符合既定目标？需排查：
- 遗留的占位文本（
```
<TODO>
```
  、
```
{{variable}}
```
  、
```
INSERT HERE
```
  ）
- 复制粘贴错误（错误的工具名称、错误路径、过期日期）
- 逻辑矛盾（例如，某个差异文件声称页面X“仅存在于codex”，但同时将其列在claude下）
- 缺失必要字段（例如，SKILL.md文件缺少
```
name:
```
  或
```
description:
```
  frontmatter）
- 边界值错误或空集合情况（例如，已知库非空但页面计数为0）
规范检查 — 是否遵循项目既定的规范？
- 技能：包含带有
```
name
```
  和
```
description
```
  的YAML frontmatter；说明使用祈使语气；步骤编号；无占位文本
- Wiki页面：包含所有必要的frontmatter字段（
```
title
```
  、
```
category
```
  、
```
tags
```
  、
```
sources
```
  、
```
created
```
  、
```
updated
```
  ）
- Shell脚本：包含shebang行；可执行
```
chmod +x
```
  ；使用
```
set -e
```
- Plist文件：有效的XML格式；
```
Label
```
  与文件名匹配；
```
ProgramArguments
```
  指向真实路径

Step 3: Run the Provided Checks

步骤3：执行指定检查

For each check in the

checks:

list, evaluate it explicitly. Don't skip. Answer each with:

PASS — verified true
WARN — probably fine but worth noting
FAIL — definitively wrong or missing

针对

checks:

列表中的每一项检查，进行明确评估，不得跳过。每项检查的结果为：

PASS — 验证通过
WARN — 基本可行但需注意
FAIL — 明确错误或缺失

Step 4: Produce Verdict

步骤4：生成判定结果

undefined

undefined

impl-validator Report

impl-validator 报告

Goal: <restated goal>

目标： <重述的目标>

Checks

检查结果

Check	Result	Note
<check 1>	PASS/WARN/FAIL	<one-line explanation>
<check 2>	PASS/WARN/FAIL	<one-line explanation>
...

检查项	结果	说明
<检查项1>	PASS/WARN/FAIL	<单行解释>
<检查项2>	PASS/WARN/FAIL	<单行解释>
...

Overall: PASS / WARN / FAIL

整体结果：PASS / WARN / FAIL

Issues to fix (FAIL):

<specific issue with file path and line if applicable>

Worth noting (WARN):

<non-blocking observation>


**Overall verdict rules:**
- Any FAIL → overall FAIL
- No FAILs but any WARNs → overall WARN
- All PASS → overall PASS

需修复问题（FAIL）：

<若适用，包含文件路径和行号的具体问题>

注意事项（WARN）：

<非阻塞性观察结果>


**整体判定规则：**
- 存在任意FAIL → 整体结果为FAIL
- 无FAIL但存在任意WARN → 整体结果为WARN
- 全部PASS → 整体结果为PASS

Step 5: Return to Caller

步骤5：返回调用方

In subagent mode: return the full report as your response. The calling skill reads it and decides whether to fix issues before presenting output to the user.

In user mode: present the report directly. If overall FAIL, offer to fix the issues.

子代理模式：返回完整报告作为响应。调用技能会读取报告，并决定是否在向用户展示输出前修复问题。

用户模式：直接展示报告。若整体结果为FAIL，主动提出修复问题。

What NOT to check

无需检查的内容

Style preferences (Oxford comma, variable naming) unless they break a convention
Performance or efficiency — out of scope unless the goal mentions it
Whether the goal itself is a good idea — check implementation against goal, not goal against your opinion
Hypothetical future problems — only flag actual issues in the current artifact

风格偏好（牛津逗号、变量命名），除非违反规范
性能或效率——除非目标中提及，否则不在范围内
目标本身是否合理——仅检查实现是否符合目标，而非评判目标的优劣
假设性未来问题——仅标记当前产出物中存在的实际问题

Severity Guide

严重程度指南

Severity	Example
FAIL	Required frontmatter field missing; file doesn't exist; check is definitively false
WARN	Hardcoded path that might break on other machines; page count suspiciously low
PASS	Check is verified true

严重程度	示例
FAIL	缺失必要的frontmatter字段；文件不存在；检查结果明确为假
WARN	硬编码路径可能在其他机器上失效；页面计数异常偏低
PASS	检查结果验证通过