Preference Marketing Web

Preference Marketing Web

Apply a bounded preference record to a public page. Route unresolved subjective decisions back to calibration.

Keep three judgments separate

Keep correctness, task fitness, and human preference separate. Never average them into one quality or taste score. A preferred treatment cannot excuse a broken link, inaccessible control, misleading claim, unreadable page, or performance failure.

Confirm the route

Use this skill when the main job is to understand, evaluate, read, trust, or convert on a mostly public page.

Route dashboards, settings, tables, repeated operational workflows, and authenticated product screens to preference-product-ui. Split hybrid products into public and product areas.

Freeze objective requirements

Before comparing any visual treatment, record:

• page type, audience, primary promise, and conversion action;
• exact source revision and runtime;
• representative final content;
• navigation, link, and form behavior;
• semantic hierarchy and discoverability requirements;
• responsive viewports;
• keyboard, contrast, focus, and reduced-motion requirements;
• performance budget.

Do not use placeholder content when it changes hierarchy or wrapping.

Apply or calibrate one axis

Load only a preference rule whose scenario covers marketing or editorial web work.

Use these axes as question prompts, not universal rules:

• composition and visual rhythm;
• typography and hierarchy;
• color and contrast;
• imagery and texture;
• density and whitespace;
• interaction.

For an unresolved axis:

1. Keep the rest of the page and content fixed.
2. Create two to six neutral alternatives.
3. Include enough surrounding context to judge the section in the page.
4. Record desktop and mobile evidence at fixed dimensions.
5. Present the alternatives without revealing the agent's preference.
6. Allow choose, reject-all, and abstain.
7. Record the literal response and route it through preference-calibrate.

Read [references/marketing-web-axes.md](references/marketing-web-axes.md) before designing a comparison.

Validate the implementation

1. Bind evidence to the exact implementation revision.
2. Render representative content at declared desktop and mobile viewports.
3. Check semantic headings, links, forms, keyboard paths, focus, contrast, and reduced motion.
4. Check overflow at 320 px and 200% zoom.
5. Check the visible reading or conversion path.
6. Measure performance against the declared budget.
7. Capture interactive behavior as video or a trace; do not infer motion from a still.
8. Use a new section or component as held-out evidence without retuning the chosen rule.
9. Pass the dossier to preference-verify.

Use [references/marketing-web-evidence.md](references/marketing-web-evidence.md) for the capture matrix.

Stop and refuse

Block preference-led release for:

• broken navigation, links, forms, or conversion actions;
• inaccessible contrast, focus, keyboard behavior, or motion;
• unreadable or overflowing responsive states;
• placeholder content that changes the decision;
• missing exact-revision evidence;
• rules imported from product UI, native mobile, or prose;
• screenshot-only proof for motion or interaction;
• performance regression outside the declared budget.

Refuse to infer the owner's preference from current trends or generic design doctrine. When no compatible record exists, calibrate instead of improvising a house style.

Output

Return:

• exact revision and page contract;
• applied rules with provenance and exclusions;
• objective validation results;
• fixed-viewport captures or interaction evidence;
• the held-out result;
• separate correctness, task-fit, and preference assessments.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Arakiss
• Source: Arakiss/preference-harness
• License: MIT

Install and usage instructions live in the source repository linked above.