Skills · Moru Core

A skill is a short guide an agent reads when the task needs it: how to name a branch, structure an Android module or review a Flutter diff. Moru Core picks the matching skills from your request and project, so agents only read what applies.

Every project (71)

  • Accessibility I18n — Use when changing UI text, forms, controls, navigation, media, keyboard/focus behavior, dates, numbers, units, measurements, currency, localization, display values, or user-facing error states.
  • Agent Editing Safety — Use when routed to common/skills/agent-editing-safety/SKILL.md or when work needs this Moru Core guidance area.
  • Agent Interaction — Use when an agent needs clarification, approval, a status update, or a handoff message.
  • Agent Operating Skill — required_docs and safety/check dependencies. Resolve isolation/branch before the first edit, not at commit/PR; reuse a bound worktree.
  • Agent Skill Card Anatomy — Use when creating, updating, splitting, or reviewing Moru Core common cards, workflow cards, platform cards, product-pattern cards, or agent-facing templates.
  • API Contract Compatibility — Use when changing HTTP APIs, DTOs, schemas, SDK clients, route contracts, deep links, events, webhooks, queues, import/export formats, or shared fixtures.
  • Application Boundary Principles — Use for new features, boundary cleanup, or structure decisions.
  • Architecture Design — Use when planning architecture for a feature, module, service, or app surface.
  • Architecture Selection — Use when choosing or changing architecture for an app, service, or major feature.
  • Asset Lifecycle — Use when touching uploads, downloads, generated files, media, attachments, signed or temporary URLs, public/private asset movement, asset cleanup, or asset references embedded in persisted content.
  • Bounded Loop — Read only for an explicitly requested sustained task with a checkable finish condition. Ordinary tasks do not enroll. This card adds no authority, router, wakeup, model service, automatic commit, source rollback or final-gate waiver.
  • Branch Cleanup — Use for requested cleanup of merged branches or stale worktrees. Deletion is destructive Git work: every target must pass the gates below; otherwise preserve and report it. Remote deletion requires an explicit request.
  • Branch Strategy — Use when creating, naming, checking, reviewing, or documenting git work branches in any repository, with or without a tracking ticket.
  • Browser Runtime Testing — Use when verifying browser UI behavior, runtime wiring, network calls, console errors, DOM state, accessibility tree, storage, routing, forms, or performance signals.
  • Bulk Change Verification — Use when applying one rule across many files at once — contract migrations, mass renames, sliced conversions — with a script or repeated mechanical edits, and when checking that the change and its verification actually looked at something.
  • Change Size Policy — Use when deciding how much code to change, whether to split work, or whether a diff is reviewable.
  • CI/CD And Automation — Use when creating, changing, reviewing, or debugging CI pipelines, release automation, scheduled jobs, build matrices, checks, deployment automation, package publishing, or repository workflow files.
  • Code Conventions — Use when writing, changing, or reviewing code style, naming, structure, comments, errors, and formatting.
  • Code Review — Use to review the current work product: working tree, diff, PR, or implementation result. Review against the user's request, repo-local instructions, and any project or product guidance.
  • Code Structure And Ownership — Use when routed to common/skills/code-structure-ownership/SKILL.md or when work needs this Moru Core guidance area.
  • Commit Review — Use when reviewing one or more commits instead of the current working tree.
  • Commit Workflow — Use before creating commits, regardless of git client, IDE, CLI, or AI tool.
  • Component API Design — Use when designing, splitting, promoting, or reviewing reusable UI components, view/section/block components, hooks, widgets, controls, SDK helpers, or other caller-facing component APIs.
  • Data Persistence Sync — Use for local persistence, cloud sync, offline mode, migrations, import/export, cache invalidation, and conflict handling.
  • Defensive Boundaries — Use when code consumes values from outside the current trusted boundary: user input, environment, configuration, files, network responses, databases, clocks, platform APIs, third-party SDKs, generated artifacts, or cached state.
  • Definition Of Done — Use before final report, handoff, commit, release, or PR creation to decide whether an agent task is actually complete.
  • Dependency Policy — Use before adding, replacing, upgrading, or removing libraries, SDKs, build plugins, packages, services, or runtime tools.
  • Deprecation And Migration — Use when removing, renaming, replacing, migrating, or sunsetting code, APIs, configuration, data shapes, routes, workflows, commands, features, or docs.
  • Design System — Use when creating or changing shared UI primitives, tokens, patterns, component defaults, or reusable interaction rules.
  • Document Conventions — Use when creating, reviewing, routing, or naming generated project documents such as PRDs, specs, ARDs, feature folders, and module implementation docs.
  • Doubt-Driven Development — Use for high-risk or non-obvious decisions where a confident first answer can hide product, architecture, security, data, reliability, cost, or release risk.
  • Error Modeling — Use when designing, handling, mapping, logging, retrying, or displaying errors.
  • Figma Handoff — Use when routed to common/skills/figma-handoff/SKILL.md or when work needs this Moru Core guidance area.
  • Generated Files Policy — Use when codegen, lockfiles, snapshots, build artifacts, schema clients, translations, icons, assets, or formatting tools modify files.
  • Git History Investigation — Use when the task is to recover why existing code is the way it is: why a line or block exists, whether apparently strange or dead code is safe to remove, or which commit really authored a behavior. The output is an evidence-backed verdict, not a plausible story.
  • Human-Authored Writing — Use when routed to common/skills/human-authored-writing/SKILL.md, when prose needs voice or AI-writing-signal cleanup, or when an intended reader cannot reconstruct a technical explanation from the text.
  • Incremental Implementation — Use when building, refactoring, or repairing non-trivial behavior. The goal is to deliver one thin, verified slice at a time instead of creating broad speculative scaffolding.
  • Live Device — Use when an Android or iOS app project may be running under Moru's Devices Live (Android Live or iOS Live): every save of a Kotlin, Java or Swift file is sent into the app already running on the emulator, device or simulator, in about a second, without a reinstall or restart. Several agents may be saving into the same running app at once.
  • LLM Coding Discipline — Use when routed to common/skills/llm-coding-discipline/SKILL.md or when work needs this Moru Core guidance area.
  • LLM Wiki Documentation — Use when routed to common/skills/llm-wiki-documentation/SKILL.md or when work needs this Moru Core guidance area.
  • Local Tools Policy — Use installed local tools when they provide better evidence, faster inspection, or safer execution than guessing.
  • Minimal Visual Design — Use when building or restyling a screen, landing page, product story, or component whose visual quality matters and the result should look refined and quiet rather than developer-default. Do not use it to decide token or component ownership; that is common/skills/design-system/SKILL.md. A repository's existing design system, brand guide, or Figma source always wins over this card.
  • Observability Error Handling — Use when adding or reviewing errors, logging, diagnostics, monitoring, audit events, support traces, or user-facing failure states.
  • Performance Verification — Use when changing, reviewing, or reporting performance across any platform.
  • Product Spec To Implementation — Use when turning a product request, PRD, design note, or vague feature idea into implementation work.
  • Project Naming — Use when naming apps, repos, packages, modules, services, CLIs, slugs, directories, bundle ids, or generated project scaffolds.
  • Public Discovery — Use when touching SEO, generative AI search visibility, AEO/GEO claims, sitemap, robots, metadata, Open Graph previews, short links, public indexes, search/discovery feeds, share previews, canonical URLs, localized alternates, or structured data.
  • React And React Native External Skill Source Coverage — Use when React web or React Native work depends on external agent-skill coverage, when refreshing the reviewed React/RN source snapshot, or when an agent must prove that a provider skill was not omitted.
  • Refactoring Guidance — Use when routed to common/skills/refactoring/SKILL.md or when work needs this Moru Core guidance area.
  • Release Deployment — Use when packaging, deploying, publishing, migrating, signing, tagging, creating release notes, changing environment config, or preparing rollback-sensitive work.
  • Release Versioning — Use when choosing, changing, reviewing, tagging, or documenting a release, deployment, package, app, build, or artifact version.
  • Reusable Code Design — Use when creating, moving, extracting, or reviewing code that should be reused across screens, features, modules, packages, services, or apps.
  • Runtime URL Configuration — Use when implementing or reviewing app, server, mobile, desktop, webhook, auth, or asset code that references URLs whose value changes by environment.
  • Scenario-Driven Testing — Use this before writing or reviewing test code. Tests should prove the workflow a user, operator, API caller, or downstream component depends on, not only that a single data shape was accepted.
  • Secure Development Baseline — Use this for any work that touches secrets, auth, permissions, user data, external integrations, local storage, logs, analytics, crash reporting, release configuration, or open-source-safe setup.
  • Security Privacy Review — Use for auth, permissions, secrets, personal data, logs, storage, browser bundles, mobile storage, and external integrations.
  • Server Side Caching — Use when touching server-rendered data, API response caching, framework data cache, request memoization, edge/CDN cache, database query cache, materialized read models, or cache invalidation.
  • SOLID Design Principles — Use when writing, refactoring, or reviewing production code that creates or changes functions, classes, components, hooks, services, repositories, adapters, interfaces, protocols, public contracts, or module boundaries.
  • Source-Driven Development — Use when implementation depends on a framework, SDK, API, platform behavior, standard, release note, or external documentation that can change over time.
  • Stack Discovery — Use before running project commands, adding dependencies, editing build config, or writing framework-specific code in an unfamiliar repo.
  • State Modeling — Use when designing or reviewing UI state, application state, domain state, async state, one-off effects, reducers, stores, ViewModels, hooks, or state machines.
  • Task Intake And Effort Routing — Use when routed to common/skills/task-intake-effort-routing/SKILL.md or when work needs this Moru Core guidance area.
  • Testing Principles — Use when choosing, adding, reviewing, or reporting tests, fixtures, snapshots, manual smoke checks, or verification evidence.
  • Tool Failure Recovery — Use when a build, test, lint, typecheck, formatter, package, script, file-edit, or local tool command fails.
  • UI Visual Verification — Use when changing UI layout, interaction, visible text, controls, navigation, responsive behavior, accessibility labels, or state presentation.
  • Verification Policy — Work is not done just because files changed. Completion requires evidence or a clear explanation of why evidence could not be collected.
  • Web Deployment Versioning — Use when choosing, documenting, reviewing, or automating version, release, build, deployment, rollback, or changelog policy for a web app, website, frontend, server-rendered web surface, or static site.
  • Web Performance Verification — Use when routed to common/skills/web-performance-verification/SKILL.md or when work needs this Moru Core guidance area.
  • Web Service RN Python — Router only. Use this pack to choose the focused Moru Core cards for a non-Android React web, React Native, and Python web-service task, then load those cards before detailed advice, editing, or review.
  • Worktree Hygiene — Use when working in an existing checkout, especially when the agent did not start from a clean tree.
  • Writing Workspace — Use when an agent is asked to draft, revise, review, or publish a blog post, article, essay, public announcement, release narrative, or other durable prose that may later be copied into a website, docs repo, newsletter, social channel, or publishing system.

Workflows (20)

  • Agent Handoff Continuation Workflow — Use when work may continue across turns, interruptions, context compaction, another agent, or a handoff back to the user.
  • Agent Task Lifecycle Workflow — Load references/current-guidance.md only for an unresolved lifecycle step, gate field, required-document drift or recovery rule.
  • Ambiguity Gate — Load references/current-guidance.md only when the task needs blocker discovery, an alignment brief or a Grill-Me session.
  • Bugfix Debugging Workflow — The procedure is references/current-guidance.md.
  • Cycle Contract Workflow — Use when a routed task produces durable work: code, docs, tests, workflow policy, release artifacts, or product requirements. The goal is not to create an endless autonomous loop. The goal is to make one useful cycle explicit enough that another agent or human can verify whether it actually completed.
  • Development Cycle Workflow — Use for multi-step implementation work from request intake through handoff. This is the default workflow when the task is larger than a one-line edit.
  • Documentation Update Workflow — Use when routed to workflows/skills/documentation-update/SKILL.md or when work needs this Moru Core guidance area.
  • Feature Implementation Workflow — Use when implementing a scoped feature slice or meaningful behavior change after the product front matter is known.
  • Multi-Agent Collaboration — Use when routed to workflows/skills/multi-agent-collaboration/SKILL.md or when work needs this Moru Core guidance area.
  • Multi-Perspective Review — Use for non-trivial reviews where a single correctness pass may miss product, UX, architecture, reliability, security, release, or QA risk.
  • Planning Research Workflow — Use when the task is to investigate, compare options, write an implementation plan, assess risk, or prepare a recommendation before editing code.
  • PRD Creation Workflow — Use when the deliverable is a PRD or product requirements note before ARD, implementation, tests, or release planning.
  • Product Architecture Delivery Workflow — Use when a task should move from product intent to implementation through a full delivery gate:
  • Refactor Cleanup Workflow — Use when behavior should stay the same and the goal is structure, naming, ownership, deletion, or maintainability.
  • Release Readiness Workflow — Use before packaging, deploying, publishing, tagging, migration rollout, signing, or handing off release-sensitive work.
  • Request Triage Workflow — Use when the agent needs to decide whether a user request is clear, whether a Grill-Me /grilling session is needed, and what effort level or route should be used before planning or implementation.
  • Retrospective Learning Workflow — Use when the active workflow requires a closeout check, when a required hook or gate failed, when the user explicitly reports that a previously completed result was wrong and asks to correct that same result, or when completed work exposed a reusable gap in a skill the agent actually used. This bundle is the single owner of the failure-repair and skill-learning automation boundary.
  • Review And Commit Workflow — Use for final review and commit/push/PR preparation. Load references/current-guidance.md for --commit-ready, local merges/fast-forward, same-run continuation, PR reuse, merge order, rejected commands or another unresolved procedure.
  • Scripted Agent Workflow — Use when routed to workflows/skills/scripted-agent-workflow/SKILL.md or when work needs this Moru Core guidance area.
  • Session Continuation Protocol — Use when work must survive the death of the process doing it, and be picked up by a later session or a different runtime.

Product patterns (7)

  • Agent Credential Broker Ideation — Use when brainstorming, comparing, or reviewing credential-broker, vault, proxy, scoped-token, egress-control, or approval-loop patterns for AI agents. This card is for ideation and architecture framing. It is not an implementation runbook and must not replace the always-on secret-handling rules in ../common/skills/secure-development-baseline/SKILL.md.
  • Auth RBAC Implementation — Use when implementing login, session refresh, organization/workspace membership, role assignment, permissions, entitlement checks, tenant scoping, protected actions, or authorization tests.
  • Auth, RBAC, Permissions — Use for login, membership, role, permission, entitlement, and tenant-boundary work.
  • Billing Entitlements — Use for plans, seats, quota, feature access, invoices, subscription status, payment failures, and downgrade behavior.
  • Billing Entitlements Implementation — Use when implementing plans, subscriptions, seats, quota, trial, downgrade, payment failure, invoices, provider webhooks, billing permissions, or feature gates.
  • Invitation Implementation — Use when implementing team, workspace, organization, tenant, project, or billing invite creation, resend, revoke, accept, email delivery, role assignment, or invite tests.
  • Invitation Workflows — Use for team, tenant, workspace, or organization invite flows.

Android (12)

  • Android Architecture — Use for Compose/ViewModel/Flow, data, and Android platform boundary work.
  • Android Background Work — Detail for the background-work card. Read it at the steps that link here: WorkManager, foreground services, alarms, push notifications, sync, uploads, downloads, and long-running jobs.
  • Android Compose UI — Use when a change adds, changes, moves or reviews a Compose composable, screen skeleton, modifier, effect, lazy list, animation or preview.
  • Android External Skill Source Coverage — Use when Android work cites or imports lessons from the external skill repositories android/skills, skydoves/compose-performance-skills or chrisbanes/skills; this is a source coverage manifest, not a vendored copy.
  • Android Memory And Lifecycle — This card owns who holds an Android resource, which lifecycle API gates it, when it is released, and which coroutine scope runs work that can outlive a screen, view, composition, or worker.
  • Android Module Structure — This card owns where Android code lives: package vs module, the api/impl/ui split, dependency edge direction, moving existing code between modules, build-logic convention plugins, and Hilt module placement.
  • Android Review — Use when reviewing any Android app, Compose/ViewModel, permission, background, or UI flow change.
  • Android Security — Use when Android work touches credentials, local storage, IPC, deep links, WebView, permissions, exported components, or release builds.
  • Android State And Data — This card decides where data work sits in the layer flow, how request/response DTOs and their fields are declared, how mappers convert and fail, what a repository exposes, and which persistence store to use.
  • Android ViewModel And State — Use when creating, changing, moving, or reviewing Android ViewModels, typed actions, UiState, one-off effects, Flow, or state-facing error handling.
  • Figma To Android — Use when reading measurements, assets, and component structure from a Figma handoff bundle and implementing or auditing Android UI. This card supports Compose, Views/XML, and repositories that intentionally use both.
  • Android Skill Source Coverage — Use when Android work cites, imports, compares, or refreshes guidance from the external Android and Compose skill repositories.

iOS (8)

  • Figma To iOS — Use when reading measurements, individual assets, and component structure from a Figma handoff bundle and implementing or auditing iOS UI. This card supports SwiftUI, UIKit, and repositories that intentionally use both.
  • iOS Architecture — Use for iOS SwiftUI/UIKit app structure, state, navigation, async work, permissions, and app target behavior.
  • iOS Module Structure — Use when deciding iOS targets, local Swift packages, feature folders, package layout, access control, public contracts, or where new SwiftUI/UIKit code should live.
  • iOS Review — Use for iOS SwiftUI/UIKit, navigation, concurrency, permission, and UI flow review.
  • iOS Security — Use when iOS work touches credentials, Keychain, local storage, permissions, Universal Links, URL schemes, app groups, extensions, WebViews, networking, signing, entitlements, or release builds.
  • iOS State And Concurrency — Use when touching SwiftUI/UIKit state, navigation, async work, or platform permissions.
  • iOS SwiftUI UI — Use when creating, changing, moving, or reviewing SwiftUI screens, view models, state models, reusable views, previews, navigation, or UI tests.
  • iOS UIKit UI — Use when creating, changing, moving, or reviewing UIKit screens, view controllers, coordinators, view models, table/collection views, diffable data sources, forms, navigation, or UI tests.

Swift (4)

  • Swift Architecture — Use for Swift app or library architecture across Apple platforms: iOS, macOS, watchOS, tvOS, widgets, extensions, command-line tools, and local Swift packages.
  • Swift Code Structure — Use when deciding Swift Package Manager layout, Xcode targets, feature folders, file ownership, target membership, access control, public contracts, or where new Swift code should live.
  • Swift Design System — Use when creating, changing, reviewing, or adopting SwiftUI, UIKit, or AppKit design-system tokens, primitives, component variants, layout patterns, themes, interaction states, previews, or visual QA rules.
  • Swift Review — Use for reviewing Swift app, package, architecture, module, SwiftUI/UIKit/AppKit UI, state, concurrency, design-system, platform adapter, or Apple target changes.

Flutter (7)

  • Flutter Architecture — Use when a Flutter change creates or moves a layer, feature slice, state owner, repository, use case, platform service, composition root, or navigation shell, or when shared Dart code must stay reusable across features, apps, or targets.
  • Flutter Platform Integration — Use when Flutter work touches MethodChannel/EventChannel, generated channel code, plugins, native Kotlin/Swift code, permissions, OS data stores (health, photos, contacts, location), push notifications, app lifecycle, background execution, isolates, secure storage, files, share sheets, WebViews, or iOS/Android build setup (Swift Package Manager or CocoaPods, Gradle, manifests, entitlements, privacy manifests).
  • Flutter Project Structure — Use when deciding Flutter feature folders, local Dart packages, pub workspace or monorepo packages, plugin or federated plugin splits, package exports, or where Dart and native (Kotlin/Swift) platform code should live.
  • Flutter Review — Use when reviewing a Flutter diff: widgets, state owners, Dart packages, repositories, platform channels, plugins, native code, target setup, release configuration, or mobile/desktop/web behavior.
  • Flutter Security — Use when Flutter work touches credentials, tokens, secure storage, biometrics, platform channels, plugins, WebViews, deep links, local files, clipboard, notifications, network clients, logs, analytics, crash reports, sensitive OS data (health, photos, location), release builds, or signing.
  • Flutter State And Data — Use when touching Flutter state owners (Riverpod, BLoC/Cubit, Provider, ChangeNotifier, ValueNotifier, or a local pattern), view models, commands, streams, repositories, local storage, caching, remote backends, offline sync, isolates, or async effects.
  • Flutter Widget UI — Use when creating, changing, moving, or reviewing Flutter routes, pages, screens, widgets, design-system components, themes or tokens, forms, gestures, navigation UI, accessibility, golden tests, or widget tests.

Kotlin Multiplatform (7)

  • KMP Architecture — Use when a Kotlin Multiplatform or Compose Multiplatform change creates or moves a layer, feature slice, composition root, platform service, window, or long-running process, including Compose desktop apps on the JVM and shared mobile/desktop logic.
  • KMP Compose UI — Use for Compose Multiplatform screens, state holders, components, previews, resources or UI tests in shared or desktop (JVM) source sets. Not for Android-only modules (platforms/android/skills/android-compose-ui/SKILL.md) or non-Compose UI.
  • KMP Module Structure — Use for multiplatform modules, source sets, Gradle edges, build logic, expect/actual placement or package layout, including desktop JVM targets. Not for Android-only projects or edits inside an existing package.
  • KMP Platform Integration — Use when Kotlin Multiplatform work touches source sets, expect/actual, native interop, platform services, files, shell/process execution, clipboard, notifications, permissions, secure storage, background work, app lifecycle, iOS framework export and Swift interop, OS data stores, or desktop (JVM) packaging and distribution.
  • KMP Review — Use when reviewing Kotlin or Compose Multiplatform changes, including desktop JVM apps. Not for Android-only reviews (platforms/android/skills/android-review/SKILL.md) or implementation work.
  • KMP Security — Use when Kotlin Multiplatform work touches credentials, tokens, local files or config, shell or process execution, network clients, secure storage, platform permissions, native interop, logging, release builds, or signing, on mobile or desktop (JVM) targets.
  • KMP State And Data — Use for shared Kotlin state holders, coroutines, Flow, repositories, persistence, sync, settings or session state, including desktop JVM targets. Not for Android-only ViewModels or pure rendering changes.

React Native (1)

  • React Native App — Use when creating, changing, moving, or reviewing React Native or Expo screens, components, navigation, lists, animations, native integrations, networking, or mobile performance work.

Web (10)

  • Figma To Web — Use when producing a handoff bundle from a node-id Figma link and converting it into Web components, tokens, assets, and responsive/accessibility implementation criteria.
  • Live Web — Use when a user points at a running web page through an inspect reference line and asks an agent to change it, or when several agents edit one web project at the same time and each owns an area the user assigned.
  • Web Accessibility I18n — Use for web-specific UI text, forms, menus, dialogs, keyboard flow, focus, localization, and responsive text behavior. Also use common/skills/accessibility-i18n/SKILL.md for platform-neutral accessibility and internationalization rules.
  • Web Architecture — Use for React web UI work: routing, pages, components, hooks, forms, data fetching, browser storage, and browser UX.
  • Web Code Structure — Use when deciding where React/web files live, how feature folders are shaped, how route files compose data and UI, or how imports should flow across a web application.
  • Web Design System — Use when creating, changing, reviewing, or adopting web UI tokens, primitives, component variants, layout patterns, themes, interaction states, or visual QA rules.
  • Web React UI — Use when the target Web repository is confirmed to use React, Next.js, Remix, JSX, or TSX and work changes or reviews React UI structure, state, rendering, interaction, or tests.
  • Web Review — Use for React/web UI, browser behavior, and frontend PR review.
  • Web Security — Use when web work touches auth, session state, browser storage, cookies, tokens, forms, uploads, embeds, third-party scripts, client-visible config, redirects, or protected UI actions.
  • Web State And Data — Use when touching React client state, server state, forms, API clients, cache, mocks, or browser persistence.

Server (5)

  • Server API Implementation — Use when creating, changing, moving, or reviewing HTTP handlers, GraphQL resolvers, RPC methods, webhooks, service methods, repositories, API validation, tenant boundaries, or response contracts.
  • Server Architecture — Use for API, worker, database, auth, tenancy, and integration-service work.
  • Server Data And Jobs — Use when touching database, migrations, transactions, queues, webhooks, or background jobs.
  • Server Review — Use for API, worker, database, auth, tenancy, migration, and integration review.
  • Server Security — Use when server work touches auth, permissions, tenant isolation, API input, database queries, webhooks, jobs, uploads, external calls, rate limits, secrets, or public endpoints.

Desktop apps (6)

  • Application Architecture — Use for desktop/native app shells on any stack (Swift/macOS, Electron, Tauri, Compose Multiplatform desktop on the JVM, or another native toolkit): windows, menu bar/tray, commands, local files, background work, and system integration. Stack cards refine this parent; they do not replace it.
  • Application Command And UI — Use when creating, changing, moving, or reviewing desktop/native app windows, panels, menu bar/tray items, shortcuts, commands, local state, background tasks, trust boundary bridges, or UI tests on any desktop stack (Swift/macOS, Electron, Tauri, Compose Multiplatform desktop on the JVM, or another native toolkit). Stack cards such as platforms/application/skills/application-react-desktop/SKILL.md and the KMP cards refine these rules.
  • Application React Desktop — Use when building, refactoring, or reviewing a desktop app that uses a React renderer inside a native shell, such as Tauri, Electron, WebView, or a Mac/Win app with embedded web UI.
  • Application Review — Use for desktop/native app review on any stack (Swift/macOS, Electron, Tauri, Compose Multiplatform desktop on the JVM, or another native toolkit): menu bar, window, command, trust boundary, and system integration review. Load the matching stack review card as well when one exists.
  • Application Security — Use for desktop/native app security on any stack (Swift/macOS, Electron, Tauri, Compose Multiplatform desktop on the JVM, or another native toolkit): menu bar tools, local files, shell access, update flows, IPC, and privileged OS APIs.
  • Application System Integration — Use when touching windows, commands, files, file watchers, shell, clipboard, notifications, background work, power assertions, menu bar/tray items, or app updates on any desktop stack (Swift/macOS, Electron, Tauri, Compose Multiplatform desktop on the JVM, or another native toolkit).

Python (1)

  • Python Web Service — Use when creating, changing, moving, or reviewing Python HTTP APIs, FastAPI or Starlette routes, Pydantic models, dependency injection, middleware, service layers, async I/O, settings, or endpoint tests.