Back to Details

piv-validate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Validate

验证

Run every check this project has and report a single PASS/FAIL verdict.

⚠️ Make this yours first

This skill is a template. The command list below is a placeholder — replace it with the commands your project actually uses. That is the entire point of a custom checker: it is the one skill that cannot be generic, because it wraps your stack's CLIs.
Find your real commands in 
package.json
scripts, 
pyproject.toml
, 
Makefile
, 
justfile
, 
docker-compose.yml
, your CI workflow, or the README — then delete these and paste yours in.
Two things to get right, because they are the usual reason a checker silently lies:
  1. Working directory. Many tools only discover their config from the current directory. If your config lives in 
    backend/pyproject.toml
    , the command is 
    cd backend && uv run pytest
    , not 
    uv run pytest
    from the repo root.
  2. Cross-platform. Avoid POSIX-only idioms if anyone on the team is on Windows — 
    lsof
    , 
    python3
    , and background-then-
    kill
    are the common offenders.
Run the checks in order. Keep going after a failure so the report covers everything, and capture the output of any command that fails.
运行项目的所有检查并输出单一的 PASS/FAIL 结果。

⚠️ 先自定义适配你的项目

本 Skill 是一个模板。下方的命令列表仅为占位符——请将其替换为你的项目实际使用的命令。 这正是自定义检查工具的意义所在：它是唯一一个无法通用的 Skill，因为它需要适配你技术栈的 CLI 工具。
你可以在 
package.json
脚本、
pyproject.toml
、
Makefile
、
justfile
、
docker-compose.yml
、CI 工作流或 README 文件中找到实际命令——然后删除这些占位符并粘贴你的命令。
有两点需要特别注意，因为它们通常是检查工具静默失效的原因：
  1. 工作目录。 许多工具仅从当前目录读取配置。如果你的配置位于 
    backend/pyproject.toml
    ，那么命令应为 
    cd backend && uv run pytest
    ，而非从仓库根目录执行 
    uv run pytest
    。
  2. 跨平台兼容性。 如果团队中有成员使用 Windows，请避免仅适用于 POSIX 系统的语法——
    lsof
    、
    python3
    以及后台启动后再 
    kill
    的方式是常见的问题点。
按顺序运行检查。即使某一步失败也要继续执行，以便报告涵盖所有内容，并捕获任何失败命令的输出。

1. Tests

1. 测试

bash
undefined
bash
undefined

REPLACE: your test command, run from the right directory

替换为：你的测试命令，从正确的目录执行

<your test command> ```
Expected: all tests pass.
<your test command> ```
预期结果： 所有测试通过。

2. Type check

2. 类型检查

bash
undefined
bash
undefined

REPLACE: e.g. mypy, tsc --noEmit, go vet

替换为：例如 mypy、tsc --noEmit、go vet

<your type-check command> ```
Expected: no type errors.
<your type-check command> ```
预期结果： 无类型错误。

3. Lint / format check

3. 代码扫描/格式检查

bash
undefined
bash
undefined

REPLACE: e.g. ruff check, biome check, eslint

替换为：例如 ruff check、biome check、eslint

<your lint command> ```
Expected: clean.
<your lint command> ```
预期结果： 检查通过。

4. Repeat per surface

4. 针对各技术层面重复执行

A full-stack project has more than one of each. Add a section per surface — backend tests, backend types, backend lint, frontend tests, frontend types, frontend lint — so a single command covers the whole repo.
全栈项目通常包含多组上述检查。为每个技术层面添加一个章节——后端测试、后端类型检查、后端代码扫描、前端测试、前端类型检查、前端代码扫描——这样一条命令即可覆盖整个仓库。

5. Optional — live smoke test

5. 可选——实时冒烟测试

Only when the change touches routing, middleware, or startup; skip it when your test suite already exercises the app in-process.
bash
undefined
仅当修改涉及路由、中间件或启动逻辑时执行；如果你的测试套件已在进程内测试应用，则可跳过此步骤。
bash
undefined

REPLACE: start your app, hit one endpoint, confirm the status code, stop it

替换为：启动应用、访问一个端点、确认状态码、停止应用

<your run command> ```
Prefer starting the server in a second shell over backgrounding and killing it from inside this skill — the background-and-kill idiom is not portable.
<your run command> ```
建议在第二个 shell 中启动服务器，而非在此 Skill 内后台启动再杀死——后台启动再杀死的方式不具备可移植性。

6. Summary report

6. 汇总报告

Report each check with a ✅ or ❌, then an overall verdict:
  • One line per check
  • Overall: PASS or FAIL
For every ❌, include the failing command and the relevant output. Do not fix anything here — this skill reports; fixing is a separate step.
为每项检查标记 ✅ 或 ❌，然后给出整体结论：
  • 每项检查占一行
  • 整体结果：PASS 或 FAIL
对于每个 ❌，需包含失败的命令及相关输出。请勿在此处修复问题——本 Skill 仅负责报告；修复是单独的步骤。

Notes

注意事项

  • Keep this skill fast. It runs before every commit; if a step gets slow, that is a signal to fix the slow step, not to drop it from the checker.
  • A checker that cannot fail is worthless. Once your commands are wired in, break something on purpose and confirm this skill reports ❌.
  • 保持本 Skill 执行速度快。它会在每次提交前运行；如果某一步骤变慢，这表明需要优化该步骤，而非将其从检查工具中移除。
  • 无法失败的检查工具毫无价值。在配置好命令后，故意破坏一些内容并确认本 Skill 会输出 ❌。