Hire an AI interface finishing reviewer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A short design contract for each screen, with what is seen first, the main action and the forbidden defaults
• A HOLD or PASS call for desktop and for phone, or NOT RATED if you did not show enough
• Findings with the evidence and the reason each one breaks the contract
• A required change for each finding, and the state or screen width to check it at
• A list of choices that already work, so nobody rewrites them
• PASS criteria for the next review

How it does the job well

• Start from the user's task and the content, then the layout. Decoration comes last.
• Design every state: empty, loading, error, long text and mobile.
• Keep one visual system. Reuse spacing, type and colour tokens instead of one-off values.
• Check text contrast (at least 4.5:1 for body text) and keyboard focus as you go.

Mistakes it avoids

• Words like "clean", "premium" or "modern" with nothing visible behind them.
• Copying a reference product whole.
• Rejecting a screen only because it is simple.
• Claiming to run on a timer or to watch the user's releases.
• Designing only the happy path at desktop width.
• Copying a reference's logo, text or claims instead of learning from its structure.

What a good result looks like

An example, not your task: A screen is built and about to go live, and someone should ask hard questions first.

• Design contract. Who uses the screen, what is seen first, the main action, density and forbidden defaults.
• Decision. PASS or HOLD for desktop and for phone, or NOT RATED if not enough was shown.
• Evidence. Each issue seen on the screen and why it breaks the contract.
• Required before PASS. Numbered changes, each with the state or screen width to check it at.
• Keep list. Choices that already work and should not be rewritten.
• PASS criteria. What must be true for the screen to pass the next review.

How the work is checked

• Every finding names what is visible and why it breaks the contract.
• Every required change has a state or width to verify.
• The decision is PASS, HOLD or NOT RATED, never a vague list.
• You rated only what you could see.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

A second opinion

Before it hands back, your AI reviews the draft the way David Carson would. This is a way of reviewing the work. It does not mean they wrote or endorse it.

Capabilities

• Set the product lens. It asks who uses the screen, what they must understand first and what repeats daily. Gaps are marked as assumptions.
• Gather comparable evidence. It notes three to five patterns from similar products, and what each teaches. It copies no design.
• Write the design contract. It fixes the first-read object, the main action, the density and the defaults you must avoid.
• Review the real screens. It checks legibility, hierarchy, pattern fit, states, phone layout and how well parts match the rest of the product.
• Return the finish gate. It gives a HOLD or PASS, the required changes with a check for each, and the criteria for a PASS.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id design-ui-finish-gate-reviewer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/design-ui-finish-gate-reviewer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• Screenshots of the built screens at desktop and phone width, or live links
• Who uses each screen and the one thing they come to do
• Brand, framework or design rules you must keep (optional)
• Screens in their loading, empty and error states (optional)
• Products you admire, or want to look different from (optional)

Helpful context (optional)

• Screenshots of the same screen before and after your last change.
• Your design rules file or style guide.
• Two or three real user quotes about the screen.

Tools and access

• Claude, ChatGPT or Gemini with image upload: It needs to see the real screens, at desktop and phone width.

Functions and deliverables

• Interface finishing reviewer: Get a clear PASS or HOLD on a built screen before release, with the generic UI patterns found and the exact fixes to check.
  • A short design contract for each screen, with what is seen first, the main action and the forbidden defaults
  • A HOLD or PASS call for desktop and for phone, or NOT RATED if you did not show enough
  • Findings with the evidence and the reason each one breaks the contract
  • A required change for each finding, and the state or screen width to check it at
  • A list of choices that already work, so nobody rewrites them
  • PASS criteria for the next review
  Source: Michael Sitarzewski and Agency Agents contributors.
• Interface interaction details designer: Find what is missing in the small moments of your screen, like a toggle or loading state. Get a score out of ten and a ranked list of fixes.
  • Trigger, rules, feedback and loop notes for each moment
  • A score out of ten against eight checks
  • A short list of fixes in priority order
  • Ideas for motion and feedback
  Source: Wondel.ai.
• Interface microcopy writer: Write clear button labels, error messages, empty states and toasts for your app. Give it a screen and get friendly, polite interface microcopy.
  • Button labels
  • Error messages that help
  • Empty state text
  • Toast messages
  • A consistent term list
  Source: sickn33.
• Screen states designer: Find the empty, loading, error and offline states your screen is missing, then build each one. Use it as a screen states checklist and builder.
  • A list of states that can happen on that screen
  • Copy and layout for each state
  • Error messages with a clear next step
  • Built versions in your code
  Source: sickn33.
• Brand profile builder: Share your website. Get a reusable profile covering your products, customers, voice and approved claims, with sources.
  • A folder of eight plain files, from a start file for your AI to a claims list and a change log
  • A tag on every fact, and every claim marked approved, pending or banned
  • A two-sentence diagnosis of your biggest gap, and a list of what's missing and who can answer it
  • A short slice for your next step, if you name one
• David Carson: Review a layout or stale template using David Carson’s recorded approach. Start with the audience and message, then test whether the experiment communicates.
  • Your problem worked on the way David Carson would: their questions, their method, their push-back
  • The answer or the work, in David Carson's voice, using their ideas by name
  • Anything that goes beyond their public record, marked
  • One suggested next step

Tasks you can use it for

• A screen is built and about to go live, and someone should ask hard questions first.
• The screen works but feels like "any SaaS", or looks AI-made.
• You need a clear go or no-go before a release or a demo.
• The phone version only stacks the desktop layout, and you suspect it hides the main job.

Limits to check before starting

• You want a 0 to 100 score for how AI-made your UI code looks. Use the UI design consistency reviewer.
• You want every new screen reviewed with several checks each time. Use the Screen usability reviewer.
• You want a new design, not a review. Use the UI Designer agent.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Add the pack to your AI as a skill. If you cannot, start a new chat and paste SKILL.md, then references/source-agent.md.
• Attach screenshots at desktop and phone width. Say who uses the screen and what they come to do.
• Say what must stay, such as your brand, framework or existing parts.
• Read the design contract first. Correct any wrong guess about the user or the main action before you read the findings.
• Fix everything under "Required before PASS". Run it again with new screenshots to get the PASS call.
• Keep the "Keep" list. It names the choices that already serve your product.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/design-ui-finish-gate-reviewer for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.