Przejdź do treści
Biblioteka skilli
AI i agenci · Przegląd i audyt

checkyourself

/checkyourself

Weryfikuje twierdzenia o ukończonej pracy, takie jak „gotowe”, „testy przechodzą” i „działa”: wyprowadza każde od nowa z pracy i zgłasza CONFIRMED, REFUTED lub UNVERIFIABLE z dowodami.

Repozytorium
checkyourself ↗
Licencja
Apache-2.0
Ostatnia zmiana repozytorium
26.10.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
3
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 26.10.2026, bez odwołań do wycofanych modeli i API.

Licencja

Apache-2.0, otwarta: można używać i zmieniać, z zachowaniem licencji i informacji o zmianach.

Co robi i kiedy

Weryfikuje twierdzenia o ukończonej pracy, takie jak „gotowe”, „testy przechodzą” i „działa”: wyprowadza każde od nowa z pracy i zgłasza CONFIRMED, REFUTED lub UNVERIFIABLE z dowodami.

Wyzwalacze z opisu

donetests passit worksready to launch
Oryginalny opis (EN)

Use when completed work makes claims — "done", "tests pass", "it works", "ready to launch" — that must be verified before they are believed. Re-derive each claim from the work itself and report CONFIRMED / REFUTED / UNVERIFIABLE with evidence. Fast claim-verification by default; the deterministic production-readiness CLI when launch stakes justify it.

Jak działa

  1. Protocol (both lanes)
  2. Fast lane (minutes)
  3. Deep lane (launch / production readiness)
  4. Example prompts
Sekcje z nagłówków SKILL.md, w oryginale · 112 linii, 850 słów
Podgląd SKILL.md
---
name: checkyourself
description: >-
  Use when completed work makes claims — "done", "tests pass", "it works", "ready
  to launch" — that must be verified before they are believed. Re-derive each claim
  from the work itself and report CONFIRMED / REFUTED / UNVERIFIABLE with evidence.
  Fast claim-verification by default; the deterministic production-readiness CLI
  when launch stakes justify it.
---

# CheckYourself

The job: independently re-derive the claims completed work makes about itself and
report each as CONFIRMED, REFUTED, or UNVERIFIABLE with evidence — so "done" means
proven, not asserted. Never grade your own homework from memory: the author's
summary is a claim to check, never evidence for itself. When the verifier is the
same agent that did the work, say so and discount accordingly — use a fresh context
or a second agent for launch-critical claims.

## Protocol (both lanes)

1. **Extract the claims.** From the completion report, commit message, diff, README,
   doc, or the request. Make implicit claims explicit — "done" implies "it runs";
   "shipped" implies "reachable at its destination"; "13 works, every one live"
   implies each URL resolves.
2. **Re-derive each claim from the work, in the consumer's frame.** Run the command,
   open the page, read the file as shipped. Prefer the path a consumer would hit
   over the path the author would show you.
3. **Label with evidence:**
   - **CONFIRMED** — what you ran and saw: command + output line, URL + selector +
     observation, file:line quote.
   - **REFUTED** — the evidence plus what is actually true.
   - **UNVERIFIABLE** — what is missing to check it (access, tool, time,
     credentials). Never silently dropped, never guessed.
   - `n/a` only when the claim's subject genuinely does not exist in this work,
     with the reason. "Not tested" is not a label.
4. **Report verdict-first.** One line answering "is the claim of completion true?",
   then X confirmed / Y refuted / Z unverifiable, then the per-claim evidence list.
   Plain-English risk before technical detail. If a launch-critical claim is
   REFUTED, say the work is not done in those words.
5. **Stay read-only.** No edits, dependency installs, secret rotation, or
   production changes without an explicitly approved named fix. After an approved
   fix: smallest reversible change, re-derive the affected claims, update status,
   rescore if evidence changed. Accepted or deferred findings stay visible as
   residual risk with owner and trigger.
6. **Safety.** No secrets, customer data, or unredacted `.env` values in output.
   For regulated, financial, health, legal, life-safety, security-critical, or
   high-volume systems, recommend qualified expert review.

## Fast lane (minutes)

Claims → re-derive → verdict list. Examples: "tests pass" (run the suite; quote the
summary line), "all links live" (fetch each; list statuses), "this doc matches the
repo" (read the file as shipped at this revision), "the page says N items" (count
them in the rendered DOM, not the source string). Label what cannot be checked in
this harness UNVERIFIABLE with the reason — a scoped honest verdict beats a fake
complete one.

## Deep lane (launch / production readiness)

When the question is "may this go to production", coverage must be swept, not
sampled. Use the CheckYourself CLI (stdlib-only, read-only, no network, no
telemetry):

```
CY=~/workspaces/checkyourself/tools/checkyourself.py
python3 $CY describe --format json
python3 $CY scan <path> --deep --format json --no-write
python3 $CY coverage --emit            # fill with evidence, then:
python3 $CY score --findings scan.json --coverage coverage.json --format json
python3 $CY backlog --findings scan.json --format json
python3 $CY next    --findings scan.json --format json
python3 $CY diff --old baseline.json --new current.json --ci   # regression gate
```

If the CLI is missing (repo moved), sweep manually, reuse the registry IDs below,
and label every score hand-computed. The score is always the CLI's — never invent
or hand-wave a number: `min(base, cap)` with caps 49 (unresolved P0), 74 (unresolved
P1), 84 (missing critical evidence), 90 (missing launch-gate evidence). **No
findings is Unknown, never automatic Pass.**

Sweep the surfaces that matter to this artifact: purpose, frontend UX/accessibility,
backend/API, auth, data/migrations, secrets/config, tests, CI/CD, dependencies,
deploy/rollback, observability, performance, privacy, compliance, and AI/RAG/agent
governance when relevant. Every claim needs Pass-with-evidence / Finding /
Unknown / Not-applicable-with-reason.

Manual fallback registry — stable IDs for citation, suppression, and diff; never
invent or renumber:

| Rule ID | Condition (canonical) |
|---|---|
| `CY-MANUAL-AUTH-001` | Auth, permission, session, or admin behavior lacks verified server-side evidence. |
| `CY-MANUAL-DATA-001` | Data storage, recovery, retention, or tenant isolation lacks verified evidence. |
| `CY-MANUAL-PRIVACY-001` | Privacy, consent, deletion, or third-party data handling lacks verified evidence. |
| `CY-MANUAL-TEST-001` | A dangerous or launch-critical path lacks a focused test receipt. |
| `CY-MANUAL-RELEASE-001` | Deployment, rollback, CI/CD, or supply-chain behavior lacks a verified receipt. |
| `CY-MANUAL-OBS-001` | Observability, alerting, or incident response lacks a verified receipt. |
| `CY-MANUAL-AI-001` | AI/RAG/agent permissions, evaluation, or refusal behavior lacks verified evidence. |
| `CY-MANUAL-OTHER-001` | A material gap matching no other registered condition. |

Every finding carries: rule/detector ID, severity, exact dated evidence,
plain-English risk, and status. When a shipped detector matches, reuse its detector
ID from the project's canonical registry instead of a manual one.

## Example prompts

```text
Use $checkyourself to verify the claims in this completion report. Read-only;
label each CONFIRMED / REFUTED / UNVERIFIABLE with evidence.
```

```text
Use $checkyourself to run the production-readiness scan and score on this app
before launch, list every blocking unknown, and propose the safest first fix
batch. Do not change code.
```

`dashboard inline` after a report adds a compact Markdown dashboard; there is no
dashboard by default.
Pliki w paczce (3)
  • SKILL.md 6 KB
  • SKILL.md.bak-pre-fpr-20260919 7 KB
  • agents/openai.yaml 1 KB

Wersje

W bazie nie ma innych skilli o nazwie checkyourself.

Migawka bazy z 28.10.2026 · wersja paczki ca3c3fcf8aca (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100shadow-verify
    Uruchamia równoległą falę weryfikatorów, którzy niezależnie sprawdzają kluczowe twierdzenia po audytach i raportach podagentów.
  • 100verify
    Testuje twierdzenie o działaniu jak badacz i zwraca wynik: potwierdzone, obalone albo niejednoznaczne, z dowodami z poleceń.
  • 100completion-gate
    Weryfikuje twierdzenia agenta względem śladu dowodowego, wychwytując „gotowe” bez dowodu, „testy przechodzą” bez wyniku i „naprawione” bez weryfikacji.
  • 100sweep-verification
    Sprawdza dowody przed każdym stwierdzeniem, że zadanie jest gotowe albo działa, bo niepotwierdzone twierdzenia nie mają wartości.
  • 100claim-check
    Sprawdza twierdzenia agenta kodującego, że testy przechodzą lub build jest czysty, z zapisami jego sesji: czy odpowiednie uruchomienie miało miejsce, czy przeszło i czy kod zmieniono potem.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.