/agent-native-reviewer

name: agent-native-reviewer
description: Review agent-native parity for skills, prompts, tools, commands, generated mirrors, repo workflows, and user-facing actions.

Agent-Native Reviewer

Review whether an agent can perform, verify, and discover the same meaningful action a user can.

The standard is simple:

user action -> agent route -> source owner -> proof command/artifact -> handoff

If one link is missing, the workflow is not agent-native.

Use When

• `.agents/**`, `.claude/**`, `.codex/**`, skills, prompts, hooks, commands, or

workflow docs changed.

• A feature adds or changes a user-facing action and the repo has agent

integration.

• A reviewer asks whether Codex can reproduce, operate, verify, or maintain the

same surface a human can.

• A repo is becoming mostly agent-maintained and needs fewer hidden human-only

paths.

Do Not Use When

• The task is a normal code review with no agent/tooling/workflow surface.
• The action is intentionally human-only: MFA, OAuth consent, billing payment

entry, CAPTCHA, legal acceptance, biometric unlock, or OS permission prompts.

• The change is cosmetic and has no meaningful operation to reproduce.

Core Principles

1. **Action parity.** Every important user action has an agent route. 2. **Context parity.** Agents can see the inputs, state, and constraints needed to act well. 3. **Source ownership.** Agents edit the durable source, not generated mirrors or copied output. 4. **Proof parity.** Agents can verify the outcome with the same authority a maintainer would trust. 5. **Discoverability.** The route is visible from the skill, AGENTS file, command docs, tool schema, or public API docs an agent is expected to read. 6. **Shared workspace.** Agent-created artifacts live where humans can inspect, edit, and commit them.

Codex Capability Ladder

Assume Codex is the agent runtime unless the repo says otherwise. Prefer the most repeatable proof and interaction layer that can cover the action:

1. **Tests and scripts first.** Unit, integration, browser-test, benchmark, typecheck, lint, import smoke, generated-mirror audit, and source audit are the default proof layer. If a behavior can be proved there, do that before driving an app by hand. 2. **Browser next.** Use the Browser plugin for app/browser interaction proof when tests cannot fully prove rendered behavior, native selection, focus, navigation, screenshots, console/network state, or real route behavior. 3. **Chrome after Browser.** Use Chrome when the task depends on the user's existing Chrome state, profile, tabs, extensions, cookies, or a site state that Browser cannot access. 4. **Computer Use last.** Use Computer Use for OS-level or native-app actions that tests, Browser, and Chrome cannot reach. Treat it as powerful but brittle; record exact manual proof and any limits.

Do not jump straight to UI automation when a focused test, command, or source audit gives stronger evidence. Do not claim a behavior is agent-native unless the selected layer can be rerun or described precisely enough for another agent to repeat.

Dotai Integrations

• Use `autogoal` for durable or measurable work. The first checkpoint must copy

agent-native requirements into the plan before implementation.

• Use `sync-skills` when a skill, rule, template, or generated mirror crosses

repo boundaries. Shared behavior belongs in dotai; repo policy stays local.

• Use `sync-vision` when the missing parity is reusable taste or doctrine, not

just one task's mechanics.

• Use `resolve-pr-feedback` for PR review feedback. Do not nest mandatory

`autoreview`; only recommend it after a complete end-to-end feature when an optional independent second pass could materially help.

• Use `hard-cut` when stale compatibility, fake aliases, dead commands, or

duplicate agent routes should be deleted rather than wrapped.

• Use `tdd` or `diagnosing-bugs` when the parity gap is a real behavior bug,

flaky proof, or unclear failure path.

Review Process

1. Identify the Changed Surface

Classify the action surface:

| Surface | Examples | |---|---| | Skill/workflow | `SKILL.md`, `.mdc`, plan template, generated mirror, lockfile | | Command/tool | CLI command, script, MCP tool, GitHub workflow, package script | | Public API | exported package API, docs example, release artifact | | Product action | button, form, keyboard shortcut, browser route, OS/device path | | Maintainer action | issue triage, PR feedback, security advisory, release lane |

For incremental reviews, start from the changed files and expand only to the source owner, generated mirror, lockfile, command, or docs that prove parity.

2. Build the Parity Map

Use this map for every meaningful action:

| User action | Agent route | Source owner | Mirror/lock/doc | Proof | Status | |---|---|---|---|---|---| | action | skill/tool/command | file/path | generated/config/doc | command/artifact | pass/gap/N/A |

Status rules:

• `pass`: source owner, route, proof, and discoverability are present.
• `gap`: agent cannot safely perform or verify the action.
• `N/A`: intentionally human-only or outside the current repo authority, with a

concrete reason.

3. Check Source Ownership

Flag any workflow that asks agents to edit output instead of source.

Common source boundaries:

| Output | Source owner | |---|---| | `.agents/skills/**/SKILL.md` installed mirror | external skill package or `.agents/rules/**` source | | `.claude/skills/**/SKILL.md` installed mirror | external skill package or `.agents/rules/**` source | | root `AGENTS.md` generated block | `.agents/AGENTS.md` or repo generator input | | generated barrel/export file | package source plus barrel generator command | | generated docs/template output | registry/package/docs source named by repo policy | | copied skill in many repos | dotai source plus Skills CLI install/update |

Finding severity is high when the wrong