product-surface-polish

Product Surface Polish

Use When

• Editing pricing pages, plan cards, upgrade/paywall screens, feature lists, in-app feature pages, navigation rows, empty states, model pickers, auth/sign-in provider buttons, settings copy, App Store metadata, TestFlight metadata, app icons, product categories, onboarding, or marketing UI.
• A product/settings/auth surface names third-party providers or tools and needs their logos, brand marks, icons, or provider-choice affordances.
• A product/settings surface uses another AI's import/export prompt, dialog, or onboarding flow as a reference for the product's own prompt or flow.
• The user points at reference products and asks for the surface to feel similar, bigger, cleaner, more premium, simpler, or less awkward.
• Editing a grant, application, or submission packet where the funder's required materials, page limits, applicant type, budget rules, line-item cost assumptions, or optional award resources define the artifact.
• Editing a research grant/application packet where the research question, evaluation method, and experimental apparatus must stay distinct from product, pilot, or prototype deliverables.
• The reference arrives through a help article, FAQ, video, screenshot, or live browser page, and the product surface depends on its layout, copy, or interaction pattern.
• The user names a real app, device, screen, or artifact contract for a product surface, such as an existing app Upgrade screen or a specific simulator.
• Product or proposal copy/visuals need to preserve a user-corrected architecture, runtime split, or reference shape.
• Copy includes internal terms, vague feature claims, filler benefits, or numbers that may drift from enforced plan limits.

Near miss: do not load this for backend-only billing logic unless a user-visible product surface is being changed.

Procedure

1. Name the exact surface and audience: store listing, home-screen app identity, pricing page, locked paywall, onboarding, model picker, grant packet, or in-app settings. If the user named a real app path, device, screen, or artifact contract, include that in the surface contract before acting.
2. For grant/application/submission packets, read the official application page and write the artifact contract before drafting: required attachments, page limits, budget requirements, applicant category, deadline, submission email/form, and selection criteria. Before finalizing a budget, build a source-backed cost model for the material lines: parts or services needed, quantities, unit prices or defensible ranges, vendor/source class, and why the compressed one-page line item matches the project shape. Keep sidecar award resources such as credits, access, support, or provider APIs out of the proposal thesis and section structure unless the application asks for them or the user explicitly asks to feature them. For research grants, name the research claim, evaluation method, and apparatus separately before editing: the device, prototype, or pilot is the instrument unless the official requirements make it the deliverable. Lead deliverables with research artifacts such as a study protocol, evaluation suite, dataset, results, apparatus, or technical report; do not make a working product or pilot the headline when the funder asks for research.
3. Read the real references the user named, plus the closest direct competitors when the user asks "how do others do it." For browser, help-article, FAQ, video, or screenshot references, save and read durable artifacts before editing: full-page screenshots or frames, article images and metadata, FAQ text, and the relevant DOM or visible text. Extract the pattern in concrete terms: naming formula, navigation placement, icon choice, subtitle placement, empty versus populated state, primary creation affordance, example prompts or rows, card/list hierarchy, feature taxonomy, spacing, and responsive behavior.
4. Classify each reference's role before implementing: verbatim source to copy, inspiration to synthesize from, or interaction/component behavior to match. For behavior to match, write the interaction contract before changing code: what the empty state invites, where input lives, which examples appear, how the layout changes once data exists, and what confirms success or failure. Use one success confirmation; when the pressed control visibly changes to Copied, a checkmark, or another done state, do not add a duplicate success toast. Copy provider prompt text verbatim only when the user asks for copying; when provider prompts are examples of how another app extracts/imports data, write one product-owned prompt shaped by the pattern instead. When the user corrects the product architecture, runtime location, or reference object, propagate that correction through headings, captions, image prompts, diagrams, and verification steps before generating more artifacts.
5. Read the product source of truth before writing copy: plan constants, enforced quotas, billing config, app metadata, bundle settings, feature gates, and current screenshots. A pricing claim must trace to code or config; store metadata must trace to App Store Connect or bundle settings.
6. For subscription or paywall work, prove the in-app purchase path before store-review artifacts: inspect the paywall code/config, product IDs, selected-plan params, StoreKit/Superwall wiring, and a real simulator/device screenshot or flow. If the user named an existing app, simulator, or screen, install/launch that exact target and navigate the normal app path; a preview flag, standalone fixture, or different booted device is a proxy unless the user explicitly asked for it. Do not upload App Store review screenshots or polish subscription metadata while the app only has static cards or an unproven trigger.
7. Translate internal capability into user language. Remove engineering phrases and filler such as "tool-heavy," "model context window," "standard usage," "switch anytime," or "add more credits anytime" unless the reference products and product truth make them genuinely meaningful.
8. For tiered pricing, make progression visible from low to high: more quota, broader capability, clearer support/access. Keep duplicated roll-up lines short, avoid unlimited claims unless the runtime actually enforces no limit, and align cards across desktop and medium-width layouts.
9. For provider import/export dialogs, use the app's existing standard dialog and controls first. Custom sizing, typography, or cloned competitor chrome needs a concrete reason from the reference pattern and the local design system.
10. For third-party provider logos, including auth buttons, search local repo assets first, then current web, vendor, and public icon sources before inventing a mark. Prefer official brand kits or established public SVG icon packages; keep the resulting asset local in the app with its source recorded. Text initials or generated marks are temporary implementation scaffolds, not the final product surface, unless no real mark exists after search.
11. For app-owned icons and store metadata, choose the model/tool intentionally after checking available local/API options. Generate or edit the asset only after the reference pattern is clear, then verify the built app bundle uses the asset and the public metadata changed.
12. Verify on the actual surface, not a proxy: screenshot or inspect the live page, run typecheck/lint/build, verify responsive wrapping, and for referenced interaction models verify the relevant states that define the pattern, not only that the route renders. For App Store/TestFlight work confirm the processed uploaded build or current App Store Connect fields.