native-feel-skill: an Agent Skill for desktop apps that feel native

The trade-off native-feel-skill refuses to accept

Cross-platform desktop development and near-native performance usually pull in opposite directions. A single UI codebase buys you one team and one release train; a native shell buys you launch time, memory headroom and the small behavioural details users read as quality. The README states the goal as refusing that trade-off, and the repository is the argument for how: eight architectural tenets, a four-layer architecture, a WebKit and WebView2 survival guide, and a 75-item ship audit. The target reader is named directly: architects, tech leads and engineers building a desktop app that runs on macOS and Windows from one UI codebase, launches in under 500 ms, stays under 500 MB resident, supports a TypeScript plugin ecosystem, and can share performance-critical code with iOS and a server backend. That is a narrow audience on purpose. If you are shipping an internal tool with twelve users, the audit will feel like ceremony. If a designer has told you your app does not pass for a real Mac app, you are the intended reader.

Four layers, one IPC schema, and codegen on every side

The architecture the skill teaches has four layers. A native shell written in Swift/AppKit on macOS and C#/WPF on Windows sits on top. Below it runs the system WebView, WKWebView and WebView2 respectively, hosting React and TypeScript shared 1:1 across platforms. Below that is a single long-lived Node backend process, and at the bottom a Rust core bridged through UniFFI so the same code can be shared with iOS and a server. The layers are joined by one IPC schema with code generation for all sides. The README's own framing is that the IPC contract is the expensive-to-get-wrong decision, ahead of the WebView survival flags and memory hygiene. That ordering is the most useful claim in the document. A schema you get wrong means rebuilding every bridge later, under pressure, while the app is shipping. The document also quotes Raycast's position on the split: "We're not a web app with some native hooks sprinkled on top. We're a native app that uses web for its UI." The distinction is not rhetorical. It determines whether the web layer owns window chrome, menus and modal presentation, or only the content inside a native frame.

Installing native-feel-skill with npx skills add

The README gives two install paths. The first uses the skills CLI from vercel-labs and works with any compatible agent. The -g flag installs at user level so every project on the machine picks the skill up.

npx skills add yetone/native-feel-skill -g

The second path is a prompt you paste into your agent. It tells the agent to clone the repository into your user-level skills directory under the name native-feel-cross-platform-desktop/, and the README gives ~/.claude/skills/ as the example location for Claude Code. After cloning, the agent is asked to verify that SKILL.md plus the references/ and checklists/ subdirectories are present, and to confirm the install path. That verification step matters because the repository has no build and no package manifest: the top level is .gitignore, LICENSE, README.md, SKILL.md, checklists/ and references/. If those two subdirectories are missing, the skill has nothing to cite.

Once installed, the README says the skill activates automatically when a conversation touches cross-platform desktop architecture, WebView quirks, or making a UI feel native. A first real use is the audit. Point your agent at an existing Electron app and ask why it feels web-y; the documented response routes to checklists/ship-readiness.md and names the items Electron apps fail most often, including cursor:pointer on rows (item 21), web-style modal overlays instead of native sheets (item 19), a hardcoded brand accent instead of the system accent (item 33), page fade transitions (item 40), an opaque window background instead of platform material (item 31), and the WebKit context menu still firing (item 23). The README describes each as a five-to-thirty-minute fix. What you should see is a short list of specific items with file-level guidance, not a rewrite plan.

The decision tree rules the stack out before you start

The most valuable file in the repository may be checklists/decision-tree.md, because it is the one that tells you not to use the architecture. The README's greenfield example runs four questions before any layer is drawn. A cold-start budget under 100 ms means build native instead. A memory floor under 150 MB means build native instead. An extension ecosystem means you need the Node layer. A runway under three months means start on Electron. Those are hard boundaries, and they cut against the skill's own thesis. If your product needs to appear instantly from a cold start, no amount of WebView prewarming will get you there, and the document says so. Read the tree first. Teams that skip it and adopt the four-layer stack because the architecture diagram looks right will discover the constraint later, when the diagram is already load-bearing.

Where the WebView layer breaks, and what the skill does not fix

The README points WebView problems at references/03-webview-survival.md and names two likely causes for a WKWebView that flickers when hidden and re-shown: throttling and startup flicker. It also mentions the survival flags the architecture depends on, including occlusion off, alpha-prewarm, _doAfterNextPresentationUpdate and font prewarming. Those are real mechanisms, and they are also the clearest limitation of the whole approach. Each flag is a workaround for behaviour in a component you do not control. A flag named with a leading underscore is private API by convention, and the README gives no compatibility statement for it. Nothing in the repository promises these flags survive an OS update. The same applies to the memory guidance: references/05-memory-truths.md is described as covering six common Activity Monitor mistakes and what to actually measure, which is a signal that the naive number is misleading, not that a target is guaranteed. There is also no tooling here. The 75-item audit is a checklist a human or an agent walks through, not a linter that fails a build. If you want automated enforcement of native conventions, this repository does not provide it and the README does not claim otherwise.

Tauri, Electron and the difference in where the seam sits

The obvious alternative for a single-codebase desktop app is Tauri, which pairs a Rust core with the system WebView and leaves the UI to your choice of web framework. The structural difference is the Node layer. native-feel-skill's four-layer stack keeps a long-lived Node process specifically so a TypeScript plugin ecosystem can run inside the app, which is the shape Raycast ships. Tauri has no equivalent runtime by default; extension-style hosting is something you add. Electron sits at the other end: it bundles Chromium rather than using the system WebView, so rendering is consistent across platforms and the WebKit-specific survival guide in this repository does not apply. The cost is the one the README's decision tree encodes, since a bundled browser engine makes a sub-100 ms cold start and a sub-150 MB memory floor difficult to reach. The honest summary is that native-feel-skill is not a competitor to either. It is a set of constraints you apply on top of whichever stack you pick, and its audit is most immediately useful to teams already on Electron who want to know how far the polish can go before the ceiling.

Maintenance, licence and what the repository actually contains

The repository is MIT licensed, so you can copy the tenets, the checklists and the reference files into internal documentation and modify them. The README does not discuss attribution requirements beyond the licence file, and nothing here is legal advice; read LICENSE if you plan to redistribute the content. On maintenance, the last push was on 2026-05-30, which is roughly three and a half months before the date of writing. The repository is not archived. There are no releases, so upgrade cost is not a versioned concern: you pull the branch and re-read SKILL.md, references/ and checklists/. The practical risk is not a breaking change but drift. The skill is grounded in reverse engineering of a specific shipping binary, Raycast Beta.app, and in Raycast's 2.0 technical deep-dive. When that app or that write-up moves, the reference files describe the older state, and the README gives no process for tracking it. Treat the content as a snapshot of a design, not as a specification that upstream maintains for you.

Editorial conclusion

Adopt native-feel-skill if you are an architect or tech lead choosing a stack for a macOS plus Windows desktop app where native feel is a stated product requirement, or if you already ship Electron, Tauri or a web-wrapped app and need a checklist to find the web-y tells. Do not adopt it expecting a library, a build system or an automated linter: the repository is SKILL.md plus references/ and checklists/, and every fix it recommends is manual. Before you rely on it, verify that your agent actually reads the install path you chose, and read checklists/decision-tree.md first, because the README's own examples rule the four-layer stack out for cold-start budgets under 100 ms, memory floors under 150 MB, and runways under three months.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. yetone/native-feel-skill on GitHub