360 Secure SkillHub
360 安全技能中心

principle-prove-it-works

该 Skill 提供一套任务完成后的验证原则:直接检查真实产物,例如运行功能、读取实际值、查看差异,而不依赖文件时间戳、缓存输出或自述等代理信号;建议把可重复的检查写成脚本,并保留可复核的输出。

分类:效率
jgorgs
热度 0.00
最近更新 2026-10-30 11:15:23

安装

发给 Agent
帮我安装这个技能:npx secure-skills-cli add jgorgs/jstack/principle-prove-it-works
兼容性
通用兼容
联网要求
不联网
数据出网
数据不出本机
Metadata
name
principle-prove-it-works
description
Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'
user-invocable
false

Prove It Works

Verify every task output by checking the real thing directly. Do not infer from proxies, self-reports, or "it compiles."

Why: Unverified work has unknown correctness. Indirect verification (file mtimes, output freshness, agent self-reports, cached screenshots) feels cheaper than direct observation. Acting on a wrong inference costs far more than checking the source.

Check the real thing, not a proxy:

  • Check process liveness directly, not indirectly through derived state
  • Read the actual value, not a cached or derived representation
  • When verification fails, suspect the observation method before suspecting the system
  • Treat verification environment overrides as part of the test surface. If you point tests at a base URL through an environment variable, first probe that exact URL and remember it may bypass the test runner's own server startup.
  • For user-facing features, start from the screen users are likely to come from and reach the feature through visible navigation before checking it via a direct URL; a deep link proves the destination renders, not that users can find it.

Verify the process as well as the outcome. A correct result can rest on a broken process, and a review that checks results passes it: a clause reconstructed from the user's paste instead of the durable record, a constraint honored by chance from a file never read. For each fact you relied on, name the record it came from and confirm that record is the one the project's rules point at.

Red is a colour, not a measurement. A failing check proves the instrument only when the failure content is the disagreement you predicted. An exception, an empty collection against a non-empty literal, and a real mismatch all print red, so quote the assertion's diff (Extra items in the right set), never the assertion (assert {...} == {...}). A convergence probe keys on behavior only the new artifact can produce, never an identity field the old one also emits. A same-SHA restart lets old code report the new commit SHA.

Script the check when you can

The strongest proof is a deterministic script that re-runs the same comparison, not a one-time eyeball. Write the script, run it, and keep its output as an artifact a reviewer can re-run instead of trusting your word.

Keep the artifact visible for the human. Commit it only for large or complex work where the trail has to be auditable later, like a big port or migration (the show-me-your-work skill).