From a finding
to a finished piece of work.

CLIENT JOURNEY BRIEF

Client: [business name]
Website: [URL]
Primary action: [request a quote / find a product / check availability]
Relevant pages: [URLs]
Audience and important constraints: [details]

1. Describe the information a visitor needs to complete this action.
2. List the steps, required fields, and expected outcome.
3. Identify which steps can be inspected publicly and which need an authorized test environment.
4. Record the current analytics events or business outcomes the client already measures.
5. Agree what an agent-readiness improvement would look like without assuming revenue uplift.

Deliverable: a one-page journey brief with scope, exclusions, and a named client reviewer.

IMPLEMENTATION SCOPE

Use the attached getAIlisted findings and the client's journey brief.
Only cite evidence included in the audit; label assumptions.

For each proposed improvement, provide:
- Finding and affected URL
- Observed evidence and scan date
- Why it may affect the client's selected action
- Specific implementation change
- Dependencies and effort estimate, with assumptions
- Acceptance criteria and verification method
- Owner and delivery status

Group work into: foundation fixes, journey improvements, and optional experiments.
Keep WebMCP experiments separate from the core readiness score.
Do not promise rankings, recommendations, lead volume, or conversion uplift.

Deliverable: a prioritized scope that the agency can edit and price.

INTERACTION IMPROVEMENT BRIEF

Inspect [page URL / component] for the [client action] journey.
Work from the current application behavior and audit evidence.

1. Give actionable controls descriptive accessible names.
2. Associate visible labels with form fields; communicate required inputs.
3. Use native links, buttons, and form semantics where appropriate.
4. Keep validation errors specific and associated with the affected input.
5. Make loading, success, and failure states understandable.
6. Preserve authorization, existing submission behavior, and keyboard access.

Verify with keyboard navigation and accessible-name inspection.
Exercise success and error paths in the approved test environment.
Do not submit real leads, bookings, or purchases as part of this inspection.

Report the files changed, behavior verified, and remaining gaps.

CONTENT & STRUCTURE BRIEF

Review [URLs] and the attached getAIlisted evidence.

1. Make the service/product identity, audience, features, constraints, and next action clear in visible content.
2. Use semantic headings and meaningful link text.
3. Add relevant Schema.org markup only for information that is accurate and represented on the page.
4. Validate the markup and check important rendered content is available under the tested access conditions.
5. Review sitemap, crawler directives, and machine-readable documentation against the site's intended access policy.
6. If adding llms.txt or AGENTS.md, keep it consistent with the website and existing API documentation.

Do not invent reviews, pricing, availability, or search benefits.
Document any blocked or untested pages.

Deliverable: implementation notes, evidence, and a verification checklist.

WEBMCP OPPORTUNITY BRIEF

Client action: [action]
Page and authorized test environment: [details]

Read the current official WebMCP documentation before implementation:
https://developer.chrome.com/docs/ai/webmcp

1. Decide whether a structured browser tool would help this journey.
2. Define a precise tool name, description, validated input schema, and useful output.
3. Prefer a read-only pilot, such as searching products or reading availability.
4. Feature-detect the supported browser API; preserve the normal website experience.
5. Reuse normal authorization and avoid exposing private data through tool outputs.
6. Record registration evidence separately from an executed scenario's outcome.
7. For consequential actions, define explicit user confirmation and duplicate-request handling before implementation.

Label WebMCP experimental. Record browser/API version, page state, test inputs, expected output, and observed output.

Deliverable: suitability decision, proposed tool contract, and a bounded test plan.

VERIFICATION RECORD

Baseline audit: [ID, date, URL, scope, methodology]
Follow-up audit: [ID, date, URL, scope, methodology]
Implementation reference: [change / release]

For each scoped finding:
- Original observation
- Change implemented and who reported it
- Recheck performed, environment, and date
- New evidence
- Result: resolved / persistent / new issue / inconclusive / not tested
- Remaining work and owner

Compare only equivalent checks and explain scope or methodology differences.
An 'implemented' status is a delivery update. Mark 'verified' only when new evidence supports it.
Keep observed website behavior separate from model interpretation.
Report client analytics outcomes only when supplied with a defined measurement method.

Deliverable: a concise before/after readout and the next recommended actions.