How the Reader, Designer, and Developer Roles Work

WTFAA groups its page actions into three roles: Reader, Designer, and Developer. Each role loads its own prompt presets and puts four actions in the toolbar at the top of the side panel, for 12 actions in total.

This guide explains what each action produces, when it is useful, and how to switch roles. If you have not set up WTFAA yet, start with Getting started.

How Actions Work

Actions appear as icons in the toolbar. Hover over an icon to see its name.
When you click an action, WTFAA reads the current tab at that moment. Most actions use the page content; Form Audit and Fill Test Data use the visible form fields instead.
Before anything is sent, the Review before sending dialog shows the context the AI will receive. You can confirm with Send to AI, or tick Skip the next quick-action preview to send the next action without the dialog.
The prompts ask the AI to base its answer on the current page and to label general background or uncertain guesses as such.
You can still type your own question in the input box in any role.

Reader: Understand and Reuse Page Content

Use Reader for articles, documentation, announcements, and other text-heavy pages. A new install starts in this role.

Action	What you get	When to use it
Summarize	Key points (topic, core information, likely audience), a 2–3 paragraph summary, and key takeaways	You want the gist of a long page before reading it in full
Explain This Page	Background context, core concepts with examples, important details, connections to broader topics, practical applications, and follow-up questions	The page assumes knowledge you do not have yet
Extract Keywords	Primary and secondary keywords, named entities (people, organizations, products), and suggested tags	Tagging, research notes, or checking what a page is really about
Turn Into Social Post	A draft X/Twitter thread, a LinkedIn post, a one-liner, and hashtags	Sharing a page; the prompt limits claims to what the page supports, but review the draft before posting

Designer: Review the Visible Interface

Use Designer for landing pages, app screens, and any page where layout and visual quality matter. These actions look at what is visible on the page; they do not judge implementation or backend behavior.

Action	What you get	When to use it
Visual Analysis	Notes on visual hierarchy and focal points, color usage, typography, and spacing and layout	A first structured look at a design
Color & Contrast Notes	A palette table and contrast notes based on colors WTFAA collects locally from the page's computed styles, plus a note on which values were measured and which are visual estimates	Documenting a palette or spotting likely contrast problems
Design Critique	Strengths, specific improvements, visible accessibility concerns, comparison with common UI patterns, and a prioritized fix table	Design reviews and feedback rounds
Visible A11y Review	A checklist of visible accessibility signals (contrast, focus indicators, labels, heading order, keyboard path, image alt text), an issues table by severity, and quick wins	A quick accessibility pass before a full audit

Color & Contrast Notes and Visible A11y Review are heuristic reviews. They are not a WCAG compliance certification.

Developer: Inspect, Test, and Fill Forms

Use Developer for frontend work, QA, and form-heavy pages.

Action	What you get	When to use it
Detect Frontend Stack	Likely frontend framework, styling, and build-tool signals with the visible evidence for each, plus confidence levels and what cannot be determined	Getting oriented on an unfamiliar site
Page QA Checklist	A test case table (ID, preconditions, steps, expected result), visible edge cases, accessibility checks, and observable performance risks	Planning manual testing of a page or flow
Form Audit	A field table (type, label, required, visible validation), dependencies between fields, and potential issues	Reviewing a form's structure and labels
Fill Test Data	Realistic but fake values for the visible form fields, shown for review before anything is filled	Filling test forms quickly during development or QA

Detect Frontend Stack only reports what the page itself exposes. It does not identify backend architecture, databases, hosting, or private APIs.

With Fill Test Data, WTFAA first shows Fields to review before filling with each field and value. Nothing changes on the page until you click One-click Execute, and filling never submits the form. The action asks the AI for visible fields only and tells it to leave out hidden, password, payment, and terms fields, so check the list before you confirm. See Form audit and test data for details.

Switching Roles

Find the role button at the right end of the action toolbar. It shows the current role's icon and a small arrow (tooltip: Switch Role).
Click it and choose Developer, Designer, or Reader.
The toolbar switches to that role's four actions. Your conversation stays in the panel.

Setting a Default Role

Open Settings (gear icon) and stay on the General tab.
Under Default Role, choose the role you want.

The role menu in the toolbar and the Default Role setting change the same saved value, so the panel keeps the role you picked last. If you mostly do one kind of work, set it once here and use the toolbar menu for occasional switches.

Page translation and screenshot analysis are available in every role from the input area.
Privacy and the send preview explains what is sent and how local redaction works.