task-verifier

Independently verifies task, PR, and Done claims against current evidence.

1|Updated Sep 15, 2026
One-click install
npx skills add https://github.com/amoai-tech/mdeai --skill task-verifier-amoai-tech
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: task-verifier
Source: https://github.com/amoai-tech/mdeai/tree/main/.claude/skills/task-verifier
Command: npx skills add https://github.com/amoai-tech/mdeai --skill task-verifier-amoai-tech

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? Teams often mark tasks, PRs, or Linear issues as Done based on status fields, stale CI runs, or reviewer prose rather than current evidence. This Skill adversarially challenges those claims, requiring cited proof from code, tests, runtime state, and live task trackers before accepting any completion verdict. ## Core Features & Use Cases - Three verification modes: Quick gate for narrow checks, Standard for normal feature/PR review, and Adversarial mode that auto-escalates for auth/RLS/tenant, HITL, migrations, payments, and production-risk changes. - Evidence-tier protocol: Ranks runtime state, exact-head code, tests/CI, Linear, and docs by authority, resolves conflicts to the higher tier, and requires file/line or command citations for every verdict. - False-green and failure-mode analysis: Builds failure-mode matrices, detects tests that could pass while the real outcome fails, and enforces Mastra/Supabase proof non-substitution rules. - Use Case: Before merging a PR that claims a Supabase RLS fix is Done, run an Adversarial verification to cross-check the diff against live Linear acceptance criteria, replay the migration, and prove cross-tenant denial with cited evidence. ## Quick Start Ask the agent to independently verify whether a specific task or PR is truly Done, requiring cited evidence for every acceptance criterion.

Frequently Asked Questions about task-verifier

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify a PR is actually ready to merge?

Run a Standard verification: record the exact head SHA, map every Linear acceptance criterion to cited evidence, build a failure-mode matrix, and check for false-green scenarios where tests pass but the outcome fails. Escalate to Adversarial mode for auth, migration, or payment changes.

What is the difference between Quick, Standard, and Adversarial verification modes?

Quick uses 1-3 decisive probes for narrow docs or small-fix checks. Standard covers task validity, AC mapping, failure modes, and domain checks for normal reviews. Adversarial adds hostile, negative, recovery, rollback, and supply-chain proof for security-sensitive or production-risk work.

Should I trust code review bot findings like CodeRabbit?

Treat bot findings as hypotheses, not facts. Re-fetch the named files at the PR's current head, confirm the finding still applies, and cross-check higher-tier evidence before acting. Dismiss incorrect findings as NOISE with a citation and log them for calibration.

When does a task count as Done?

Done requires the observable outcome, risk-matched adversarial evidence, and applicable post-merge proof. Code existing, tests passing, or a PR being merged are each insufficient on their own, and any unresolved BLOCKER overrides the score.

Why can a tool unit test not prove Mastra agent routing works?

A direct tool test bypasses natural-language model routing, so it cannot prove the agent selects the correct tool in production. The skill enforces non-substitution rules: routing, authorization, persistence, restart recall, and abort behavior each require independent proof classes.