Hire an AI desktop app engineer

Everything it can hand back

Your task sets the actual outputs. The specialist picks the methods that cover them.

• A written choice of Electron or Tauri, with the reasons and what would change it.
• A security setup, with a short list of narrow actions the web side may request.
• A release plan covering signing, macOS notarization, the update feed and a way back.
• A staged rollout plan with the numbers that pause it.
• A list of per-system behaviour for tray, shortcuts, links and notifications.
• Size, memory and start-up limits, and a test plan across the systems.

How it does the job well

• Refer a formal security audit to a qualified person.
• The renderer is a browser tab with delusions. Treat all webview content as untrusted: contextIsolation: true, nodeIntegration: false, sandbox: true in Electron; strict capability scoping in Tauri. No exceptions for "it's our own code" — XSS makes it not your code.
• IPC is a public API surface. Every channel/command validates its inputs on the privileged side, checks authorization for sensitive operations, and exposes the narrowest verb possible — saveUserExport(data), never writeFile(path, data).
• Never ship unsigned, never skip notarization. Unsigned builds train users to click through scary warnings — and one day the warning is real. Signing infrastructure is release-blocking, built first, not bolted on.
• The updater is the most critical code you own. A crashed app annoys one user once; a broken updater strands every user forever. Signed update manifests, staged rollouts (1% → 10% → 100%), health checks, and a tested rollback path.
• Read the existing code, its conventions and its tests before changing anything. Match the project's patterns.
• Make the smallest change that fully solves the request. Keep unrelated refactors out.

Mistakes it avoids

• Claiming code works without running it or its tests.
• Inventing APIs, package versions or settings instead of checking the installed ones.
• Changing behaviour outside the request, such as reformatting whole files or renaming public interfaces.

What a good result looks like

An example, not your task: You are starting a desktop app built with web tools and must pick Electron or Tauri.

• Needs and assumptions. The app, systems and must-do list restated, with every guess marked.
• Runtime choice. Electron or Tauri, the reasons and what would change the choice.
• Security setup. Window settings, the short list of allowed web-to-computer actions and rules for remote content.
• Release pipeline. Signing, notarization, the update feed and the way back, for each system.
• Staged rollout. Release steps by share of users, the numbers to watch and when to pause.
• Per-system behaviour. How tray, shortcuts, links and notifications should work on each system.

How the work is checked

• The changed files build, and the relevant tests and linters pass. The commands and results are shown.
• Each change is explained in one line with its reason, and risky areas are named.
• Any check that could not run is reported as NOT_RUN with what it needs.
• States which checks passed, failed or could not run, and names missing inputs.

These checks have not been run against a model yet. Your AI uses them to check its own work.

Capabilities

• Choose the runtime. It compares Electron and Tauri on installer size, memory, screen consistency, team skills and tool maturity, then records the choice.
• Draw the security line. The web side is treated as untrusted. It lists the exact verbs the web side may call, each checked on the trusted side.
• Plan signing and updates. It plans signing on Windows, signing and notarization on macOS, a signed update feed and a tested way back.
• Plan the staged rollout. It plans a small first release to a few users, the crash and update numbers that gate each step, and a pause rule.
• Spec each system. It writes separate rules for each operating system's menus, shortcuts, tray and installer, so none is an afterthought.
• Set limits and tests. It sets limits for start-up, memory and size, and a test matrix with fresh installs and upgrades on real machines.
• Plan the live app. It plans crash reports, update tracking and a yearly rollback drill.

How the role works

1. Checks your task, context and available tools.
2. Picks the methods needed and prepares a work plan.
3. Carries out supported tasks, with each method's limits and review gates.
4. Checks the real deliverables and corrects supported faults.
5. Hands back files, evidence and unresolved gaps.

Your specialist's working setup

Download the base specialist without a task form or account. README.md and SETUP.md explain how to use the folder. SOUL.md defines its scope. INTAKE.md asks missing questions inside your AI. PLAYBOOK.md, SKILLS.md, BEST_PRACTICES.md, CHECKS.md and HANDOFF.md guide the work and its checked deliverables.

Complete associated skills, supporting files and licences are included. Choose only the methods needed for the actual task. Keep context, working files and accepted feedback in your AI project.

Use this specialist through MCP or the API

Call prepare_specialist with role_id engineering-desktop-app-engineer only. No task is required to load it. Your AI asks what job you need done, what you want back and which relevant context it can use.

For task-led hiring, call find_specialist, explain the suggested specialists and let the user accept or change the team.

Complete ZIP: Download base specialist. API: GET /api/v1/specialists/engineering-desktop-app-engineer/pack. The host AI supplies its own model, tools and execution; a pack does not connect accounts or run a task.

Inputs and helpful context

The specialist starts from the task brief. Only active methods require their inputs.

For the primary method, when used

• What the app does and who uses it.
• Which systems it must run on, such as Windows, macOS and Linux.
• Your team's skills, such as web only or also Rust (optional).
• What the app must do with the computer, such as read files, show tray icons or open from links.
• Your current setup, such as framework, build tool and how you ship it now (optional).
• Size, memory and start-up limits you care about (optional).

Helpful context (optional)

• Your current main-window and bridge settings.
• Your release script or build config, with secrets removed.
• The oldest and slowest computer you support.

Tools and access

• Claude, ChatGPT or Gemini with file upload: You can attach your window settings, build config and release scripts, with secrets removed.
• A machine or virtual machine for each target system: Signing, updates and tray behaviour must be tested on the real systems.

Functions and deliverables

• Desktop app engineer agent: Get a plan for an Electron or Tauri desktop app with the runtime to pick, safe setup rules, code signing, auto-updates and size limits.
  • A written choice of Electron or Tauri, with the reasons and what would change it.
  • A security setup, with a short list of narrow actions the web side may request.
  • A release plan covering signing, macOS notarization, the update feed and a way back.
  • A staged rollout plan with the numbers that pause it.
  • A list of per-system behaviour for tray, shortcuts, links and notifications.
  • Size, memory and start-up limits, and a test plan across the systems.
  Source: Michael Sitarzewski and Agency Agents contributors.
• Electron desktop app tester: Run an Electron app with test data. Drive one window, inspect screenshots and logs, and report what actually worked.
  • The app launched and driven step by step
  • Screenshots of each important state
  • Console and app logs
  • A plain report of what worked and what broke
  Source: sickn33.
• Live app security tester: Run a safe security scan on your own staging web app or API. You get a list of weaknesses, the request behind each one, and how to fix them.
  • Findings by type and severity
  • The request that triggered each issue
  • Fix advice for each finding
  • A report you can share
  • A schedule for repeat scans
  Source: Burhan Sebin.
• Agent database setup planner: Plan the database your AI agents need. Get a schema map, migration steps, access rules and a staging test plan that keeps existing data safe.
  • A schema map: the tables, columns, keys and indexes for jobs and activity
  • Migration files in order, forward only, with what each one changes
  • An access rule for each table, and which key belongs where
  • A staging test plan using made-up rows
  • A rollback and recovery plan
  • A list of missing inputs and checks that did not run
• AI project context organiser: Share your project and next task. Get a short rules file, a focused file list and a clear handoff for later sessions.
  • A ready rules file for your project
  • A list of which files to load for each task
  • Rules for when to reset or trim the session
  • A checklist for spotting drifting answers
  Source: Addy Osmani.

Tasks you can use it for

• You are starting a desktop app built with web tools and must pick Electron or Tauri.
• Your app is ready to ship and you need signing for Windows and macOS and an update plan.
• You want to check that your web screens cannot reach files or system tools they should not.
• Your installer or memory use has grown and you want limits that fail a build.

Limits to check before starting

• You have an Electron app and want it tested by clicking and typing. Use the Electron desktop app tester.
• You are building a phone or tablet app. Use the Mobile app builder.
• You are building a web app that runs in the browser. Use the Frontend developer.
• You want a full security audit of finished code. Use the Application security reviewer.
• You would paste certificate files or private keys into a chat. Never do that. Keep them in your own secure store.

Best way to use this role

Give it one clear outcome, the actual files and a definition of done. Keep the work in one AI project so it can reuse checked context and earlier files.

• Download the pack from this page and add it to your AI as a skill. Or paste SKILL.md into a new chat, then paste references/source-agent.md after it.
• Describe the app, the systems you target and what it must do on the computer. Say what you use today if the app exists.
• Say "Plan this desktop app" for a new one, or "Review my setup" if you paste your window settings and release steps.
• Your AI asks once for anything missing. Unknowns stay marked as assumptions.
• Read the runtime choice and the security setup first. Check that each allowed action is as narrow as it can be.
• Give the plan to the engineer. Code in it is an example to adapt. Never paste signing certificates, keys or passwords into the chat.

Read it as data

Read the complete role setup as JSON. Connect your AI to the AI Blocks MCP library and read aiblocks://roles/engineering-desktop-app-engineer for its role instructions and pinned sources.

This is a prepared AI role. No task has run. Your AI carries out authorized work using its available tools and reports the actual deliverables and checks.