Web & Mobile App Builder

View saved version →

---
name: build-android-app
description: Create or improve native Android apps using Kotlin and Jetpack Compose, modern Android navigation, permissions and Material 3 guidance.
---

# Build Android App

1. Read `../../references/android-native.md`, `../../references/platform-choice.md`, and current repo configuration. Keep Gradle, Kotlin and Compose dependencies compatible; verify versions with docs when possible.
2. Use Compose and suitable architecture such as ViewModel and state flows; structure screen UI, navigation, repositories, persistence and network requests. Honor existing framework if established.
3. Follow Material 3 and Android platform conventions, including system bars, predictive back, permissions, adaptive layouts, accessibility semantics and dynamic color where appropriate.
4. Implement real states, retries, background constraints and offline strategy rather than hiding failures behind loading spinners.
5. Build/test with real Android SDK and emulator/device if available. If tools unavailable, deliver exact commands and clearly mark tests unverified.
6. No automatic Play Console publishing, signing key handling or production permission changes.

View saved version →

---
name: build-cross-platform-app
description: Build or maintain a shared-codebase iOS and Android app using Expo/React Native or Flutter, preserving platform-specific behavior and release constraints.
---

# Build Cross Platform App

1. Read `../../references/cross-platform.md` and select Expo/React Native vs Flutter based on existing repository, team capabilities, native modules, UX requirements, web needs and performance.
2. Shared core does **not** imply identical screens. Respect iOS navigation/safe areas and Android back navigation/system UI/Material conventions; use platform-specific components when warranted.
3. Implement coherent navigation, forms, offline/persistence model, accessibility and error states. Do not claim Web, Android and iOS functionality tested because one platform builds.
4. Separate app state, network/adapters and platform permissions; audit third-party native packages, build plugins and secrets.
5. Run available platform tests/builds separately; for iOS signing/simulators require macOS/Apple tooling, Android builds require proper SDK. Clearly mark unrun platforms.
6. Provide actual source, setup instructions, dependency versions, proof of builds and remaining platform risks; request approval for EAS/App Store/Play publishing.

View saved version →

---
name: build-from-idea
description: Build a complete working website, web app, PWA, native Apple app, Android app, or cross-platform app from a product idea, including design direction and actual verification where available.
---

# Build From Idea

Use when the user's intent is to **make/build/create/implement** an app. Do not respond only with a tech stack or mockup when code tools exist.

1. Read `../../references/platform-choice.md`, `../../references/execution-model.md` and `../../references/design-quality.md`. Capture user outcome, core workflow, intended platform, data/auth constraints and minimal complete vertical slice. Honor a requested framework; otherwise choose by needs and document the rationale.
2. Inspect repository/environment or create a new runnable workspace using current tool-supported commands. Existing code is authoritative over preferred defaults.
3. Design-first, not design-only: prepare a short reference-backed visual direction (type, composition, color, density, navigation, signature details); inspect user sources first. Read `../research-design-direction/SKILL.md` and `../create-design-system/SKILL.md`. If user requests concept selection, stop for approval; otherwise choose a defensible direction and implement it.
4. Specify key screens and functional states: initial, empty, loading, error, disabled, success, permission and mobile/large-screen behavior. Read `../design-app-flows/SKILL.md`.
5. Implement real navigation/state/data boundaries, not inert fake buttons. Choose the focused platform skill and `../design-backend/SKILL.md` if server/data work is needed.
6. Secure any user data and implement accessible controls. Read `../secure-app/SKILL.md` for authentication, uploads or sensitive integrations.
7. Run actual builds/tests. Capture browser or simulator renders and compare to design direction where tools permit. Use `../test-app/SKILL.md` and `../review-visual-ux/SKILL.md`; fix significant findings and rerun.
8. Use `../orchestrate-agents/SKILL.md` for genuine subagents when available; otherwise perform roles sequentially without fabricating reports.
9. Return source paths/links, commands and actual test output, design decisions, known failures and unverified items. Do not claim submission or deployment without actual action and permission.

Completion: one real user workflow executes successfully **when execution tools exist**, or disclose the precise execution blocker.

View saved version →

---
name: build-ios-app
description: Build, refactor or debug true native iOS applications in Swift and SwiftUI with Apple navigation, persistence, accessibility and Xcode verification.
---

# Build Ios App

1. Read `../../references/apple-native.md`, `../../references/design-quality.md` and `../../references/execution-model.md`. Inspect existing Xcode project, OS target, Swift language mode, dependencies and capabilities; preserve package signing and current state.
2. Prefer SwiftUI for modern native screens and selectively use UIKit bridges when justified. Use native NavigationStack/navigationSplitView, tabs, sheets, presentation detents, dynamic type, accessibility labels and safe areas appropriately. Do not produce web/CSS-style interfaces inside SwiftUI.
3. Design platform-appropriate loading/empty/errors, permission prompts, state restoration, dark appearance and VoiceOver. Respect user-provided screenshots and HIG constraints.
4. Separate views, observable state, persistence/network clients and test seams. Use SwiftData/Core Data/files as appropriate for the project's OS target; do not choose storage solely by trend.
5. For charts, consult `../../references/apple-native.md` and user-provided Swift Charts Examples when licensed/useful; use Swift Charts for meaningful data with accessible descriptions.
6. Build with real Xcode/xcodebuild, run simulator/UI tests and inspect render when Mac tools are present. In Linux-only or no-Xcode environments, label all Apple builds as **unverified**; never fabricate simulator screenshots.
7. Do not promise App Store approval, provisioning or TestFlight distribution without credentials and user authorization.

View saved version →

---
name: build-macos-app
description: Build or improve native macOS apps with SwiftUI and AppKit integrations, multiple windows, keyboard shortcuts, persistence and Xcode tests.
---

# Build Macos App

1. Read `../../references/apple-native.md` and inspect target/architecture before editing.
2. Respect macOS-specific patterns: menus, commands, focus, toolbar, sidebar/split view, multi-window behavior, document handling, drag-and-drop and native keyboard shortcuts. Do not merely enlarge an iPhone layout.
3. Model autosave/retry, document identity, undo/redo, window restoration and resilient persistence when needed. Preserve existing data and filenames by default.
4. Use SwiftUI for primary UI with AppKit where unavoidable. Handle accessibility, keyboard use, dark mode and dynamic resizing.
5. Run xcodebuild/unit/UI tests on supported macOS host. On other platforms provide source and precise unverified test steps rather than a fake build pass.
6. Packaging, signing and notarization require real Apple tooling/credentials and approval.

View saved version →

---
name: build-pwa
description: Turn an existing web app into a genuine PWA or build a new installable PWA with manifest, service worker strategy, offline behavior and installation testing.
---

# Build Pwa

1. Read `../../references/web-and-pwa.md`; start with the user's web framework and existing content. Explain that PWA installation and capability vary by browser and OS, especially iOS.
2. Implement a valid manifest (name, icons, start URL, display modes), HTTPS deployment expectations and a versioned service worker when needed. Pick a cache strategy per resource class; avoid caching sensitive authenticated data by default.
3. Define offline UX: shell, data that may be cached, unavailable actions, queued writes only when consistency/replay is safe, conflict behavior and user-facing sync status.
4. Test installability with compatible tools/browsers, simulate offline and cache refresh, update flows and version migration. Validate mobile layouts and app icon sizes when assets are available.
5. Do not claim background sync, push, arbitrary file access or install prompt is universally supported. Record platform/browser constraints and actual tests.
6. Return manifest/service worker source, commands, test log and limitations.

View saved version →

---
name: build-web-app
description: Implement complete browser-based apps, dashboards, editors and SaaS products with real state, navigation, API boundaries and design-quality verification.
---

# Build Web App

1. Read `../../references/web-and-pwa.md`, `../../references/design-quality.md`, `../../references/testing-and-evidence.md` and project conventions.
2. Preserve existing framework if extending; for new apps select React/Vite, Next.js or another framework based on routing, rendering, hosting and data needs. Confirm current package versions and APIs from source docs when possible.
3. Start with a runnable vertical slice: one real workflow, state persistence strategy, accessible controls and error/retry handling. Separate UI primitives, features, API/data modules and routing. Avoid a single huge component.
4. Use actual user-approved integrations or local fixtures clearly marked as demos. No fictitious authentication, backend, data metrics or paid subscriptions.
5. Render desktop and mobile layouts, interact with the main workflow and check loading, offline, empty, error, focus and reduced motion. Read `../review-visual-ux/SKILL.md`.
6. Run typecheck/lint/unit/integration/browser tests when supported, record commands and failures, and fix critical defects before handoff.

View saved version →

---
name: build-website
description: Build or redesign responsive marketing sites, landing pages, portfolios and editorial websites with a distinctive visual hierarchy, genuine content and browser verification.
---

# Build Website

1. Distinguish informational sites from authenticated apps; do not wrap an app in an unnecessary marketing homepage.
2. Review `../../references/design-quality.md`, `../../references/web-and-pwa.md` and chosen design references. Preserve supplied copy, sections, branding and factual claims; ask only for blocking assets.
3. Choose an appropriate static/SSR framework based on existing project, SEO, editorial needs and content management. Avoid imposing Next.js on a simple static site.
4. Implement semantic structure, navigation, functional forms/links, responsive grids, responsive images, safe typography and sensible performance budgets. Generated visuals require asset authorization and actual generation tools.
5. Run build/lint/tests, check mobile and desktop layout and keyboard navigation, inspect hero/section continuity and interaction states. Never claim browser inspection without captured evidence.
6. Deliver runnable source, previews where available and test/visual findings. No automatic publish.

View saved version →

---
name: create-design-system
description: Create or adapt a consistent, accessible design system for a web, PWA, iOS/macOS or Android app, including tokens, components, typography, spacing and interaction states.
---

# Create Design System

1. Review the existing project's design tokens/components first; preserve its recognizable identity unless redesign is requested.
2. Read `../../references/design-quality.md` and the relevant platform guide: `../../references/web-and-pwa.md`, `../../references/apple-native.md`, or `../../references/android-native.md`.
3. Define semantic color tokens, typography roles, spacing scale, elevation/borders, radius, icon rules, motion duration/easing, responsive breakpoints or adaptive size classes. Design for content and task, not a single fashionable template.
4. List component states (rest, hover where relevant, pressed, focus, disabled, loading, selected, error, success), light/dark and reduced-motion variants.
5. Implement shared components and tokens rather than repeating hardcoded style fragments. Include examples and usage constraints.
6. Verify contrast/focus, touch target sizing, screen-reader labeling, dynamic content, localization and long text. Follow native platform systems when building native apps.
7. Provide code artifacts and before/after screenshots when implementation tools exist; otherwise a design token/spec file and explicit limits.

View saved version →

---
name: debug-app
description: Diagnose and fix actual web, PWA, SwiftUI, macOS, Android or React Native crashes, broken UI, build errors and app state bugs.
---

# Debug App

1. Inspect user's logs, reproduction steps, versions, OS/browser, recent changes and repository. Reproduce failure when tools allow; do not assume the first plausible explanation is the cause.
2. Narrow to minimal failing scenario, instrument safely, and capture baseline command and error. Avoid logging secrets, tokens or user data.
3. Determine root cause and implement smallest justified patch. Keep unrelated behavior unchanged and add a regression check.
4. Run focused test, typecheck/build, then broader related checks; for UI defects inspect relevant viewport/device and expected state.
5. Report reproduction evidence, changed files, test output, and remaining caveats. When environment blocks reproduction, state hypothesis as unverified.

View saved version →

---
name: design-app-flows
description: Design end-to-end product navigation and interface states for dashboards, editors, commerce, onboarding, forms, mobile apps and complex interactive workflows.
---

# Design App Flows

1. Identify the user task, starting context, necessary permissions and completion signal. Map primary and secondary journeys without inventing business features.
2. Create a screen inventory showing entry, normal, empty, loading, offline, permission denied, error, validation, success, retry and recovery states. Use `../../templates/screen-state-inventory.md`.
3. Design accessible navigation, information hierarchy, keyboard/touch interactions, back behavior and persistence. For native apps, respect safe areas, platform tab/nav conventions, state restoration and OS permissions.
4. Define what each interactive control actually does. Label simulated demo state explicitly, never represent placeholder buttons as production flows.
5. Verify the journey at small and large viewports or device sizes, including long labels, dynamic type and one-hand interactions where relevant.
6. Hand off screen/state requirements to platform implementation and QA skills; include user-visible expected outcomes.

View saved version →

---
name: design-backend
description: Design and implement backends, data models, APIs, storage, authentication boundaries and integrations for web or mobile apps while preserving security and data integrity.
---

# Design Backend

1. Capture actual domain entities, read/write flows, consistency, data sensitivity, tenancy and permission levels. Read `../../references/backend-architecture.md` and `../../references/security-and-privacy.md`.
2. For existing systems inspect migrations, API contracts, constraints, indexes and current auth. Avoid destructive schema edits or broad data access.
3. Prefer simple typed APIs, explicit authorization per request, validated inputs, idempotency on retries, bounded pagination, standardized errors and auditability for consequential writes.
4. Choose storage based on query patterns and deployment needs; do not force Supabase/Firebase/Postgres on every project. Keep migrations reversible and test them with fixture data.
5. Use environment secret providers, never client-embedded privileged keys. Handle API errors, timeouts, retries and rate limits.
6. Integrate through real tests, confirm access controls and disclose unverified external credentials/flows.

View saved version →

---
name: get-started
description: Route requests to build, design, improve, debug, test, or release websites, PWAs, iOS, macOS, Android, and cross-platform apps; clarify actual available execution capabilities.
---

# Get Started

Use this onboarding/router when user asks how to begin or what the plugin does.

1. Determine whether user wants a **build**, plan, design study, existing-app edit, review, bug fix, release or explanation. For build requests, implement when capable: do not stop at an abstract plan.
2. Identify app target and core user outcome. If user supplied repository/code/screenshot/Figma/url, preserve it as the primary source; do not overwrite working behavior.
3. Inspect actual tools available in the current host (workspace, terminal, browser, simulator, subagents, deploy tools). Follow `../../references/execution-model.md`. Never claim a tool, simulator, screenshot, integration or deployed URL without evidence.
4. For new apps, route to `../build-from-idea/SKILL.md`; for plans, `../plan-product/SKILL.md`; for native SwiftUI, `../build-ios-app/SKILL.md` or `../build-macos-app/SKILL.md`; for PWA, `../build-pwa/SKILL.md`; for Android, `../build-android-app/SKILL.md`; for cross-platform, `../build-cross-platform-app/SKILL.md`; for project modernization/debugging, `../improve-existing-project/SKILL.md` or `../debug-app/SKILL.md`.
5. Apply `../../references/platform-choice.md`, `../../references/design-quality.md`, and `../../references/security-and-privacy.md` as relevant. Ask a question only for a blocking decision; otherwise state defaults and proceed.
6. Do not invent assets, external API credentials, customer data, app store approvals, or runtime verification. Deployment, purchases, production writes and destructive changes require appropriate approval.

Output: user's outcome, chosen platform, execution approach, implemented deliverable/evidence or exact blocker.

View saved version →

---
name: improve-existing-project
description: Refactor, redesign, modernize or extend an existing app repository while preserving working behavior, user data and current project conventions.
---

# Improve Existing Project

1. Before edits, inspect current tree, git status, scripts, packages, app entry points and expected user behavior. Read `../../references/execution-model.md` and `../../references/testing-and-evidence.md`.
2. Record baseline tests/build and identify user-requested scope. Keep changes surgical; do not upgrade unrelated frameworks or redesign adjacent screens.
3. For visual changes, study existing branding and compare before/after. For functionality, identify contracts, state persistence and error cases. Add a regression test for each fixed bug where practical.
4. Use isolation/worktrees for agents with overlapping edits. Preserve unrelated files and uncommitted work; no automatic commits/pushes.
5. Run focused tests then broad tests as feasible; report exact diffs, before/after evidence, regressions and limits.

View saved version →

---
name: orchestrate-agents
description: Coordinate real specialist agents for complex web or mobile app builds, with task boundaries, independent review and transparent single-agent fallback when subagents are unavailable.
---

# Orchestrate Agents

1. Read `../../references/orchestration.md` and `../../references/execution-model.md`. A skill instruction is not an executable agent: verify actual host subagent support before delegating.
2. Lead decides smallest set of specialists: product analyst, design director, platform architect, implementer(s), security reviewer, visual/functional verifier. Avoid all agents for a simple bug fix.
3. Parallelize nonconflicting research/analysis. Freeze shared interfaces before parallel implementation. Assign separate modules/worktrees to writers and independent read-only review to reviewers.
4. Define for each specialist objective, allowed tools, files to touch, inputs, deliverable, deadlines/budget and approval boundaries. Use `../../templates/agent-handoff.md`.
5. Gather actual outputs, compare against source/test evidence, integrate and rerun. Do not invent 'agent consensus' or independent reviews when only one agent ran.
6. If subagents unavailable, execute roles sequentially with the same checklists and disclose that orchestration was simulated as a workflow, not parallel runtime.
7. Do not launch unapproved background jobs or use paid third-party services without authorization.

View saved version →

---
name: plan-product
description: Plan product architecture, platform and implementation milestones for a website, SaaS app, PWA, iOS/macOS, Android or cross-platform app before coding when planning is requested.
---

# Plan Product

Use for roadmap/spec/architecture requests, not as a substitute for a direct implementation request.

1. Identify target users, high-value task, requested platform(s), devices, offline needs, auth/data, integrations, performance and regulatory concerns. Resolve unknowns with reasonable assumptions except essential decisions.
2. Apply `../../references/platform-choice.md` and respect the existing stack, costs and skill constraints. Avoid defaulting every app to Next.js or every mobile app to React Native.
3. Model user journeys, screen/state inventory, data entities, API boundaries, security/trust boundaries and accessibility. Identify integrations that need credentials/permissions.
4. Define a minimal vertical slice and milestones with acceptance tests, risk register and decision points. Use `../../templates/product-brief.md`.
5. Decide whether to use real specialists according to `../../references/orchestration.md`. Separate independently executable tasks and gate production modifications.

Deliver: concise product brief, architecture diagram/table, stack rationale, screens, milestones, test strategy and unresolved blockers.

View saved version →

---
name: prepare-release
description: Prepare tested web/PWA/iOS/Android applications for deployment, store submission or handoff with accurate platform gates, security findings and user approvals.
---

# Prepare Release

1. Read `../../references/release-and-compliance.md` and `../../references/testing-and-evidence.md`. Determine actual target (preview, staging, production, TestFlight, App Store, Play Console, distributable ZIP).
2. Confirm app identifier, version, environments, signing, legal/privacy copy, runtime secrets, data retention, content policy and platform permissions. Do not invent organization identities, privacy policies or store screenshots.
3. Run available build/test/security/accessibility checks and attach evidence. Provide platform-specific blockers (macOS/Xcode for Apple signing, keystore/Android build tools for Android, HTTPS for PWAs, DNS for web).
4. Prepare deployment checklist, release notes, rollback/backup strategy and known issues. Ask for user approval before deploy, public sharing, purchases, external writes or app-store submission.
5. Return a verified release bundle where tools support it; otherwise a clearly labeled release-readiness report, not a false publication claim.

View saved version →

---
name: research-design-direction
description: Research contemporary UI/UX references and create a distinct product-appropriate visual direction from user links, screenshots, Figma, competitors or curated inspiration.
---

# Research Design Direction

Use when user asks to explore visual direction, redesign look-and-feel, research UX references, or when building from a new idea without a visual target.

1. Treat user-provided references and actual user constraints as primary. Review `../../references/curated-sources.md` and `../../references/reference-usage.md`. When web/browser access exists, inspect current sources, images, interactions and licenses; do not claim to have seen pages you could not load.
2. Identify product archetype (editor, dashboard, native utility, commerce, editorial, landing page), content density, audience and brand personality. Select 2–4 relevant inspirations by feature, not popularity.
3. Extract **design principles**, not copied pixels: hierarchy, grids, type scale, color role, motion purpose, navigation shape, data density and accessibility. Do not bulk-copy copyrighted screenshots/code or remove attribution/license constraints.
4. Reject gratuitous effects: identical rounded cards on every page, random purple gradients, fake content, motion without a purpose and unnecessary hero sections around tools.
5. Produce a visual-direction brief with 3–5 measurable anchors (e.g. dense table navigation, restrained contrasting typography) plus reference URLs, allowed patterns and prohibited mismatches. When user requests alternatives, present distinctly different options and ask them to choose; otherwise select and continue to implementation.
6. If images/mockups are required, use an actual supported image/design tool and report whether they were created; do not pretend they exist.

Read `../../references/design-quality.md`, `../../references/reference-usage.md`.

View saved version →

---
name: review-visual-ux
description: Audit an implemented app or compare a rendered web/mobile interface with reference screenshots or a design specification; produce evidence-linked fixes.
---

# Review Visual Ux

1. Read `../../references/design-quality.md`, `../../references/reference-usage.md` and `../../references/testing-and-evidence.md`.
2. Determine review target: user screenshot/Figma, existing app, or documented design spec. Capture actual render with available browser/simulator tools; if absent, perform a clearly labeled static code review only.
3. Inspect information architecture, visual hierarchy, spacing, type, color roles, content density, image treatment, component consistency, input states, responsive/adaptive behavior, accessibility and reduced motion.
4. Check at least: primary screen, one critical workflow state, small screen, large screen and one error/empty state where available. Record findings with severity, evidence, specific remedy and status.
5. Never report objective pixel fidelity without a source image and comparable render. Do not substitute a synthetic design-quality score for screenshot comparison.
6. If implementation changes are requested and authorized, apply bounded fixes, rerender and report before/after evidence. Preserve brand and existing structure unless redesign explicitly requested.

View saved version →

---
name: secure-app
description: Assess and harden app authentication, authorization, data privacy, secret handling, API calls, platform permissions and dependency risks.
---

# Secure App

1. Read `../../references/security-and-privacy.md`; identify assets, users, data classification, trust boundaries, external services and relevant abuse cases.
2. Check server-side authZ on every privileged operation (not only hidden UI controls), tenancy/data isolation, token lifecycle, least-privileged scopes, validated untrusted input, safe output, CSRF/CORS/XSS/SSRF risks as applicable and rate limits.
3. For web/PWA review service worker caching, authentication cookies, environment variables, upload handling, dependency advisories and disclosure of third-party telemetry.
4. For native/mobile review permissions, storage (Keychain/Keystore for secrets), deep links, exported components, ATS/network security, package identifiers, mobile signing secrets and release builds.
5. Never request users paste production secrets into chat or embed server tokens in client bundles. Before destructive writes, publishing, payment or external integration, check authorization and approvals.
6. Provide severity, reproduction or supporting evidence, minimal fix and residual risk; never call an unaudited project 'secure'.

View saved version →

---
name: test-app
description: Run reproducible functional, UI, accessibility, integration and platform-specific checks on websites, PWAs, native Apple, Android or cross-platform projects before handoff.
---

# Test App

1. Read `../../references/testing-and-evidence.md` and `../../templates/evidence-report.md`; inspect scripts and environment capabilities.
2. Select relevant test layers: formatting/typecheck, unit, API/integration, browser E2E, accessibility, visual screenshots, offline/PWA, Swift tests/Xcode UI tests, Android instrumentation/Compose UI tests.
3. Execute real commands where supported. Store command, platform, dependency versions (when relevant), exit code, count and evidence paths. Never infer passing tests from code review.
4. Distinguish PASS, FAIL, NOT RUN, BLOCKED and PARTIAL. For missing credentials or unavailable macOS simulator, mark appropriately and supply exact follow-up steps.
5. Review security separately; prohibit release claims if critical broken flows, data-loss risk, failed security gates or build failure remain. Do not assert that passing tests proves universal correctness.
6. Provide verification matrix, findings, fix/retest ledger, and honest release readiness statement.