DesktopGo: Skill for Claude Code

Maintain Modular Code

Apply this workflow to every code change. Optimize for clear ownership and stable boundaries, not merely fewer lines or more files.

Project Launch Ownership

• Never start the DesktopGo application, a Tauri development process, a Vite development or preview server, a browser session, or a native application window for testing.
• Do not run pnpm dev, pnpm tauri dev, vite, vite preview, tauri dev, cargo run, or any equivalent command that launches the project or keeps a project process running.
• The user exclusively owns starting and stopping DesktopGo project processes, including processes used for runtime and visual verification.
• Verify changes with unit tests, linting, builds, static inspection, and runtime evidence supplied by the user.
• If verification requires launching DesktopGo or one of its servers, report that limitation and ask the user to run it.
• Inspect an already-running DesktopGo instance only when the user explicitly requests it; never restart, replace, or stop the user's process as part of ordinary verification.

1. Inspect Before Designing

• Read repository instructions and the relevant neighboring modules.
• Measure every file likely to change. Treat an oversized file as refactoring pressure, not permission to add more responsibilities.
• Search before creating a component, hook, helper, type, store action, domain rule, service, or Rust module. Use rg by name, behavior, visible copy, props, and imported APIs.
• Identify the change's responsibilities: rendering, interaction orchestration, domain policy, state ownership, persistence, IPC, or platform integration.
• Read references/component-reuse.md whenever UI, hooks, shared types, or utilities are involved.
• Read references/architecture-boundaries.md whenever a change crosses modules, stores, IPC, persistence, or platform code.

2. Choose Boundaries Before Editing

• Keep one primary reason to change per module.
• Keep views focused on rendering and user interaction.
• Put React lifecycle and workflow coordination in hooks or feature controllers.
• Put deterministic business decisions and transformations in pure domain modules.
• Put storage, network, Tauri IPC, filesystem, and operating-system access behind services or adapters.
• Keep shared state minimal. Derive values instead of duplicating them in stores.
• Preserve dependency direction; never make a lower-level or shared module import a feature view to save time.
• Prefer a small cohesive extraction made for the current behavior over a speculative framework.