Use when preparing local changes, a branch, pull request, merge request, or merge-to-main for final review before publishing, opening a PR, merging, or claiming readiness.

2026-07-142

test-driven-development

jwilger/ai-plugins

Use when implementing any feature, bugfix, behavior change, or refactor before writing production code.

2026-07-142

advisor

jwilger/ai-plugins

Use when the user asks to shape fuzzy planning, product/design/engineering tradeoffs, scope/spec/ticket plans, or says "challenge this/help me think"; delegate to an advisor subagent. Good for rough ideas, second opinions, load-bearing decisions, or scope cuts. Skip scoped implementation, narrow bugs, reviews, and "just build" requests.

2026-07-132

scaffold-agentic-evals

jwilger/ai-plugins

Use when setting up a project-local eval harness for prompts, agents, judges, RAG, tools, or other LLM behavior, especially when the default should be free/OSS promptfoo with repo-owned artifacts.

2026-07-132

babysit-pr

jwilger/ai-plugins

Use when a pull request or merge request needs to be driven to merge — watching CI, responding to review feedback, and merging once green and approved, across GitHub, Forgejo, or GitLab.

2026-07-132

tiber

jwilger/ai-plugins

Use when the user wants repository task tracking, shared agent task state, cross-worktree coordination, tiber setup/install/scaffold guidance, or task create/list/show/prioritize/validate/close workflows. Plugin install and session start are non-mutating; setup integration starts with dry-run previews.

2026-07-132

name	verification-before-completion
description	Use when claiming work is done, fixed, passing, ready, reviewed, committed, or safe to merge.

Verification Before Completion

Evidence comes before claims. A completion statement is only valid when fresh verification proves the exact scope being claimed.

Gate

State the claim precisely.
Identify the evidence that would prove that claim.
Run the relevant command or inspect the authoritative source now.
Read the full output or current state, including exit code and failures.
Report only what the evidence proves. Name any gaps.

Claim Scope

Claim	Required evidence
"Tests pass"	Fresh full relevant test output with zero failures
"Lint/format is clean"	Fresh lint/format command output
"Bug fixed"	The original symptom or regression test now passes
"Requirement met"	Requirement-by-requirement check against files, output, runtime state, or PR state
"Ready to merge"	Current checks, review state, branch status, and required approvals

Partial checks prove partial claims only. A focused test can prove a narrow fix; it cannot prove the whole repo is green.

Red Flags

"Should pass", "looks good", "probably fixed", or any success wording before running verification.
Reusing a previous run after files changed.
Treating a generated report, agent message, or green subcommand as proof of a broader claim.
Skipping verification because the change is "just docs" or "obvious".

When evidence is missing, say what was checked and what remains unverified.