Claude Skills
The open format is called Agent Skills and works in Claude Code, Codex, Cursor and other agents — most people know it as Claude Skills.
Every Agent Skill we could find on GitHub, deduplicated by content. 79 341 files from 1 736 authors, of which 61 700 are unique — the rest is the same skill repackaged into someone else's repository. For each one: what it weighs in tokens, whether it ships runnable scripts, and which MCP servers it needs.
Create, revise, translate, scrape, crop, validate, and prepare App Store marketing screenshots and `.appstore-screenshots` workspaces. Not for general image generation.
Orchestrate TestFlight distribution, groups, testers, and What to Test notes using asc. Use when rolling out betas.
Use when App Store subscription groups, subscriptions, or in-app purchases need localized display names or descriptions created or updated with `asc`. Not for app listing metadata, What's New release notes, keywords, screenshots, or pricing.
Route broad or ambiguous Swift and Apple-platform work across the Build Swift Apps skill pack. Use before choosing among adjacent iOS, macOS, SwiftUI, Xcode, simulator, App Store Connect, Tuist, SwiftPM, signing, profiling, or Apple research skills.
Design and implement App Intents, AppEntity, EntityQuery, and App Shortcuts for iOS system surfaces such as Shortcuts, Siri, Spotlight, widgets, controls, and app handoff routes.
Define, validate, run, resume, and audit repo-local `.asc/workflow.json` automations with current `asc workflow`, including safe release/TestFlight flows and step outputs.
Submit or update a Wall of Apps entry in the App-Store-Connect-CLI repository using `asc apps wall submit`. Use when the user says "submit to wall of apps", "add my app to the wall", or "wall-of-apps".
Capture and interpret symbolicated ETTrace profiles for iOS simulator startup, scrolling, navigation, rendering, runtime flows, before/after comparisons, and CPU hotspots.
Implement, refactor, or review iOS 26+ SwiftUI Liquid Glass features using native `glassEffect`, `GlassEffectContainer`, glass button styles, availability gates, and fallbacks.
Use RocketSim for iOS Simulator UI inspection and interaction, including visible accessibility state, taps, long-presses, swipes, typing, hardware buttons, and RocketSim CLI automation.
Capture, inspect, compare, and prove iOS leaks with Apple's `leaks`, simulator memgraphs, retain-cycle evidence, and before/after leak summaries.
Build, run, launch, inspect, interact with, and debug iOS simulator apps using XcodeBuildMCP tools, UI descriptions, screenshots, and log capture. Prefer ios-simulator-browser for user-facing browser mirrors, visible simulator proof, or SwiftUI preview viewing.
Build or refactor iOS SwiftUI views/components: navigation, TabView, sheets, async state, responsive stacks/grids, state ownership, environment injection, previews, and performance-aware declarative UI.
Prefer this over plain simulator-only workflows when the user should watch, interact with, or receive browser-visible proof of an iOS Simulator run. Use to mirror an iOS Simulator into the Codex in-app browser and render SwiftUI previews from importable Swift packages with hot reload.
Implement, refactor, or review modern macOS SwiftUI Liquid Glass UI: NavigationSplitView, toolbars, search, sheets, controls, system materials, `glassEffect`, `GlassEffectContainer`, and `glassEffectID`.
Decide when and how to bridge a macOS app from SwiftUI into AppKit. Use when implementing NSViewRepresentable or NSViewControllerRepresentable, accessing NSWindow or the responder chain, presenting panels, customizing menus, or handling desktop behaviors that SwiftUI does not model cleanly.
Use when preparing or diagnosing macOS Developer ID distribution artifacts, including archives, exported app bundles, bundle structure, hardened runtime, notarization readiness, or distribution-only failures. Not for local signing-only diagnosis or direct `asc notarization` execution.
Build, run, and debug local macOS apps or desktop executables with shell-first Xcode/Swift workflows. Use for Mac app builds, launch scripts, compiler/linker/startup failures, logs, telemetry, or desktop runtime debugging.
Build, run, and test pure SwiftPM-based macOS packages and executables. Use when the repo is package-first, when there is no Xcode project, or when Swift package workflows are the fastest path to diagnosis.
Use when an existing macOS app or binary needs code-signing, entitlement, hardened runtime, sandbox, Gatekeeper, or trust-policy diagnosis. Not for full distribution packaging or running notarization submissions.
Triage failing macOS tests across Xcode and SwiftPM workflows. Use when asked to run macOS tests, narrow failing scopes, explain assertion or crash failures, or separate real test regressions from setup and environment problems.
Refactor macOS SwiftUI views/scenes into small stable subviews, explicit scene roots, command/toolbar ownership, scene-aware state, and narrow AppKit bridges.
Build or refactor native macOS SwiftUI scenes and components: windows, commands, toolbars, settings, split views, inspectors, menu bar extras, keyboard workflows, and desktop layouts.
Add and verify lightweight macOS runtime telemetry with `Logger`/`os.Logger`, `log stream`, Console filters, signposts, and build-run checks.
Customize macOS 15+ SwiftUI windows and scene behavior: toolbar/title visibility, drag regions, window materials, minimize/restoration, default/ideal placement, launch behavior, and borderless windows.
Audit SwiftUI runtime performance from code and profiling evidence for slow rendering, janky scrolling, high CPU or memory, excessive updates, hangs, and layout thrash.
Debug Tuist-generated project failures across generation, build, and runtime. Use when `tuist generate`, generated Xcode workspaces, or generated app launches fail or behave differently from the source project.
Analyze Swift Package Manager dependencies, plugins, module variants, branch pins, package graph shape, macros, binary targets, and CI/local build overhead that slow Xcode builds.
Investigate and fix flaky tests using Tuist test insights and local repeated test runs. Use when a user provides a flaky test URL, test case identifier, or asks to find and stabilize flaky tests.
Refactor SwiftUI view files toward small dedicated subviews, MV-first data flow, stable view trees, explicit dependencies, extracted actions, and correct Observation usage.
Benchmark Xcode clean, cached-clean, zero-change, and incremental builds with repeatable inputs, timing summaries, and `.build-benchmark/` artifacts.
Migrate existing Xcode projects toward Tuist-generated workspaces. Use when converting hand-maintained Xcode projects, mapping targets/settings/dependencies, or validating generated builds and launches.
Work productively in Tuist-generated Xcode workspaces. Use for `tuist generate`, generated workspace builds, focused generation, tags, buildable folders, and Xcode build/test commands after generation.
Recommend-first Xcode build optimization: benchmark, run specialist analyses, prioritize wall-clock findings, request approval, delegate fixes, and re-benchmark. Use for speeding up Xcode builds or full build audits.
Audit Xcode project configuration, schemes, build settings, target dependencies, run scripts, module maps, explicit modules, and fixed build overhead with approval gates.
Apply approved Xcode build optimization changes and re-benchmark. Use after `xcode-build-strategist` approval, or for explicit build-setting, script-phase, Swift compilation, or SwiftPM graph fixes.
Analyze Swift and mixed-language compile hotspots from timing summaries, Swift frontend diagnostics, type-checking warnings, CompileSwiftSources, SwiftEmitModule, and related build evidence.
Create, stabilize, and run UI end-to-end tests with Xcode (XCUIApplication/xcodebuild), including environment setup, focus/input stabilization, logging/attachments, and flakiness triage. Use when adding or debugging UI automation, writing new UI tests, or making them reliable.
Use for Next.js App Router, React Server Components, server actions, API routes, auth, database integration, caching, deployment, or full-stack product features.
Use for slow endpoints, p95/p99 latency, database query issues, frontend bundle/render performance, memory leaks, caching, profiling, or performance regressions.
Use for Python code changes, FastAPI/Django/Flask services, packaging, typing, async, pytest, data scripts, dependency hygiene, or Python performance fixes.
Use when designing or reviewing safe Grok Build hooks for linting, tests, formatting, notifications, command guards, lifecycle automation, or project hook trust decisions.
Use for frontend features, Next.js/React/Vue/Svelte UI, accessibility, responsive layout, design polish, state handling, forms, visual QA, or product workflow improvements.
Use for branch prep, clean commits, PR descriptions, GitHub issue triage, changelogs, release notes, review response, merge readiness, or publishing a branch safely.
Use when reviewing a diff, pull request, branch, or AI-generated code for correctness, security, regression, test, performance, and maintainability risks before merge.
Use for clean architecture, modular monoliths, hexagonal boundaries, service boundaries, data flow, dependency direction, ADRs, or large feature planning.
Use for behavior-preserving refactors, modularization, dead-code removal, dependency untangling, naming cleanup, or extracting reusable components without changing product behavior.
Use for current web/X research, library/API verification, competitive analysis, source-backed technical decisions, or updating docs with recent facts.
Use for security review, auth/permission changes, secrets, dependency risk, injection, SSRF, XSS, CSRF, data exposure, unsafe hooks, or supply-chain concerns.
Use for test-first development, regression tests, flaky test debugging, coverage gaps, test strategy, CI failures, or converting bugs into minimal reproducible tests.
Use when auditing a repo before changes to find the smallest safe PR, quality risks, stale docs, missing tests, ignored-file gaps, or agent setup issues. Best first skill for unfamiliar codebases.
Audit a game, feature, progression system, social system, live-ops loop, onboarding flow, monetization surface, or multiplayer space through the lens of the Big Five personality traits (OCEAN): Openness, Conscientiousness, Extraversion, Agreeableness, and Neuroticism. Use when evaluating which personality-style preferences a design feels comfortable for, which kinds of players it energizes or exhausts, how much structure, novelty, social intensity, conflict, or emotional pressure it creates, or when you need a personality-fit lens that is different from archetype or motivation-segment frameworks.
Audit a game, feature, event, progression system, social system, live-ops loop, or onboarding flow through the lens of Bartle player archetypes: Achievers, Explorers, Socializers, and Killers. Use when evaluating who a design motivates, who it neglects, whether a feature over-serves one archetype at the expense of others, how a system will be perceived by different motivational player types, or why engagement is uneven across different player motivations.
Turn a game-design emotional canvas into a curated visual moodboard by deriving image-search queries, gathering a candidate pool from the internet, saving the files locally, rejecting weak references, and rendering both an HTML board and a flattened JPG board. Use when a user wants a moodboard from an emotional canvas, wants visual references for a game concept, or wants a reusable workflow that turns emotional direction into search terms, downloaded image files, and a tastefully curated presentation-ready board.
Audit a game, feature, combat scenario, progression step, failure state, onboarding beat, or reward outcome through the lens of attribution theory: how players explain success and failure. Use when evaluating whether players will blame themselves, the system, luck, or hidden rules; diagnosing perceived unfairness, learned helplessness, rage, or churn after losses; or identifying where clarity, control, and feedback are too weak for healthy learning.
Extract the actual core loop from a game, feature set, or pitch based on repeated player actions, feedback, rewards, and renewed motivation. Use when a team can list mechanics but cannot clearly articulate the repeatable loop that drives engagement, when a pitch sounds like disconnected features, when a design document lacks loop clarity, or when you need to test whether the claimed loop is coherent, rewarding, and structurally complete.
Break game design creative block with oblique prompts, sideways reframing, and deliberately non-linear workflow moves. Use when a feature, mechanic, live-ops idea, UX flow, FTUE, economy layer, or prototype feels stale, overthought, equally uninspired in every direction, or trapped in circular discussion. Best when the team needs jolts, detours, provocations, and weird-but-useful next directions rather than another sensible framework.
Apply established brainstorming and ideation methodologies to game design problems, features, systems, UX flows, live-ops ideas, content concepts, and stuck team discussions. Use when the user wants a specific brainstorming method rather than generic ideation, or when you should choose and run a method such as SCAMPER, How Might We, Crazy 8s, Six Thinking Hats, Brainwriting 6-3-5, Worst Possible Idea, forced connections, Lotus Blossom, or a morphological matrix.
Adversarial design audit that stress-tests a game feature, system, pitch, roadmap item, or product idea by assuming failure and identifying the most credible reasons it would fail. Use when pressure-testing a concept before production, performing a pre-mortem, challenging a feature that sounds good on paper, exposing blind spots in design thinking, or getting a hostile-but-constructive critique with concrete failure mechanisms and de-risking moves.
Define, refine, and evaluate the emotional identity, feeling, atmosphere, and vibe of a game, feature, event, region, or content theme. Use when shaping a game's emotional core, building a moodboard brief, clarifying the intended player feeling, checking whether a concept feels emotionally hollow, aligning art/audio/narrative around one emotional promise, or reviewing whether new content reinforces or dilutes the intended mood.
Claude Skills — questions
Answers built from the skills we actually parsed.