Back to Mobile Development

Build macOS Apps

swiftmacosswiftuiappkitclaudecode
β˜… 4.8 (240)⭐ 1.9kπŸ“„ MITπŸ•’ 2026-04-01Source β†—

Install this skill

npx skills add glittercowboy/taches-cc-resources

Works across Claude Code, Cursor, Codex, Copilot & Antigravity

What this skill does

  • β€’Automates project scaffolding using Swift, SwiftUI, and AppKit
  • β€’Implements a mandatory verification loop for every code change
  • β€’Integrates standard CLI build and test tools like xcodebuild
  • β€’Facilitates complex tasks like notarization and App Store shipping
  • β€’Supports modular feature development through dedicated workflow files

When to use it

  • βœ“You need to start a new Swift-based desktop application from a terminal
  • βœ“You are troubleshooting specific crashes or performance bottlenecks in an existing app
  • βœ“You want to integrate unit and integration tests into your development loop
  • βœ“You need to prepare a finished app for release, including signing and notarization

When not to use it

  • βœ•You rely heavily on Xcode's visual interface builder or drag-and-drop design tools
  • βœ•You are building for iOS or watchOS rather than native macOS

How to invoke it

Example prompts that trigger this skill:

  • β€œHelp me start a new SwiftUI app for macOS.”
  • β€œDebug the crash occurring in my current project's build process.”
  • β€œAdd a new user authentication feature to my existing app.”
  • β€œWrite tests for the data transformation logic in my main module.”
  • β€œOptimize the performance of my current project.”
  • β€œGet my application ready for the App Store.”

Example workflow

  1. User initiates a task with a clear goal (e.g., 'Add a feature').
  2. Agent selects the corresponding workflow from the repository.
  3. Agent implements the code change in small, logical steps.
  4. Agent runs the verification loop, including builds and tests.
  5. Agent reports success or failure to the user with actionable proof.

Prerequisites

  • –macOS environment
  • –Swift toolchain installed
  • –Xcode command line tools

Pitfalls & limitations

  • !Requires strict adherence to the agent's reporting protocol to be effective
  • !Limited support for visual UI layout via drag-and-drop
  • !Requires high-quality test coverage to ensure stability during refactoring

FAQ

Does this tool replace Xcode entirely?
Yes, it replaces the Xcode GUI with CLI-driven workflows. You still rely on the underlying Apple tools, but you interact with them through text-based commands.
How do I verify the agent's work?
The agent provides proof of work, such as passing test results or terminal output. You should define your quality standards upfront so the agent can validate them.
What happens if I don't write tests?
The workflow encourages tests for logic and state changes. If you skip tests, you must manually verify the UI and features, which increases the risk of regressions.

How it compares

Unlike manual coding where you might batch several changes before testing, this skill enforces a strict 'Change, Verify, Report' cycle that ensures your app is always in a working state.

Source & trust

⭐ 1.9k starsπŸ“„ MITπŸ•’ Updated 2026-04-01πŸ›‘ runs-shell

From the source: β€œ<essential_principles> ## How We Work **The user is the product owner. Claude is the developer.** The user does not write code. The user does not read code. The user describes what they want and judges whether the result is acceptable. Claude implements, verifies, and reports outcomes. ### 1. Prove,…”

View the full SKILL.md source

<essential_principles>
## How We Work

**The user is the product owner. Claude is the developer.**

The user does not write code. The user does not read code. The user describes what they want and judges whether the result is acceptable. Claude implements, verifies, and reports outcomes.

### 1. Prove, Don't Promise

Never say "this should work." Prove it:
```bash
xcodebuild build 2>&1 | xcsift  # Build passes
xcodebuild test                  # Tests pass
open .../App.app                 # App launches
```
If you didn't run it, you don't know it works.

### 2. Tests for Correctness, Eyes for Quality

| Question | How to Answer |
|----------|---------------|
| Does the logic work? | Write test, see it pass |
| Does it look right? | Launch app, user looks at it |
| Does it feel right? | User uses it |
| Does it crash? | Test + launch |
| Is it fast enough? | Profiler |

Tests verify *correctness*. The user verifies *desirability*.

### 3. Report Outcomes, Not Code

**Bad:** "I refactored DataService to use async/await with weak self capture"
**Good:** "Fixed the memory leak. `leaks` now shows 0 leaks. App tested stable for 5 minutes."

The user doesn't care what you changed. The user cares what's different.

### 4. Small Steps, Always Verified

```
Change β†’ Verify β†’ Report β†’ Next change
```

Never batch up work. Never say "I made several changes." Each change is verified before the next. If something breaks, you know exactly what caused it.

### 5. Ask Before, Not After

Unclear requirement? Ask now.
Multiple valid approaches? Ask which.
Scope creep? Ask if wanted.
Big refactor needed? Ask permission.

Wrong: Build for 30 minutes, then "is this what you wanted?"
Right: "Before I start, does X mean Y or Z?"

### 6. Always Leave It Working

Every stopping point = working state. Tests pass, app launches, changes committed. The user can walk away anytime and come back to something that works.
</essential_principles>

<intake>
**Ask the user:**

What would you like to do?
1. Build a new app
2. Debug an existing app
3. Add a feature
4. Write/run tests
5. Optimize performance
6. Ship/release
7. Something else

**Then read the matching workflow from `workflows/` and follow it.**
</intake>

<routing>
| Response | Workflow |
|----------|----------|
| 1, "new", "create", "build", "start" | `workflows/build-new-app.md` |
| 2, "broken", "fix", "debug", "crash", "bug" | `workflows/debug-app.md` |
| 3, "add", "feature", "implement", "change" | `workflows/add-feature.md` |
| 4, "test", "tests", "TDD", "coverage" | `workflows/write-tests.md` |
| 5, "slow", "optimize", "performance", "fast" | `workflows/optimize-performance.md` |
| 6, "ship", "release", "notarize", "App Store" | `workflows/ship-app.md` |
| 7, other | Clarify, then select workflow or references |
</routing>

<verification_loop>
## After Every Change

```bash
# 1. Does it build?
xcodebuild -scheme AppName build 2>&1 | xcsift

# 2. Do tests pass?
xcodebuild -scheme AppName test

# 3. Does it launch? (if UI changed)
open ./build/Build/Products/Debug/AppName.app
```

Report to the user:
- "Build: βœ“"
- "Tests: 12 pass, 0 fail"
- "App launches, ready for you to check [specific thing]"
</verification_loop>

<when_to_test>
## Testing Decision

**Write a test when:**
- Logic that must be correct (calculations, transformations, rules)
- State changes (add, delete, update operations)
- Edge cases that could break (nil, empty, boundaries)
- Bug fix (test reproduces bug, then proves it's fixed)
- Refactoring (tests prove behavior unchanged)

**Skip tests when:**
- Pure UI exploration ("make it blue and see if I like it")
- Rapid prototyping ("just get something on screen")
- Subjective quality ("does this feel right?")
- One-off verification (launch and check manually)

**The principle:** Tests let the user verify correctness without reading code. If the user needs to verify it works, and it's not purely visual, write a test.
</when_to_test>

<reference_index>
## Domain Knowledge

All in `references/`:

**Architecture:** app-architecture, swiftui-patterns, appkit-integration, concurrency-patterns
**Data:** data-persistence, networking
**App Types:** document-apps, shoebox-apps, menu-bar-apps
**System:** system-apis, app-extensions
**Development:** project-scaffolding, cli-workflow, cli-observability, testing-tdd, testing-debugging
**Polish:** design-system, macos-polish, security-code-signing
</reference_index>

<workflows_index>
## Workflows

All in `workflows/`:

| File | Purpose |
|------|---------|
| build-new-app.md | Create new app from scratch |
| debug-app.md | Find and fix bugs |
| add-feature.md | Add to existing app |
| write-tests.md | Write and run tests |
| optimize-performance.md | Profile and speed up |
| ship-app.md | Sign, notarize, distribute |
</workflows_index>

Quoted from glittercowboy/taches-cc-resources for reference β€” see the original for the authoritative, latest version.

πŸ“„ Full skill instructions β€” original source: glittercowboy/taches-cc-resources
This skill provides a structured framework for building native macOS applications using Swift, SwiftUI, and AppKit directly through your CLI. It replaces the traditional Xcode GUI flow with a rigorous, test-driven approach that prioritizes incremental validation over long-form coding. By acting as the developer while the user remains the product owner, the agent ensures that every change is verified via build passes and test execution before reporting back. The system is built for speed and clarity, relying on specific workflows for everything from architectural scaffolding to final App Store notarization. It is ideal for developers who prefer a keyboard-centric workflow and want to maintain a constant, shippable state throughout the entire application lifecycle, from initial prototype to final production release.

How to Use This Skill Unit

Option A: Project-Specific (Recommended)

  1. Click "Download" above
  2. In your project, create the directory: .agent/skills/macos-apps/
  3. Save the file as SKILL.md
  4. The agent will automatically discover the skill based on its description.

Option B: Global Installation (All Agents)

Save the file to these locations to make it available across all projects:

  • Claude Code: ~/.claude/skills/glittercowboy/taches-cc-resources/macos-apps/SKILL.md
  • Cursor: ~/.cursor/skills/glittercowboy/taches-cc-resources/macos-apps/SKILL.md
  • Antigravity: ~/.gemini/antigravity/skills/glittercowboy/taches-cc-resources/macos-apps/SKILL.md

πŸš€ Install with CLI:
npx skills add glittercowboy/taches-cc-resources

Read the Master Guide: Mastering Agent Skills β†’

Recommended Rules

View more rules β†’

Recommended Workflows

View more workflows β†’

Recommended MCP Servers

View more MCP servers β†’

Take It Further

Maximize your productivity with these powerful resources

πŸ“‹

Define Your Standards

Set up coding standards to ensure this workflow produces consistent, high-quality results.

Browse Rules Library
πŸ“–

Master Workflows

Learn how to create custom workflows, use Turbo Mode, and build your automation library.

Complete Guide

How to use this Skill in Claude Code & Cursor

For Claude Code (CLI)

To use this skill in Claude Code, copy the rule content into your project's custom instructions or follow our Add-Skill CLI guide. This ensures Claude follows your standards during every code generation.

For Cursor & Windsurf

For Cursor or Windsurf, individual skills are best used in the "Rules for AI" section. This specific unit helps the agent avoid mobile development issues, leading to cleaner, more efficient code.

Why the skill format matters: the standardized Agent Skills format lets your AI agent load detailed instructions only when they are relevant, keeping your prompt clean while improving results.

Source & attribution

This skill is categorized under Mobile Development and is published by glittercowboy, maintained in glittercowboy/taches-cc-resources.

← Browse All Agent Skills
Sponsored AI assistant. Recommendations may be paid.