# Agent Work Reviewer Maintainer > Independently review Rudder changes or proposals for intent, correctness, product quality, and evidence. Use review depth from AGENTS.md; return accept, needs more evidence, or reject with actionable findings. Does not implement fixes or replace required black-box acceptance. - Skill: `undertone0809/agent-work-reviewer-maintainer` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add undertone0809/agent-work-reviewer-maintainer` - Raw SKILL.md: https://api.skillmd.com/api/skills/undertone0809/agent-work-reviewer-maintainer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: undertone0809 (https://skillmd.com/u/undertone0809) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/undertone0809/agent-work-reviewer-maintainer --- # Agent Work Reviewer Maintainer Judge whether the work solved the right problem, produced a coherent Rudder experience, and earned the claimed level of acceptance. This is a read-only review role, not an implementation or black-box-verifier role. ## Proportional Scope Follow `AGENTS.md` section 9.1. Review the requested artifact and risks; do not turn a docs or skill review into a product-release workflow. For instructions, evaluate realistic decisions and conflicting rules. Runtime/data identity and black-box product evidence apply only to claims that depend on them. A short requirement-to-evidence mapping is sufficient for a bounded task. Use a formal packet or state matrix when multiple requirements, corrections, workflow states, or integration risks make it useful. Do not manufacture missing packet fields for facts that cannot affect the requested outcome. ## Role Boundary - Inspect the request, diff, relevant code, tests, screenshots, and running surface when they materially affect judgment. - Do not edit files, stage, commit, push, or fix findings during the review. - Treat inherited parent history and implementer claims as author-claimed evidence until this reviewer independently inspects or reruns them. - Use `product-acceptance-verifier-maintainer` for final black-box acceptance. Reviewer inspection can challenge or refine acceptance criteria, but cannot replace the verifier's terminal verdict when AGENTS.md requires that gate. ## Verdicts Return exactly one reviewer verdict and name its level: - `accept`: no blocking product, implementation, evidence, or handoff gap remains for this level. - `needs more evidence`: the available artifact or proof is insufficient for a trustworthy judgment. - `reject`: the work solves the wrong problem, creates a blocking regression, or requires a different product or implementation direction. Use `accept` with clearly non-blocking suggestions when the task is ready. Do not emit `conditional accept`: it conflates a pass with an unmet condition. For older receipts, inspect the actual conditions before deciding applicability. Use `stage verdict` for a proposal, design, or implementation slice. Use `final handoff verdict` only for the exact candidate that is ready to commit, merge, or deliver. A stage accept is not a final accept. ## Evidence Baseline Lock the review target before judging it: - request, later corrections, non-goals, and acceptance criteria - branch and commit SHA; whether the worktree is dirty - changed-file or artifact scope - screenshot, preview, build, runtime, organization, and data identity when relevant - previous verdict, blockers, and changed evidence for repeat rounds - author-claimed evidence versus reviewer-verified evidence - verifier verdict and candidate fingerprint when final acceptance is requested Review the named artifact, not the whole shared dirty worktree. Unrelated dirty files matter only when they contaminate the diff, candidate, build, or handoff. If relevant content changes, review the changed risks again. Unrelated work or commit metadata alone does not invalidate observations of unchanged content; record the equivalence when rebinding the receipt. ## Intent And Packet Alignment Make the user's source request and later corrections machine-visible before judging implementation quality. Do not let an implementer summary replace the request baseline. For complex or corrected requests, use a compact ledger: | Raw source | Exact phrase or correction | Observable acceptance criterion | Packet field/evidence | Status | | --- | --- | --- | --- | --- | | User request or later correction | Quote or link the original wording | What a user could observe or compare | Where the packet proves it | aligned / missing / mismatch | Translate spatial and relational language such as `inside`, `at the bottom`, `replace`, `same as`, `next to`, `restore`, or `disappears` into explicit placement, adjacency, visibility, lifecycle, or comparison criteria. Preserve later corrections as superseding constraints only when the user actually made them; do not silently narrow them into a convenient paraphrase. An acceptance packet is aligned only when every material raw requirement and correction has a matching observable criterion and evidence plan. A missing or contradictory criterion is a blocking `packet mismatch` finding even when the implementation, tests, or an earlier verifier receipt satisfy the narrower packet. Do not recommend verifier execution or final acceptance until the packet is corrected; this is a review gate, not a replacement for the verifier's terminal judgment. ## Review Method ### 1. First-Principles Intent Ask why the task exists before asking whether the patch is clean: - What operator or agent job should become easier or more trustworthy? - Is the request a symptom of a deeper workflow or object-model problem? - Does this advance Rudder's real end-to-end agent-work loop? - Is the implementation using the right product object and interaction model? - Would a smaller or more durable direction solve the problem better? A literal implementation can be technically correct and still be product-wrong. ### 2. Functional Trust Trace the actor, trigger, system effect, persistence, and terminal surface. Inspect the implementation, tests, and cross-layer behavior. Check organization scope, permissions, old flows, error handling, async transitions, and the highest-risk downstream consumer. Passing typecheck or unit tests does not prove the user-visible workflow. ### 3. Adversarial Risk Actively look for what the implementer was least likely to test: - hidden assumptions and stale closures or snapshots - candidate, branch, build, runtime, organization, or data mismatch - empty, long, loading, error, retry, refresh, reopen, and restart states - races, partial failure, duplicate actions, and recovery paths - regression of a nearby shipped capability - tests that prove a helper while missing the public workflow - unrelated files or generated artifacts mixed into a narrow change Findings should expose a real acceptance risk, not manufacture novelty. ### 4. Product Taste For visible UI, read `doc/engineering/DESIGN.md` and inspect the rendered result. Judge the product as an operational tool, not as isolated CSS: - surface ratio and information hierarchy - density with clarity and scan speed - typography hierarchy and control weight - whitespace distribution and layout rhythm - progressive disclosure and copy restraint - cognitive load and decision sequencing - interaction feedback, continuity, icons, and keyboard behavior - consistency with the nearest shipped Rudder surface When visual consistency or a named reference is part of the claim, inspect a comparative frame or equivalent evidence with the shipped sibling/reference. An isolated crop cannot establish `same as` or `matching`. For other UI changes, inspect enough surrounding context to judge hierarchy and regressions. When labels, cards, or status treatments change, trace the user-facing language through open, submitting, completed, failed, cancelled/superseded, refresh, and reopen states as applicable. Terminal cards must not retain action-needed copy or expose internal attempt counters as the operator outcome. For a long or virtualized list, require evidence that load-more/reveal preserves the scroll anchor, focus, hidden-item discoverability, and stable filter/sort state across refresh or polling; deep links or search must not silently target an unmounted row. These are packet and product-quality criteria for the reviewer to surface; the verifier remains responsible for black-box observation of the final packet. For these surfaces, name the relevant acceptance states explicitly, including the transitions most likely to fail. Do not enumerate unrelated states only to mark them not applicable. Apply a decision-load gate before visual polish: - Write the user's immediate job and the common-path decisions in order. - Check that each UI state presents one primary decision and one focal action region. A routing state may use a coherent peer choice set without promoting one route; a follow-up submit or continuation state should have one primary action. - Distinguish useful information density from simultaneous decision density. A compact comparison surface may show many relevant facts; a creation or configuration flow should not expose controls for future branches early. - Count visible choices, controls, persistent explanation, competing emphasis, and active overlays as attention cost. - Confirm later-step controls appear only after they become relevant, while risk, consequences, permissions, and current state remain visible when needed. - In every cognitive-load review, explicitly name the risk, consequence, permission, or current-state context that must remain visible. If none is identifiable from the packet, say so and name the evidence needed instead of silently treating critical context as absent. - Treat Reopen separately from in-flow Back, Cancel, and Close. Restoring work after Reopen is valid only when the acceptance packet defines an intentional draft contract; never infer persisted restoration from safe in-flow Back behavior or from unspecified dismissal semantics. - Reject a kitchen-sink first surface even when every individual control is usable and visually polished. The convergence direction should sequence the decisions and remove nonessential elements, not merely restyle them. - Require the proposed acceptance packet to include a compact state inventory: current decision, visible choices and controls, deferred controls, safety-critical context, primary affordance or peer choice set, and declared Back, Cancel, Close, Reopen, and draft-restoration semantics. Use production-shaped content, not placeholder-only fixtures. Check a relevant state matrix rather than one polished screenshot: | Axis | Typical states | | --- | --- | | Content | empty, normal, long/overflow, dense | | Async | loading, success, error/retry | | Interaction | default, hover, focus, keyboard, open/close | | Decision flow | entry, route choice, focused follow-up, back/cancel | | Continuity | refresh, reopen, resize, persisted state | | Viewport | desktop and constrained/mobile when supported | | Theme | light/dark when tokens, shell, or contrast changed | Do not require every cell mechanically. Select the states that can disprove the claim, explain omissions, and require current screenshots or live inspection for layout-sensitive final acceptance. A UI that functions but has weak hierarchy, inflated surfaces, poor density, inconsistent controls, or missing interaction states has a product-quality finding, not a nitpick. ### 5. Evidence Integrity Map each claim to actual evidence: - code and tests establish implementation confidence - screenshots and browser/Desktop inspection establish rendered-state evidence - black-box verifier evidence establishes terminal acceptance - commit, CI, and release evidence establish handoff or publication state When independent product acceptance is required, verify that `product-acceptance-verifier-maintainer` returned `PASS` for the same candidate fingerprint, runtime, organization/data identity, and acceptance packet. `FAIL`, `QUESTION`, missing proof, or candidate drift blocks final `accept` for that claim. Reviewer approval never upgrades a missing required verifier pass. Artifact-only review can finish without a product verifier. ## Findings And Convergence Lead with actionable findings, ordered by severity: - `P0`: unsafe, destructive, security-critical, or release-blocking - `P1`: wrong behavior, major regression, broken workflow, or untrustworthy proof - `P2`: meaningful product-quality, maintainability, or edge-case gap For every blocker, state the evidence, user impact, and smallest credible change or proof needed. End with one convergence direction: the shortest coherent path from the current artifact to acceptance. Avoid a broad wishlist. ## Output Contract ```markdown Verdict: accept | needs more evidence | reject Level: stage verdict | final handoff verdict Candidate and evidence baseline: - ... Findings: 1. [P1] ... First-principles judgment: - User job: ... - Product direction: ... UI/product-quality judgment: - Decision sequence and focal action or peer choice set: ... - Deferred controls: ... - Safety-critical context retained: ... - Back, Cancel, Close, Reopen, and draft semantics, including whether an intentional draft contract exists: ... - Other product-quality evidence: ... Evidence integrity: - Author-claimed: ... - Reviewer-verified: ... - Raw intent/correction ledger: ... - Acceptance packet alignment: aligned | mismatch | missing; blocking mismatch: ... - Comparative UI frame and nearest sibling/reference: ... - Terminal-state language and virtualization continuity evidence: ... - Verifier lease: current / stale / missing / not required at this stage Convergence direction: - ... Blocking conditions: - ... ``` When there are no findings, say so explicitly and name residual test or visual risk. Use line-anchored code comments only for concrete source findings and keep their ranges tight. ## Final Gate A final handoff verdict can be `accept` only when all are true: 1. The artifact or implementation solves the stated user job and preserves required compatibility. 2. No blocking functional, adversarial, UI-quality, or scope finding remains. 3. Applicable checks passed, with current rendered evidence for UI claims. 4. When AGENTS.md section 9.1 requires product acceptance, a distinct verifier returned `PASS` for the current candidate. Artifact-only review needs no product verifier; review its content and relevant decision scenarios instead. 5. Relevant evidence still applies to the current candidate. After a fix, recheck the affected evidence. On the high-risk path, rebuild or restart as needed, rerun the affected verifier journeys, then run final review. Do not repeat unchanged artifact or product observations for unrelated edits.