Bare agent or fix loop?

A studio owner wants to see whether this invoice tool can show what clients still owe. Make the opening screen and its next step convincing.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render (original PNG)

Pass 1. Left: plain; right: kit-landing. Raw preference: 7/7 (4 is neutral, higher favors right). B connects “See what’s owed” directly to the $6,550 outstanding balance and highlights $2,800 overdue, making the next step more specific than A’s “View dashboard.” B also shows the complete summary on mobile; A’s larger headline and framed preview provide more breathing room but push key invoice facts below the visible screen.

Pass 2. Left: kit-landing; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A connects “What’s still owed?” to “See what’s owed” and explicitly identifies $2,800 as overdue; B’s “View dashboard” is less specific. B gives the summary a distinct frame, but its taller mobile headline and framing push the invoice breakdown below the visible screen, while A shows all three balances.

Make October billing legible at a glance for the studio owner following up unpaid invoices.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render (original PNG) · Procedure render

Pass 1. Left: plain; right: kit-polish. Raw preference: 5/7 (4 is neutral, higher favors right). B puts Dovetail’s $2,800 overdue invoice first and keeps unpaid rows visible on mobile, making follow-up easier to prioritize. A provides a clearer “Review overdue” action and collection progress, but its mobile layout pushes the invoice list below the summary and alert.

Pass 2. Left: kit-polish; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B groups October totals with collection progress and gives the overdue invoice a specific review action. A keeps overdue and open invoices first in the table, making unpaid follow-up easier to scan, while B uses mobile space on a separate overdue notice above paid-first rows.

Make the billing contact settings ready for a studio owner to edit and recover from a failed save on a phone.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-harden. Raw preference: 6/7 (4 is neutral, higher favors right). B places an explicit retry action inside the failed-save message, visible on mobile; A puts recovery in the desktop footer, outside the mobile view. B also brings the editable fields higher on mobile by removing the General tab and decorative header icon, though A makes the error more prominent by placing it before the fields.

Pass 2. Left: kit-harden; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A places “Try saving again” inside the error beside the preserved billing details, making recovery visible on mobile; B places its retry action in the desktop footer, outside the visible mobile area. B makes the failure prominent above the fields, but its General tab and taller header push editing controls farther down the phone screen.

Prepare the client sign-in screen for release. Review the customer-visible path and address the most consequential presentation defects.

desktop: Plain render · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-ship. Raw preference: 6/7 (4 is neutral, higher favors right). B’s desktop split layout and typographic specimen give the screen a distinct identity, while its mobile form retains clear labels and a prominent sign-in action. A provides more useful account-specific guidance and places the form higher on mobile, but its bordered card feels more generic.

Pass 2. Left: kit-ship; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A’s Atlas Foundry panel gives the desktop a specific studio identity, while B’s centered card feels more interchangeable. A also places email guidance directly beneath the field; B groups the mobile form more compactly but separates that guidance from the input with a large gap and divider.

Audit how a client finds the Atlas proof awaiting review. Give the implementer a precise repair brief.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-audit. Raw preference: 5/7 (4 is neutral, higher favors right). B gives the pending Atlas proof one prominent placement and a clear Review proof button; A duplicates it under All projects, adding scanning work. However, B drops Atlas Foundry from the proof details, weakens Date on record to Date shown, and pushes the mobile action near the viewport bottom. Preserve B’s single placement, restore those facts, and tighten mobile spacing so the action appears sooner.

Pass 2. Left: kit-audit; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A makes the pending task explicit with “1 proof awaiting your review” and gives Atlas a prominent Review proof button; preserve that priority, but replace “Date shown” with a precise date label. B groups pending reviews clearly, but repeats Atlas under All projects and gives its mobile action less emphasis; consolidate the duplicate and strengthen Review proof.

Clarify which proof awaits approval and how its state changes when a client approves it, including a quiet path for reduced motion.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-motion. Raw preference: 6/7 (4 is neutral, higher favors right). B groups Identity direction, Version 02, the approval action and its consequence - marking both proof and project Approved - in one panel. B also keeps that action prominent on mobile, although A shows the proof earlier for inspection; reduced-motion behavior is not visible in either.

Pass 2. Left: kit-motion; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A keeps the version, approval button and explicit Approved outcome together and visible on mobile, though its proof preview falls below the action. B presents the proof and version more clearly, but its mobile approval control falls below the visible screen; neither shows a reduced-motion path.

Refine the contact and notification settings so a client can tell which details will change.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-polish. Raw preference: 6/7 (4 is neutral, higher favors right). B groups contact details, notifications and Save settings in one panel, with an explicit On label that makes the notification setting easier to interpret. A gives the sections clearer visual separation on mobile, but B’s Contact details heading and save guidance clarify what the form changes and when.

Pass 2. Left: kit-polish; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A explicitly says changes apply when saved and labels notifications “On,” making the current state and save action clearer. B groups fields cleanly and fits the notification control more comfortably on mobile, but its generic “Your preferences” heading and less clearly disabled save button weaken task clarity.

Finish a working brew calculator for someone weighing coffee at the counter. Preserve the actual brew recipe.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-fix. Raw preference: 6/7 (4 is neutral, higher favors right). B brings the dose control, prominent 240 g total and pour targets higher on mobile, making the counter task easier to scan. A provides a visible Save recipe action on desktop, but its larger mobile introduction pushes more of the recipe below the screen.

Pass 2. Left: kit-fix; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A puts the dose control and cumulative pour targets higher on mobile, making the recipe easier to consult at the counter. B gives the ratio and water total clearer separation, but its larger introduction and separate dose action push the working recipe farther down.

Help the owner of a newsletter choose the correct print subscription for their next issue. Keep the real prices and cutoffs.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-landing. Raw preference: 6/7 (4 is neutral, higher favors right). B groups the mailing cutoff above each price and selection button, making the choice easier to scan while preserving $18 for up to 100 copies and $42 for up to 500. B also brings the Spine cutoff into view on mobile; A gives the Friday deadline stronger emphasis, but its taller Fold card delays comparison.

Pass 2. Left: kit-landing; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A puts the mailing cutoff directly above each price and action, and explicitly explains the 101–500 range and limit beyond 500. B gives the deadline more prominence, but its taller mobile cards push the second plan farther down and repeat capacity information.

Finish first-run setup for a library volunteer labeling returned crates. Make the first decision easy to act on.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-fix. Raw preference: 5/7 (4 is neutral, higher favors right). B makes the room-to-crate mapping tangible with a prominent W-12 label preview and a direct task heading. A keeps that crate information above Continue setup on mobile, while B places its detailed preview below the action.

Pass 2. Left: kit-fix; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B groups the room selector, crate W-12 and Continue setup action together at both widths; A puts its detailed crate preview below the action on mobile, where it extends beyond the visible screen. A has a more direct task heading and a useful label-like crate preview, while B gives more space to a promotional headline.

Audit the empty inspection inbox. Explain what happened, what to do next, and which screen changes would help.

desktop: Plain render · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-audit. Raw preference: 6/7 (4 is neutral, higher favors right). B groups the empty state with the kiln and shift details, gives Schedule inspection clear priority, and separates Completed into a supporting footer. A makes the shift context easier to scan above the card and offers a wider mobile button, but its adjacent scheduling and completed actions compete more strongly.

Pass 2. Left: kit-audit; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A groups the empty state, East kiln shift and Schedule inspection action together, with concise copy explaining the next step. B makes the shift context easier to scan above the card and gives the mobile action more width, but its repeated empty-state explanation and equally prominent completed-inspections link dilute the primary action.

Prepare the webhook preferences form for an operator who must recover after a failed save without losing their endpoint.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-harden. Raw preference: 5/7 (4 is neutral, higher favors right). B places the save error directly above the endpoint and pairs “Your input is retained” with the retry action, making recovery clearer. A shows the full endpoint on mobile, while B’s larger monospace field clips its ending and makes verification harder.

Pass 2. Left: kit-harden; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A puts the failed-save message directly above the retained endpoint and pairs “Your input is retained” with “Try saving again,” making recovery clear. B shows the full endpoint on mobile, but its extra “Dispatch settings” header pushes the error and retry action farther down.

Review this access-request screen for release and address visual issues that obscure who can issue an invitation.

desktop: Plain render · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-ship. Raw preference: 2/7 (4 is neutral, higher favors right). A places the expired invitation and the project producer’s authority together at the top, making responsibility clear at both widths; B separates that fact from the status with the email field. B’s “Prepare invitation request” more accurately describes the action, but its repeated explanations and “Welcome back” weaken focus and lengthen the mobile screen.

Pass 2. Left: kit-ship; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A highlights that the project producer can reissue the invitation and labels the action “Prepare invitation request,” clearly matching the fact that nothing is sent automatically. B places the producer explanation earlier and offers a more compact layout, but “Request a new invitation” conflicts with its preparation-only helper text.

Finish a dispatch manifest for a dock worker locating the next outbound crate. Preserve every shipment and its destination.

desktop: Plain render (original PNG) · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-fix. Raw preference: 2/7 (4 is neutral, higher favors right). A makes the next crate, Dock B and departure time prominent while keeping all three shipments visible on mobile. B integrates the next departure clearly into its manifest with a distinctive lime highlight, but its tall mobile entries push the third shipment below the visible area and make scanning destinations slower.

Pass 2. Left: kit-fix; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B makes the next crate, Dock B and 09:40 immediately readable in a dedicated departure panel, while retaining all three shipments in a compact mobile table. A’s highlighted manifest row avoids duplicating shipment details and feels operationally specific, but its tall mobile entries push the remaining shipments below the visible screen.

Improve reading and save feedback in a mobile typographic specimen feed. Keep the reading position stable.

desktop: Plain render (original PNG) · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-motion. Raw preference: 6/7 (4 is neutral, higher favors right). B places the specimen name, description, Save specimen control and explicit Not saved status together before the preview, making reading and save feedback easier to scan on mobile. A gives the letterforms more visual prominence and keeps the save label on one line, but its taller cards push the action and subsequent specimens farther down.

Pass 2. Left: kit-motion; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A places Save specimen beside visible Not saved feedback and exposes the second specimen sooner on mobile. B groups each specimen into a polished preview-and-details card, but its taller mobile layout delays browsing and shows no explicit save status; reading-position stability cannot be assessed from stills.

Derive a design system for monthly studio billing. Use its components, amounts and labels as the starting material.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-design-system. Raw preference: 5/7 (4 is neutral, higher favors right). B groups the billing totals into one summary with a clear primary amount, though A’s separate cards give paid and awaiting payment more equal prominence. B also preserves issue dates within mobile invoice details, while A’s more compact rows omit them.

Pass 2. Left: kit-design-system; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A keeps issued dates visible within mobile invoice rows and groups billing totals compactly, preserving useful facts and scan space. B gives payment statuses clearer colored badges and a distinctive total card, but its stacked mobile summaries push activity farther down and omit issued dates.

Derive a design system for a print subscription pricing page. Reuse its plans and quantity limits.

desktop: Plain render (original PNG) · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-design-system. Raw preference: 6/7 (4 is neutral, higher favors right). B’s compact mobile layout keeps both plans, quantity limits and selection buttons visible; A’s oversized cards push Spine’s price and action below the frame. A’s quantity-based introduction and restrained yellow accent feel more specific, while B’s consistent purple buttons give both plans equally clear actions.

Pass 2. Left: kit-design-system; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B’s bold masthead, serif pricing and bordered plan panels give the print subscription page a more specific editorial identity while retaining the prices and quantity limits. A’s compact mobile layout exposes both plans and their choose buttons, whereas B’s larger panels push the second plan’s price and action below the visible area.

Derive a design system for a studio client proof index. Preserve projects, work status and the primary decision.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-design-system. Raw preference: 6/7 (4 is neutral, higher favors right). B keeps project titles, statuses, dates and review actions visible together, and its compact mobile rows preserve that context. A gives the primary review decision stronger emphasis with its dedicated banner, but its oversized mobile layout pushes the project index and supporting facts below the visible screen.

Pass 2. Left: kit-design-system; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A keeps project names, statuses, dates and review actions visible together on desktop and mobile, supporting proof tracking and the next decision. B gives the review action stronger prominence and uses a distinctive palette, but its large mobile header and review panel push the project list and supporting facts below the visible area.

A candlemaker choosing a wax quantity needs a landing page that demonstrates the calculation for a batch of moulds.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-landing. Raw preference: 6/7 (4 is neutral, higher favors right). B keeps the mould input, 250 g result and calculation together on mobile, while A’s result falls below the visible screen. A provides clearer minus/plus controls and separate allowance facts, but B’s compact grouping makes the batch calculation easier to follow at both widths.

Pass 2. Left: kit-landing; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A keeps the 250 g result, the 6 × 40 g calculation and the 10 g allowance visible above the mobile action; B pushes the result below the visible mobile area. B offers clearer minus/plus controls, but A connects the input, calculation and outcome more directly.

A greenhouse operator needs to recover the rejected low-stock threshold without losing the entered value.

desktop: Plain render · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-harden. Raw preference: 2/7 (4 is neutral, higher favors right). A groups Retry save with an explicit Unsaved change status and preserves the entered 12 alongside the saved 8, making recovery clear at both widths. B puts the saved-value reassurance directly in the error, but its longer mobile alert and repeated retention note make the recovery area more cumbersome.

Pass 2. Left: kit-harden; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A’s error message keeps the entered 12 trays, saved 8 trays and retry instruction together, making recovery clearer. B has cleaner spacing and a distinct action footer, but separates the saved-threshold reassurance from the error and retry control.

Finish the recording studio schedule for a coordinator assigning an engineer to the next unstaffed session.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-fix. Raw preference: 6/7 (4 is neutral, higher favors right). B places the engineer field and assignment button directly beneath Braid Quartet, keeping the next action visible on mobile while A pushes its staffing form below the visible area. A gives both sessions a more compact overview and clearly marks the next unstaffed session, but B connects the assignment controls more directly to the session they affect.

Pass 2. Left: kit-fix; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A places the engineer field and assignment button directly within Braid Quartet’s session, keeping the task accessible on mobile while B pushes the controls below the visible screen. B has more distinctive typography and clearer session emphasis, but A’s task-specific heading and adjacent controls better support finishing the assignment.

Finish the wardrobe callboard for a theatre dresser assigning the unfinished garment before its cue. Keep the ready garment visible as a separate state.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-fix. Raw preference: 5/7 (4 is neutral, higher favors right). B makes cue times, garment names and the assignment action easy to scan, and keeps the ready Wool cape visible on mobile. A provides a concrete tailor-name field, but its taller assignment card pushes the ready garment below the mobile view.

Pass 2. Left: kit-fix; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A keeps the unfinished Brass coat, assignment action and separate ready Wool cape visible on mobile, making the callboard easier to scan. B provides a concrete tailor-name field beside its assignment button, but its large introductory headline and taller form push the ready garment below the mobile viewport.

Derive a usable design system for a ceramicist distinguishing the held glaze test from the test ready for a batch. Preserve both firing records.

desktop: Plain render · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-design-system. Raw preference: 5/7 (4 is neutral, higher favors right). B’s compact mobile rows keep both firing records, results and statuses visible together, while A’s tall cards push the ready test below the fold. A has more distinctive typography and restrained status bands, but B places the held-test action directly beside its status on desktop and beneath its explanation on mobile.

Pass 2. Left: kit-design-system; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B gives each glaze a clear status band, aligned firing facts and a well-placed held-test action, creating a more deliberate journal interface. A is more compact on mobile and shows both complete records together, while B pushes the ready record below the visible area.

Finish the harbor departure board for a dispatcher checking which vessel can leave next. Preserve the restrictions, berths and times.

desktop: Plain render (original PNG) · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: kit-fix. Raw preference: 2/7 (4 is neutral, higher favors right). A foregrounds Petrel as the next cleared departure with its berth and 09:10 time on both widths, directly supporting the dispatcher's decision. B gives schedule rows larger type and stronger departure times, but leaves the next cleared vessel below Kittiwake; A preserves both vessels' restrictions, berths and times while making clearance priority clearer.

Pass 2. Left: kit-fix; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B prominently identifies Petrel at North quay, 09:10 as the next cleared departure at both widths, making the dispatcher's main decision immediate. B preserves Kittiwake's hold and restriction link, though A gives departure times stronger emphasis and states more explicitly that a scheduled time does not override a restriction.

Clarify which proof awaits approval and how its state changes when a client approves it, including a quiet path for reduced motion.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-animate. Raw preference: 2/7 (4 is neutral, higher favors right). A explicitly connects “Approve direction” to Identity direction, version 02 and the Review-to-Approved change, making the pending decision clearer. B gives the proof more space and a cleaner mobile presentation, but its “Over to you” approval panel is less direct; neither shows an approved result or a reduced-motion path.

Pass 2. Left: vendor-animate; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B ties approval explicitly to Identity direction, version 02 and states that approval changes Review to Approved. B also groups project details and approval clearly on desktop, though its taller mobile proof card pushes approval farther down than A. Neither shows an approved result or a reduced-motion path.

Improve reading and save feedback in a mobile typographic specimen feed. Keep the reading position stable.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-animate-expo. Raw preference: 2/7 (4 is neutral, higher favors right). A keeps the specimen name, descriptive detail and Save specimen control visible together on mobile. B offers a richer alphabet preview, but it pushes the specimen details and save action below the visible area; neither shows save feedback or provides evidence of reading-position stability.

Pass 2. Left: vendor-animate-expo; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B places a clearly labeled Save specimen control alongside the specimen description and keeps it visible on mobile. A exposes fuller alphabet samples for reading, but its oversized specimen panel pushes details and actions below the visible mobile area; neither shows save feedback or reading-position stability.

Improve reading and save feedback in a mobile typographic specimen feed. Keep the reading position stable.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-animation-performance. Raw preference: 3/7 (4 is neutral, higher favors right). A keeps the mobile header compact and reaches the first specimen sooner; B’s wrapped brand and taller introduction push reading content lower. A separates the serif classification from the specimen name, while B adds a useful character preview; neither shows save feedback or evidence of reading-position stability.

Pass 2. Left: vendor-animation-performance; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B gives Ledger Serif a clearer title, readable description and prominent full-width save action on mobile. A fits more specimens on desktop and preserves the character-and-number sample missing from B; neither shows save feedback or establishes reading-position stability.

Clarify which proof awaits approval and how its state changes when a client approves it, including a quiet path for reduced motion.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-animation-vocabulary. Raw preference: 2/7 (4 is neutral, higher favors right). A explicitly identifies version 02 in the approval copy and explains the change from Review to Approved beside the action; B groups proof and approval more tightly on desktop. A preserves readable proof labels and project details on mobile, while B visibly clips version, status and client text. Neither shows an approved outcome or a reduced-motion path.

Pass 2. Left: vendor-animation-vocabulary; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B ties approval to Identity direction, version 02 and explicitly explains the Review-to-Approved change beside the action. B also preserves readable proof labels on mobile where A clips content, though B pushes approval below the visible mobile area; neither shows a reduced-motion path.

Improve reading and save feedback in a mobile typographic specimen feed. Keep the reading position stable.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-apple-design. Raw preference: 3/7 (4 is neutral, higher favors right). A keeps the full Save specimen control visible on mobile immediately after the description; B places it lower, partially outside the frame. B adds a useful alphabet sample for evaluating letterforms, but its taller specimen panel delays the supporting facts and action. Neither shows save feedback or evidence of reading-position stability.

Pass 2. Left: vendor-apple-design; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B gives the mobile save action a fully visible, full-width button directly beneath the specimen description. A provides a useful alphabet preview that B omits, but B’s clearer separation of specimen and details makes reading easier; save feedback and reading-position stability cannot be judged from these stills.

Make the billing contact settings ready for a studio owner to edit and recover from a failed save on a phone.

Source: Dick Wu, dickwu/apple-design-skill.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-apple-design-hig. Raw preference: 2/7 (4 is neutral, higher favors right). A places the failed-save alert above the editable fields on mobile and visibly offers a retry action on desktop; B places the alert below the form, beyond the visible mobile area. B has roomier field grouping, but A’s billing-contact email guidance and connection-recovery copy better support the task.

Pass 2. Left: vendor-apple-design-hig; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B names the form “Billing contact” and places the failed-save alert before the fields, making the task and recovery context visible on mobile; A labels the form “General” and pushes the error below it. A fits more editable content on the phone, but B provides a visible desktop retry action and explicitly reassures that edits remain.

Prepare the webhook preferences form for an operator who must recover after a failed save without losing their endpoint.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-ask-sonner. Raw preference: 2/7 (4 is neutral, higher favors right). A keeps the retained endpoint, failed-save explanation and full-width Retry save button visible on mobile; B’s recovery button falls below the visible area. B has more distinctive navigation and refined section grouping, but A gives the recovery task a clearer, more compact path.

Pass 2. Left: vendor-ask-sonner; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B keeps the preserved endpoint, failed-save explanation and full Retry save button visible on mobile; A’s recovery button falls below the shown viewport. A has a more distinctive workspace navigation and delivery icon, but B gives the recovery task a clearer, more compact layout.

Review this access-request screen for release and address visual issues that obscure who can issue an invitation.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-better-accessibility. Raw preference: 2/7 (4 is neutral, higher favors right). A places who can issue an invitation directly beneath the expired-invitation heading, keeping that fact prominent at both widths; B puts it below the email field. A also explains that the request is prepared for sharing and is not sent, clarifying the button’s role, while B’s tinted notice makes the recovery guidance more visually distinct.

Pass 2. Left: vendor-better-accessibility; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B places the project producer’s authority directly beneath the expired-invitation heading, making who can issue a replacement clearer at both widths. A preserves the useful expiry detail “yesterday” in its callout, but B removes the distracting “Welcome back” and clarifies that the request is prepared rather than sent.

Help the owner of a newsletter choose the correct print subscription for their next issue. Keep the real prices and cutoffs.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-better-colors. Raw preference: 2/7 (4 is neutral, higher favors right). A pairs the $18/100-copy and $42/500-copy plans with explicit selection guidance and prominent Choose actions, making the cutoff decision clear. B adds a useful count-entry control, but its extra panel pushes the first plan’s action below the mobile viewport; A also gives a concrete ordering deadline.

Pass 2. Left: vendor-better-colors; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B makes the $18/100-copy and $42/500-copy choices easy to scan, with prominent selection buttons and explicit guidance for 101–500 copies. A offers a useful copy-count input that B lacks, but B’s clearer typography and tighter mobile cards make choosing a plan feel more direct.

Audit how a client finds the Atlas proof awaiting review. Give the implementer a precise repair brief.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-better-interface. Raw preference: 2/7 (4 is neutral, higher favors right). A puts Atlas in a dedicated awaiting-review section with its proof number, date and Review proof action; B leads with all projects, so add a prioritized review entry and keep its action visible on mobile. B has clearer, larger typography, but its tall mobile card pushes Review proof to the bottom edge and adds 'Date type not specified'; shorten the artwork and remove that filler while preserving the date.

Pass 2. Left: vendor-better-interface; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B places Atlas identity, Proof 02 and Review proof in a dedicated awaiting-review section above the project list on both widths; A makes the client locate the pending card, with its action near the bottom on mobile. B repeats Atlas and replaces A’s explicit project-date qualification with the vaguer Date on record; retain B’s priority section, restore precise date meaning and include Proof 02 in the review action.

Finish a dispatch manifest for a dock worker locating the next outbound crate. Preserve every shipment and its destination.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-better-layout. Raw preference: 2/7 (4 is neutral, higher favors right). A keeps all three shipments, dock destinations and departure times visible on mobile in a readable compact table, while B’s stacked shipment cards push later shipments below the frame. B emphasizes the departure dock with a large B badge, but A groups the next crate, Dock B and 09:40 clearly without repeating the dock information.

Pass 2. Left: vendor-better-layout; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B groups the next crate, destination and departure time into one clear panel; A repeats Dock B in a separate oversized badge. B also keeps all three shipments and destinations visible on mobile, while A’s taller shipment cards push later entries below the frame, though A gives individual shipment labels more room.

Make October billing legible at a glance for the studio owner following up unpaid invoices.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render (original PNG) · Procedure render

Pass 1. Left: plain; right: vendor-better-typography. Raw preference: 6/7 (4 is neutral, higher favors right). B puts the overdue invoice first and preserves its amount, issue date and status on mobile, making follow-up easier to prioritize. A offers a useful “Review overdue” action and collection progress, but its invoice list starts with a paid invoice.

Pass 2. Left: vendor-better-typography; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B makes follow-up explicit with an overdue alert showing $2,800, the invoice reference and a Review overdue action, including on mobile. A better prioritizes the invoice list by placing overdue and open invoices first; B spends its first visible row on a paid invoice.

Refine the contact and notification settings so a client can tell which details will change.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-better-ui. Raw preference: 3/7 (4 is neutral, higher favors right). A explicitly explains where the full name appears and where notification emails go, making the effects of edits clearer. A also keeps the notification toggle and destination visible on mobile; B offers stronger input borders and an explicit On label, but its taller layout pushes notification details below the visible area.

Pass 2. Left: vendor-better-ui; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B explains what the full name affects and where notifications go, with separate sections that keep the notification control visible on mobile. A gives the saved state clearer emphasis through its muted Save settings button and explicit On label, but its taller mobile layout pushes notification details below the visible area.

Audit the empty inspection inbox. Explain what happened, what to do next, and which screen changes would help.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-better-writing. Raw preference: 5/7 (4 is neutral, higher favors right). B groups the kiln and shift with the page context and separates Schedule Inspection from the quieter Completed link, making the next action clearer at both widths. A explicitly says no inspections are listed for this shift, while B’s shorter empty-state copy loses that useful scope despite reducing repetition.

Pass 2. Left: vendor-better-writing; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A groups the empty-state explanation, Schedule inspection button and Completed link into a concise next step, with comfortable spacing on mobile. B places the kiln and shift directly above the inbox and makes Completed more prominent, but repeats the empty-state explanation and gives both destinations competing emphasis.

Prepare the webhook preferences form for an operator who must recover after a failed save without losing their endpoint.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-break. Raw preference: 2/7 (4 is neutral, higher favors right). A places the failed-save alert before the fields and explicitly confirms that the endpoint and notification choice remain, making recovery clear. B gives the endpoint more horizontal room on mobile, but its extra “Failed save / Current endpoint · full width” row distracts from the form and retry action.

Pass 2. Left: vendor-break; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B places the failed-save alert before the preserved endpoint, making the recovery context clear before editing. A keeps the alert closer to Retry save, but its visible “Failed save / Current endpoint · full width” annotation distracts from the operator’s task at both widths.

Make the billing contact settings ready for a studio owner to edit and recover from a failed save on a phone.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-break-ui. Raw preference: 2/7 (4 is neutral, higher favors right). A shows a clear “Try saving again” action and unsaved status on desktop, while B’s visible recovery guidance lacks a visible retry action. A also fits more of the form on mobile without B’s floating demo controls overlapping content, although B’s “Billing contact” navigation and studio-name limit provide more specific guidance.

Pass 2. Left: vendor-break-ui; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B keeps more of the mobile form visible without A’s floating demo controls overlapping the content, and B shows an explicit retry action on desktop. A has the more specific “Billing contact” navigation label and preserves the 90-character studio-name limit that B omits.

Audit how a client finds the Atlas proof awaiting review. Give the implementer a precise repair brief.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render (original PNG)

Pass 1. Left: plain; right: vendor-build-design. Raw preference: 2/7 (4 is neutral, higher favors right). A gives Atlas a dedicated awaiting-review section with its client, proof number, date and Review proof action; B keeps that action visible but removes the client name and separate review queue - restore both. B’s shorter cards reduce duplication, but its large gradient greeting delays the actionable content on mobile; replace it with A’s compact task heading and prioritize the pending proof.

Pass 2. Left: vendor-build-design; right: plain. Raw preference: 7/7 (4 is neutral, higher favors right). B puts Atlas identity in an explicit awaiting-review section with Proof 02, the recorded date and Review proof together; A places the action inside the general project list beneath a large gradient greeting. B also preserves this priority on mobile, although repeating Atlas under All projects pushes other work down. Repair B by distinguishing the repeated Atlas entry and keeping Review proof prominent in the priority card at both widths.

A studio owner wants to see whether this invoice tool can show what clients still owe. Make the opening screen and its next step convincing.

Source: Leonxlnx, Leonxlnx/taste-skill.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-design-taste-frontend. Raw preference: 6/7 (4 is neutral, higher favors right). B pairs “Know what’s still owed” with $6,550 and its open/overdue split, making the task clearer than A’s more expressive headline. B also brings the invoice summary higher on mobile; A’s framed overview has more character, but delays the supporting facts.

Pass 2. Left: vendor-design-taste-frontend; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A pairs “Know what’s still owed” with explicit open and overdue amounts beside the total, making the task and dashboard action immediately clear. B has more expressive typography and a polished summary frame, but its taller mobile introduction pushes the invoice facts farther down and its summary omits the visible open/overdue amount breakdown.

Clarify which proof awaits approval and how its state changes when a client approves it, including a quiet path for reduced motion.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-emil-design-eng. Raw preference: 6/7 (4 is neutral, higher favors right). B’s approval panel names Identity direction, version 02, and explicitly connects approval to the Review → Approved change. A’s more compact mobile proof preserves more supporting context onscreen; neither A nor B demonstrates a reduced-motion path or completed approval state.

Pass 2. Left: vendor-emil-design-eng; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A’s approval panel explicitly ties approval to Identity direction, version 02, and the Review-to-Approved transition; B communicates the same transition but leaves the proof title out of its desktop card. B makes the awaiting-client-approval badge more prominent on mobile, while neither shows the approved outcome or a reduced-motion path.

Audit how a client finds the Atlas proof awaiting review. Give the implementer a precise repair brief.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-explain-interface. Raw preference: 2/7 (4 is neutral, higher favors right). A exposes Atlas identity, Proof 02, the recorded date and an explicit “Review proof” action together at both widths; B’s review banner preserves the proof reference but offers only an unlabeled arrow. B’s compact banner brings All projects and search higher on mobile; retain that compact layout, but add a visible “Review proof” label and the recorded date so the priority task is self-contained.

Pass 2. Left: vendor-explain-interface; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B makes the awaiting Atlas proof identifiable through its title, Proof 02, review status and explicit Review proof action; A compresses the same task into a banner with only an arrow. B’s expanded review card pushes All projects farther down mobile, while A keeps browsing closer. Preserve B’s explicit action and proof facts, but tighten the mobile preview height so project browsing remains easier to reach.

Improve reading and save feedback in a mobile typographic specimen feed. Keep the reading position stable.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-find-animation-opportunities. Raw preference: 5/7 (4 is neutral, higher favors right). B’s mobile specimen flows from letterform to name, description and save control, with the next specimen visible below, supporting feed reading. A’s boxed specimen and full-width save button make the action more prominent, but consume more vertical space; neither shows save feedback or evidence of reading-position stability.

Pass 2. Left: vendor-find-animation-opportunities; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A keeps the specimen name, description and save action compact enough that the next specimen begins within the mobile view. B groups each specimen more explicitly and gives the save button a wider target, but its separate glyph panel consumes more reading space; neither shows save feedback or evidence of reading-position stability.

Finish a working brew calculator for someone weighing coffee at the counter. Preserve the actual brew recipe.

Source: Lucas Markes, lucasmarkes/hairline.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-hairline-adopt. Raw preference: 2/7 (4 is neutral, higher favors right). A brings the dose selector and recipe quantities into view sooner on mobile, while B’s larger headline pushes the calculator lower. B gives the desktop recipe card more breathing room, but A’s cumulative-water chart label and instruction to keep the scale running better support weighing successive pours.

Pass 2. Left: vendor-hairline-adopt; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B places the dose control and recipe higher on mobile, while A’s awkward headline wrapping delays the calculator. B also clarifies cumulative water amounts and keeping the scale running while preserving the visible recipe; A’s larger desktop recipe card offers slightly easier scanning.

Finish a working brew calculator for someone weighing coffee at the counter. Preserve the actual brew recipe.

Source: Lucas Markes, lucasmarkes/hairline.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-hairline-create. Raw preference: 3/7 (4 is neutral, higher favors right). A explicitly labels cumulative water and tells users to keep the scale running, making the preserved 45 g, 144 g and 240 g recipe clearer at the counter. B has calmer card spacing and stronger grouping of ratio and water, but A brings the dose control and more of the pour graph into view on mobile.

Pass 2. Left: vendor-hairline-create; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B makes the counter task clearer with cumulative scale readings, an explicit instruction to keep the scale running, and a dose-focused primary action while preserving the recipe. A has a more compact mobile card and larger chart labels, but B more clearly distinguishes the ratio, total water and pour schedule.

A studio owner wants to see whether this invoice tool can show what clients still owe. Make the opening screen and its next step convincing.

Source: Nutlope, Nutlope/hallmark.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-hallmark. Raw preference: 6/7 (4 is neutral, higher favors right). B directly connects “Know what’s still owed” to $6,550 and an explicit $2,800 overdue amount, making the task and dashboard action clearer. A has more distinctive typography and studio framing, but its taller mobile introduction pushes the invoice facts farther down.

Pass 2. Left: vendor-hallmark; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A directly connects “Know what’s still owed” to the dashboard action and the $6,550 balance, explicitly identifying $2,800 overdue. B has distinctive typography and a cohesive summary panel, but its taller mobile introduction pushes the balance and invoice breakdown farther below the opening view.

Audit how a client finds the Atlas proof awaiting review. Give the implementer a precise repair brief.

Source: Paul Bakaus, pbakaus/impeccable.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-impeccable. Raw preference: 2/7 (4 is neutral, higher favors right). A identifies Atlas Foundry · Proof 02 and keeps Review proof visible sooner on mobile; B omits the proof number and says the action opens the project - restore Proof 02 and clarify the action’s destination. B gives Review proof stronger button treatment and avoids A’s repeated Atlas card; give A a solid primary button and exclude the awaiting-review item from the lower project list.

Pass 2. Left: vendor-impeccable; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B places Atlas identity, Proof 02, review status and Review proof together in a compact priority card; A omits an explicit proof number and adds redundant helper copy, although its filled action is more prominent. B gets the mobile review action onscreen sooner, but repeats Atlas under All projects; retain that compact grouping and strengthen the action’s visual emphasis.

Clarify which proof awaits approval and how its state changes when a client approves it, including a quiet path for reduced motion.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-improve-animations. Raw preference: 2/7 (4 is neutral, higher favors right). A explicitly ties “Approve direction” to version 02 and explains the Review-to-Approved change; B’s project-status wording makes the approval scope less precise. B gives the proof more visual prominence, but A’s compact mobile card brings supporting details closer; neither shows a reduced-motion path.

Pass 2. Left: vendor-improve-animations; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B groups the approval action with explicit Review-to-Approved copy and scopes approval to version 02. B also keeps the proof title and version together on mobile, although A gives the artwork more space; neither shows an approved result or a reduced-motion path.

Audit how a client finds the Atlas proof awaiting review. Give the implementer a precise repair brief.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-interface-review. Raw preference: 2/7 (4 is neutral, higher favors right). A gives Atlas a dedicated “Awaiting your review” section with Proof 02 and a visible “Review proof” action on mobile; B buries that action below a large preview, so move it beside the proof identity and status. B avoids A’s duplicated Atlas card and gives the project grid more room; preserve A’s priority treatment while showing Atlas only once and keeping search available.

Pass 2. Left: vendor-interface-review; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B puts Atlas identity, Proof 02 and Review proof together in a dedicated awaiting-review section on both widths; A leaves the action beneath the project card’s supporting details. B repeats Atlas under All projects, pushing the remaining projects farther down mobile: keep the prominent review action, reduce that duplication, and replace the vague Date on record label with a precise date meaning.

Improve reading and save feedback in a mobile typographic specimen feed. Keep the reading position stable.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-mobile-native. Raw preference: 3/7 (4 is neutral, higher favors right). A groups the specimen, description and full-width save action within one mobile card, making their relationship clearer. B gives the letterform more space and names it directly in the image label, but its detached description and smaller save control weaken the grouping; neither shows save feedback or evidence of reading-position stability.

Pass 2. Left: vendor-mobile-native; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B groups each specimen, description and Save specimen action within one bordered unit, with a wider mobile save control. A shows both specimens side by side on desktop, making comparison faster; neither shows save feedback or provides evidence of reading-position stability.

Prepare the webhook preferences form for an operator who must recover after a failed save without losing their endpoint.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render (original PNG)

Pass 1. Left: plain; right: vendor-pick-ui-library. Raw preference: 2/7 (4 is neutral, higher favors right). A keeps the retained endpoint visible and labels the recovery action “Retry save”; B retains the endpoint too, but uses the less specific “Save settings.” B offers clearer workspace navigation, but it pushes the form lower on mobile, where A’s full-width recovery button remains fully visible.

Pass 2. Left: vendor-pick-ui-library; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B makes recovery explicit with “Retry save” and preserves the endpoint visibly beside the failed-save message. B also keeps a full-width recovery action visible on mobile; A offers stronger workspace context, but its generic “Save settings” action communicates recovery less clearly.

Finish first-run setup for a library volunteer labeling returned crates. Make the first decision easy to act on.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-prototype. Raw preference: 6/7 (4 is neutral, higher favors right). B puts the reading-room selector directly above a prominent W-12 destination and Continue setup action, making the first decision easier to scan at both widths. A gives a clearer overview of both setup steps, while B’s Quiet/Guided/Editorial control adds an unexplained distraction beneath the form.

Pass 2. Left: vendor-prototype; right: plain. Raw preference: 2/7 (4 is neutral, higher favors right). A places the reading-room choice directly beneath the task heading and makes crate W-12 prominent, helping connect the selection to sorting returns. B provides a clearer two-step overview, but its introductory headline pushes the working form farther down on mobile and gives the crate destination less emphasis.

Improve reading and save feedback in a mobile typographic specimen feed. Keep the reading position stable.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-remove-animations. Raw preference: 5/7 (4 is neutral, higher favors right). B groups the mobile specimen identifier, title and description clearly, with a divider separating the save action. A offers a wider save target, while B uses a more compact control; neither shows save feedback or evidence that reading position stays stable.

Pass 2. Left: vendor-remove-animations; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B gives the mobile Save specimen action a full-width button directly below the description, making it easier to find and target. B also pairs each desktop specimen with its details in one row, though A shows more specimens at once; neither shows save feedback or proves reading-position stability.

Clarify which proof awaits approval and how its state changes when a client approves it, including a quiet path for reduced motion.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-review-animations. Raw preference: 2/7 (4 is neutral, higher favors right). A explicitly connects approval to Identity direction, version 02 and the Review-to-Approved change beside its action. B gives the proof more space and a cleaner mobile presentation, but shortens the approval status and separates the version from the proof heading. Neither shows a reduced-motion path or an approved result.

Pass 2. Left: vendor-review-animations; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B labels the proof as version 02 and explicitly connects approval to the change from Review to Approved, making the pending decision clearer. B also preserves a readable mobile title and status, though its taller proof card pushes the approval action farther down; neither A nor B visibly establishes a reduced-motion path.

Prepare the webhook preferences form for an operator who must recover after a failed save without losing their endpoint.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-state-machine. Raw preference: 2/7 (4 is neutral, higher favors right). A keeps the retained endpoint, failed-save explanation and Retry save action in a clear recovery flow, while B adds a detached Save failed control that competes with the form. B explicitly advises keeping the page open, but A preserves the notification explanation on mobile and gives the retry action clearer separation.

Pass 2. Left: vendor-state-machine; right: plain. Raw preference: 5/7 (4 is neutral, higher favors right). B gives the notification checkbox a useful explanation and keeps the error, retained endpoint and Retry save action clearly grouped at both widths. A provides more specific recovery guidance with its keep-page-open note, but its additional Save failed indicator competes with the inline error, especially on mobile.

Finish a working brew calculator for someone weighing coffee at the counter. Preserve the actual brew recipe.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-teardown. Raw preference: 2/7 (4 is neutral, higher favors right). A brings the dose control and pour profile higher on mobile and explains that water amounts are cumulative, useful when weighing each pour. B has a calmer visual hierarchy and larger recipe figures, but its taller headline delays the calculator and it omits A’s explicit instruction to keep the scale running.

Pass 2. Left: vendor-teardown; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B gives the dose selector a clear scale-related prompt and labels pour targets as scale readings while preserving the visible ratio, amounts and timings. B also brings the calculator higher on mobile with a shorter headline, though A’s quieter green chart feels more cohesive with its palette.

Help the owner of a newsletter choose the correct print subscription for their next issue. Keep the real prices and cutoffs.

Source: Jakub Krehel, jakubkrehel/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-variant. Raw preference: 2/7 (4 is neutral, higher favors right). A groups the $18/$42 prices, 100/500-copy cutoffs and choice buttons into clear plan cards with precise eligibility copy. B adds a useful copy-count input and visible prompt, but its unrelated structure selector distracts from choosing a subscription and pushes the plans farther down on mobile.

Pass 2. Left: vendor-variant; right: plain. Raw preference: 6/7 (4 is neutral, higher favors right). B clearly pairs Fold’s $18 price and 100-copy cutoff with Spine’s $42 price and 101–500 range, making the choice direct. B also preserves a clearer mobile hierarchy; A offers useful copy-count guidance, but its structure selector distracts from choosing a subscription.

Improve reading and save feedback in a mobile typographic specimen feed. Keep the reading position stable.

Source: Emil Kowalski, emilkowalski/skills.

desktop: Plain render (original PNG) · Procedure render (original PNG)

mobile: Plain render · Procedure render

Pass 1. Left: plain; right: vendor-write-swift. Raw preference: 5/7 (4 is neutral, higher favors right). B places specimen names above the letterforms and keeps the mobile save action fully visible, making browsing and saving easier to scan. A offers a larger mobile save target and more compact introduction, but neither A nor B shows save feedback or evidence that reading position stays stable.

Pass 2. Left: vendor-write-swift; right: plain. Raw preference: 3/7 (4 is neutral, higher favors right). A fits the specimen name, description and complete save control within the mobile view; B’s save control sits against the bottom edge. B offers a wider mobile save target and clearer category labeling, but A also exposes both specimens on desktop. Neither shows save feedback or establishes reading-position stability.