capacitor-localization

Find real bugs and broken flows in a Capacitor app — the JavaScript that runs inside the WebView and the seams where it meets the native shell. Use when a Capacitor/Ionic app misbehaves on one platform but not the other, when a button does nothing, when something is slow or unresponsive, when a change does not appear on the device after a rebuild, before shipping a release, or when asked to QA or debug such an app ("באג בקפסיטור", "לא עובד במכשיר"). It carries a catalog of WebView traps measured on real devices, and the recipe for driving the WebView from the Mac over devtools instead of tapping the user's phone. For a native Swift app use apple-bug-flow-review; its analyzer, sanitizers and XCUITest have nothing to work on here.

Tighten existing product copy — App Store / Google Play listing text, marketing and product sites, README marketing sections, in-app strings, replies to store reviews — when it reads clumsily: long sentences, stacked clauses, the same point made twice, throat-clearing openers, jargon the buyer does not know, or a translation that reads as a translation rather than as the language. Use when the user says copy is convoluted, wordy, clunky, unprofessional, hard to read, sounds machine-written, "מסורבל", "מנוסח רע", "נשמע כאילו מודל כתב", or asks to rewrite, tighten, sharpen or polish existing text in any language. This skill EDITS text that already exists; it does not decide what to say. Run it before delivering copy to a store or deploying a site.

Build an app's product profile — the one document every piece of copy about it is later derived from: store listings, site pages, campaigns. Use when onboarding a new app, before writing any copy for it, or when the user asks to "analyze my app", "write up what my app does", "build the marketing profile", "document the app's advantages" ("נתח את האפליקציה", "בנה פרופיל"). It reads the app's source like a product analyst, interviews the owner for what code cannot reveal, researches the real competitors, and proposes a feature and advantage list for the owner to edit before anything is written. Writes `profile.md`, an owner-facing translation beside it, and prepares the media folder. It does NOT capture media (appstore-media does), does NOT write store listing text (store-metadata-writer does), and never writes the app's name or subtitle — those live in the app's README, owned by app-identity.

Decide an app's NAME for both stores, and own the project README as the source of truth for the name, subtitle / short description, and detected feature list. Use when the user wants to name or rename an app, asks "what should I call my app", wants to change the name under the icon or in a store listing, or wants the README's feature list written or refreshed ("תן שם לאפליקציה", "עדכן את ה-README"). Run it when the app is feature-complete, and always BEFORE app-store-metadata, play-store-metadata, aso-keywords and appstore-media, which all read the name and feature list from here. It scans the code for features and monetization, proposes ASO-aware candidates, and DISCUSSES them: it never picks a name on its own. Once decided it writes the display name into the Apple build settings and into Android's strings.xml, and owns the README's version label and changelog. It does NOT write the store metadata files or the keyword field — app-store-metadata, play-store-metadata and aso-keywords own those.

Set up the app factory in a repo, or say why its skills are not loading. Use when a store or release skill that should exist is missing, when the user asks "why aren't the skills loading here", "set up the factory", "enable the tracks", "which tracks does this repo need" ("למה אין לי את הסקילים", "תפעיל את המסלולים"), or after installing the marketplace for the first time. It reads the repo to decide what it is, proposes the tracks that follow, and writes the repo's own .claude/settings.json. It does NOT install plugins, does NOT change the machine's global settings, and does NOT commit — enabling a track is a fact about one repo.

Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling or beautifying any web UI; "תעצב את הדף", "שפר את העיצוב"). Generates creative, polished code and UI design that avoids generic AI aesthetics. It does NOT decide a page's structure — `page-builder` does that first — and does NOT audit the result (`web-design-guidelines`).

Take a built macOS app from an Xcode archive, package it into a signed DMG, notarize it with Apple, staple the ticket, and verify that everything — the app AND the DMG — is properly signed and notarized for direct (non-App-Store) distribution. Use this whenever the user wants to ship a Mac app outside the Mac App Store ("נוטריזציה", "קובץ DMG"): build/create a DMG, sign with Developer ID, notarize, staple, fix "app is damaged / can't be opened / unidentified developer" Gatekeeper errors, or verify notarization status. Covers the Developer ID flow only (for Mac App Store builds, that's a different signing path). It signs, notarizes and packages; setting up the Sparkle update channel is macos-direct-distribution's job.

Audit and manage IN-APP localization for a macOS or iOS Xcode project — the user-facing strings inside the app (Localizable.strings / .xcstrings String Catalogs), NOT the App Store listing text. Use this whenever the user wants to localize or translate the app's UI ("תתרגם את האפליקציה", "תוסיף שפה"), add or check a language, find hardcoded (un-localized) strings in Swift, check that all locales have all keys (no missing / empty / untranslated strings), find unused or undefined string keys, migrate to String Catalogs, or handle RTL (e.g. Hebrew) and pluralization. For App Store listing metadata (name/description/keywords per language), that's the separate app-store-metadata skill.

Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.

No description in the SKILL.md.

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.

Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".

tasteskill 2.5.1, the anti-slop frontend skill. Builds professional company websites at the level of figma.com and x.ai: plain copy in a voice of its own, one system, one section per screen, equal edges, real photographs and real product UI (licensed stand-in photographs when the client has none; a product render only when the brief asks for 3D), a hero entrance and one or two dealt moments on every page, shader effects and scenes only on tech, gaming and software pages, quiet micro-interactions, and a checker and finish gate that enforce it in a real browser. Use this whenever you build, design, redesign, restyle, polish or review a landing page, company, product, shop, cafe, hotel, studio, SaaS, AI, developer-tool or game site, as static HTML/CSS or inside an existing React, Next.js, Vue, Svelte, Astro or Tailwind project, or when the user says a page looks generic, templated or "AI-made".

React composition patterns that scale. Use when refactoring components with boolean prop proliferation, building flexible component libraries, or designing reusable APIs. Triggers on tasks involving compound components, render props, context providers, or component architecture. Includes React 19 API changes.

UI/UX design intelligence for web, mobile, and desktop. This skill should be used when designing, building, reviewing, or fixing interfaces, including pages, components, design systems, accessibility, interaction, responsive layout, typography, color, charts, and stack-specific UI implementation. Searchable local data: 80 searchable styles (51 active), 192 product palettes and reasoning profiles, 74 font pairings, 120 UX guidelines, 105 icons, 17 GSAP presets, 25 chart types, and 22 stacks.