Skip to main content

verify-your-own-claims

This skill should be used before reporting findings to a user, writing a PR body or issue comment, posting an audit result, or making any assertion about a codebase, a toolchain, or a system's state — especially a claim that GENERALIZES ("only X and Y do Z", "all of them pass"), asserts a CAUSE ("it fails because…"), asserts a NEGATIVE ("there is no…"), or reports a measurement as clean ("0 found", "all green"). ALWAYS use it when a claim rests on a grep, a search, a script you just wrote, or an API listing. It is the counterpart to [`claim-verification`], which gates a repo's documents with CI; this one covers the assertions you emit into a conversation, a PR body or an issue, where there is no build to fail — so the check has to be a procedure you run, not a gate that runs for you.

インストールへ移動

ソース情報

リポジトリ
pulseengine/pulseengine.eu
ソースの最終更新活動
2026年8月26日 19:06
検出された SKILL.md の言語
英語
スター
0
フォーク
0

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
verify-your-own-claims
description
This skill should be used before reporting findings to a user, writing a PR body or issue comment, posting an audit result, or making any assertion about a codebase, a toolchain, or a system's state — especially a claim that GENERALIZES ("only X and Y do Z", "all of them pass"), asserts a CAUSE ("it fails because…"), asserts a NEGATIVE ("there is no…"), or reports a measurement as clean ("0 found", "all green"). ALWAYS use it when a claim rests on a grep, a search, a script you just wrote, or an API listing. It is the counterpart to [`claim-verification`], which gates a repo's documents with CI; this one covers the assertions you emit into a conversation, a PR body or an issue, where there is no build to fail — so the check has to be a procedure you run, not a gate that runs for you.
metadata
{"author":"pulseengine.eu","version":"0.1.0"}
# Verify your own claims The operating contract already says: ground every progress claim in a tool result. That rule catches the model that reports work it never did. **It does not catch this.** Every failure below *had* a tool result behind it. The claim was grounded — and still wrong, because the claim reached further than the instrument could see. > **The one principle.** A tool result behind a claim is **necessary, not > sufficient.** The claim must not exceed what the instrument can measure. So > before asserting, name the instrument, and name what it is blind to. This is [`oracle-gate-a-change`]'s red-first discipline turned on your own sentences, and it is [`gate-potency`]'s question — *can this check fail?* — asked about the check you just ran on yourself. ## Why this is a real class, not a hypothetical Five instances, one session, same author, all with evidence in hand: | the instrument | the claim | what it could not see | |---|---|---| | `grep 'z3::\|use z3\|Z3_\|z3_sys'` over `.rs` + Cargo deps | *"Only loom and synth link Z3."* | Z3 as a **subprocess** and as a **Bazel toolchain** — so gale, relay and rules_verus, the largest un-certificate-checked Z3 surface in the org, were invisible | | a link checker matching `href="([^"]+)"` | *"0 dead links."* | **Zero links.** The output is minified and emits unquoted `href=/docs/`. Six were dead, four on a nav-linked page | | `gh run list` conclusions | *"cancelled by dependabot storms + cancel-in-progress."* | The **cause**. The concurrency group was per-branch; the durations sitting in the same output showed a 30-minute timeout | | *(no probe ran)* | *"gale: cross-check none."* | Everything. An asserted **negative** with no instrument behind it at all | | `--version` / exit-code conformance | *"these tools are fine"* (so they went unexercised) | **Behaviour.** The two most severe defects of the survey were in tools that passed every convention cleanly | Note what is *not* in that table: a single instance of reporting work that was never done. The contract's rule was satisfied every time. ## The four checks Run these against the claim you are about to make. Each one is named after the instance it would have caught. ### 1. Does the instrument have a zero-case that looks like success? A checker that matched nothing prints the same triumphant `0 problems` as a checker that matched everything and found nothing wrong. **Print the denominator, and fail on zero.** ``` 75 pages, 94 internal links checked, 0 dead <- evidence 0 dead links <- not evidence ``` If a count of *things examined* cannot be produced, the result is not a measurement. This is [`gate-potency`]'s vacuity check applied to a one-off script. ### 2. What shape of the thing would this probe be blind to? Before generalizing from a search, enumerate the forms the target can take, and confirm the pattern covers each. A dependency can arrive as a linked crate, a spawned binary, a build-system toolchain, a vendored source tree, a container image. One grep sees one form. State the scope you actually searched — *"no crate links Z3"* is defensible; *"nothing uses Z3"* is not, from the same grep. ### 3. Is this a cause, or a correlation the data also permits? Reporting *what happened* needs the observation. Reporting **why** needs the alternatives ruled out. Before writing "because", ask what else predicts the same data, and check whether the answer is already in the output you have — it usually is. ### 4. Did I probe every member of the population I am generalizing over? A table with a row per repo asserts a result per repo. If one row was never probed, it does not get a value — it gets **"unprobed"**. An absent instrument never produces a negative finding; it produces no finding. The tell: you are about to write a confident cell for something you have not run a command against. ## Then: separate what you measured from what you concluded In the report itself, keep them visibly apart. The measurement is durable and someone else can re-run it; the conclusion is yours and may be wrong. ``` Measured: 57 cancelled, 3 failure, 0 success across 60 runs (2026-07-15 → 08-25); durations 30.4–102.5 min against timeout-minutes: 30 Concluded: the job cannot finish inside its budget ``` Anyone can falsify the second line without re-deriving the first. That is the property worth having, and it is the same reason a rivet artifact separates the requirement from its verifying evidence. ## Anti-patterns - **Treating "I ran a tool" as the end of the check.** It is the beginning. The contract's rule is the floor, not the ceiling — this skill exists because five claims cleared that floor and were still wrong. - **Conformance as a proxy for correctness.** Passing a convention audit says a tool meets the convention. It says nothing about whether the tool works. Both of the worst defects in one survey were in tools with impeccable `--version`. - **A confident cell for an unprobed row.** Fill it with *unprobed*, or delete the row. Do not let table symmetry manufacture a finding. - **Rewriting the claim smaller after being challenged, without saying so.** If the scope was wrong, correct it plainly once and move on — see the operating contract on corrections. - **Running this on trivia.** It is for load-bearing claims: ones that route work, close an issue, or land in a PR body someone will act on. Not for "the file is at `src/main.rs`." ## Where this composes - [`claim-verification`] — the same species, other target: a repo's *documents*, where a `claims.yaml` sidecar and a CI gate can make drift fail the build. A sentence in a PR body has no build, which is why this one is a procedure. - [`gate-potency`] — check 1 is its vacuity audit, scoped to a script you wrote five minutes ago rather than a standing CI gate. - [`clean-room-verification`] — when a claim survives these four checks and is still consequential, hand it cold to a fresh-context agent. This skill is the cheap pass; that one is the expensive pass. - [`report-tool-friction`] — an instrument that cannot see a whole shape of the thing it searches is often a *tool* gap worth filing, not just a personal slip. - [`pulseengine-operating-contract`] — *"Ground every progress claim in a tool result"* is the always-on floor this skill builds on.
GitHubで見る