본문으로 건너뛰기
cccskills
무료GitHub에 공개

verify-before-done

Evidence rules for completion claims. Use before ticking an acceptance criterion, ending an implementation run, or writing anything that says something works, passes or is fixed.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

설치 방법 보기

포함된 파일(1)

  • SKILL.md3.3 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

Verification Before Completion

Overview

Claiming work is complete without verification is dishonesty, not efficiency.

Core principle: Evidence before claims, always.

The Iron Law

NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE

If you haven't run the verification command in THIS run, you cannot claim it passes. A previous run, "should pass", or "looks correct" is not evidence.

The Gate Function

Before claiming any status or moving any task forward:

  1. IDENTIFY — what command proves this claim?
  2. RUN — execute the full command, fresh and complete.
  3. READ — the full output: exit code, failure count, warnings.
  4. VERIFY — does the output actually confirm the claim? If no: state the real status with evidence.
  5. ONLY THEN — make the claim, with the evidence.

Skipping any step is lying, not verifying.

What Each Claim Requires

ClaimRequiresNot sufficient
Checks passThe component's list_component_checks commands, run in this run, exit 0 — the hand-off gate runs exactly theseA different command you picked yourself
Build succeedsBuild command: exit 0Linter passing, logs look fine
Bug fixedRe-run the original symptom: passesCode changed, assumed fixed
Regression test guards the fixRevert the fix, run the test (MUST FAIL), restore, run again (passes)The test passing once, with the fix already in place
Endpoint works (backend)curl against the running service: status code and bodyCode review of the handler
Screen works (frontend)browser_read_dom with contains: for the element, plus screenshots at the four widthsA build that compiled
Screen works (mobile)mobile_screenshot / mobile_read_ui, or the Flutter web-render fallback when no device is attached"The widget should render"
AC metLine-by-line check of every acceptance criterion against what you just verifiedTests passing

Tests passing is NOT the same as requirements met — re-read every acceptance criterion and confirm each one is actually satisfied.

Handoff

Then close as your prompt says: final message, no comment, no move.

If you cannot show fresh passing output, the task is not done — say what actually failed instead. And do not re-run a check you already have fresh output for: once a build has passed on the code as it stands, running it again proves nothing and costs the run.

Red Flags — STOP

  • Using "should", "probably", "seems to"
  • Expressing satisfaction before verification ("Done!", "Perfect!")
  • Finishing a run without having run the checks in it
  • Relying on partial verification ("the linter passed")
  • Running the same check twice over unchanged code — that is not rigor, it is a loop

Rationalization Prevention

ExcuseReality
"Should work now"RUN the verification.
"I'm confident"Confidence is not evidence.
"Just this once"No exceptions.
"Partial check is enough"Partial proves nothing.
"I'm tired / it's late in the task"Exhaustion is not an excuse.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

makifbaysal/tasktrooper1172026년 10월 21일 업데이트

Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

makifbaysal/tasktrooper1172026년 10월 21일 업데이트

Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

makifbaysal/tasktrooper1172026년 10월 21일 업데이트

Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

makifbaysal/tasktrooper1172026년 10월 21일 업데이트

How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

makifbaysal/tasktrooper1172026년 10월 21일 업데이트

Use when the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

makifbaysal/tasktrooper1172026년 10월 21일 업데이트

makifbaysal의 스킬 모두 보기

이 스킬의 문제 신고