# Bot Validator

> Validate agent-built or bot-built code, plans, PRs, web app changes, automation, and release candidates. Use when the user invokes /bot-validator, /bv, or asks Codex to audit work produced by an AI agent or coding bot before accepting, merging, shipping, or building on it, including checks for correctness, tests, security, performance, maintainability, browser behavior, CI quality gates, and release readiness.

- Skill: `maybackcompany/bot-validator` (Agent Skill, multi-file: 17 files)
- Install (CLI): `npx skillmds@latest add maybackcompany/bot-validator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maybackcompany/bot-validator/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: MaybackCompany (https://skillmd.com/u/maybackcompany)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/maybackcompany/bot-validator

---


# Bot Validator

## Overview

Use this skill to validate work produced by an AI agent, coding bot, or automated workflow before trusting it. Treat bot output as a candidate change: useful, but untrusted until it has evidence.

Source basis: this skill adapts validation patterns from Addy Osmani's `addyosmani/agent-skills` repository. Load the bundled references only when the validation depth requires them.

## Validation Flow

1. Identify the artifact under review: diff, PR, files, plan, generated app, test output, CI logs, or deployed URL.
2. State assumptions and missing context. If the acceptance criteria are unclear, infer cautiously and label assumptions.
3. Verify intent before implementation details: what was the bot asked to do, and what changed?
4. Review tests first. Confirm relevant tests exist, fail for the right reason when applicable, and pass after the change.
5. Review implementation across correctness, simplicity, architecture, security, and performance.
6. Run or request concrete verification: tests, typecheck, lint, build, browser smoke test, accessibility checks, CI status, or manual reproduction.
7. Separate findings from suggestions. Blocking issues must be actionable and tied to evidence.
8. End with a trust decision: accept, accept with follow-ups, request changes, or reject.

## Validation Matrix

| Dimension | Questions | Evidence |
|---|---|---|
| Intent fit | Does the output solve the actual request without scope creep? | Spec, user prompt, task notes, changed files |
| Correctness | Are edge cases, errors, async state, and data boundaries handled? | Tests, reproduction, code paths |
| Test quality | Do tests cover behavior rather than implementation details? | Test names, assertions, failing/passing output |
| Maintainability | Is the code simple, local, idiomatic, and easy to review? | Diff size, naming, abstractions, duplication |
| Security | Are inputs, auth, secrets, dependencies, and external data handled safely? | File references, threat scenario, audit output |
| Performance | Are hot paths, rendering, queries, bundles, and network calls reasonable? | Measurements, profiling, bundle/build output |
| Browser UX | Does the UI render and behave correctly across key viewports? | Screenshot, Playwright/DevTools result, console logs |
| Release readiness | Are CI, docs, migrations, flags, rollback, and monitoring addressed? | CI status, checklist, deployment notes |

## Reference Selection

Read only the relevant reference files:

- `references/using-agent-skills.md`: broad phase mapping and operating behaviors.
- `references/code-review-and-quality.md`: multi-axis code review and severity handling.
- `references/test-driven-development.md` and `references/testing-patterns.md`: test design and regression validation.
- `references/browser-testing-with-devtools.md`: rendered web app and browser behavior verification.
- `references/security-and-hardening.md` and `references/security-checklist.md`: security review and hardening.
- `references/performance-optimization.md` and `references/performance-checklist.md`: performance review.
- `references/ci-cd-and-automation.md`: CI quality gates and automation review.
- `references/shipping-and-launch.md`: release readiness and rollback checks.
- `references/code-reviewer-agent.md`, `references/test-engineer-agent.md`, `references/security-auditor-agent.md`: role-specific review lenses when a focused persona helps.

## Output Format

Return findings first, ordered by severity:

| Severity | Area | Finding | Evidence | Required Fix |
|---|---|---|---|---|
| Critical/High/Medium/Low/Info | Correctness/Security/etc. | Specific issue | File, line, command, screenshot, or log | Concrete next step |

Then include:

- **Trust decision:** accept, accept with follow-ups, request changes, or reject.
- **Verification run:** commands/checks performed and whether they passed.
- **Residual risk:** what was not checked and why.
- **Suggested follow-ups:** optional improvements that should not block acceptance.

## Standards

- Do not rubber-stamp bot output.
- Do not rely on "looks right" without evidence.
- Do not treat all feedback as blocking. Mark severity clearly.
- Prefer small, targeted fixes over broad rewrites.
- Ask before deleting uncertain dead code or expanding scope.
- If a bot-made change touches auth, payments, privacy, credentials, infrastructure, migrations, or release automation, perform a security and rollback pass.