Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
实测评分 未实测
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Claiming work is complete without verification is dishonesty, not efficiency.
Core principle: Evidence before claims, always.
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.
Before claiming any status or moving any task forward:
Skipping any step is lying, not verifying.
| Claim | Requires | Not sufficient |
|---|---|---|
| Checks pass | The component's list_component_checks commands, run in this run, exit 0 — the hand-off gate runs exactly these | A different command you picked yourself |
| Build succeeds | Build command: exit 0 | Linter passing, logs look fine |
| Bug fixed | Re-run the original symptom: passes | Code changed, assumed fixed |
| Regression test guards the fix | Revert 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 body | Code review of the handler |
| Screen works (frontend) | browser_read_dom with contains: for the element, plus screenshots at the four widths | A 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 met | Line-by-line check of every acceptance criterion against what you just verified | Tests passing |
Tests passing is NOT the same as requirements met — re-read every acceptance criterion and confirm each one is actually satisfied.
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.
| Excuse | Reality |
|---|---|
| "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. |
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
中文简介正在准备中。当前显示原文说明。
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
中文简介正在准备中。当前显示原文说明。
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
中文简介正在准备中。当前显示原文说明。
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
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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
中文简介正在准备中。当前显示原文说明。