glittercowboyglittercowboy/taches-cc-prompts/skills/expertise/macos-apps/SKILL.md

build-macos-apps

Skill2k starsChanged 12 months agoMITView on GitHub

Build professional native macOS apps in Swift with SwiftUI and AppKit. Full lifecycle - build, debug, test, optimize, ship. CLI-only, no Xcode.

2 other projects use a version of this.

Other versions2 projects use a version of this.
Word for word · 2
glittercowboy/taches-cc-resources★ 2k100% same
mosif16/codex-Skills★ 18100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository11 other files it gives its agents.
- create-agent-skillsSkill
- create-hooksSkill
- create-mcp-serversSkill
- create-meta-promptsSkill
- create-plansSkill
- create-slash-commandsSkill
- create-subagentsSkill
- debug-like-expertSkill
- build-iphone-appsSkill
- setup-ralphSkill
- the-pirate-baySkill

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Never say "this should work." Prove it:
line 15
Distinctive:
If you didn't run it, you don't know it works.
line 21
Distinctive:
Never batch up work. Never say "I made several changes." Each change is verified before the next.
line 48
Distinctive:
Every stopping point = working state.
line 62
Distinctive:
App Types: document-apps, shoebox-apps, menu-bar-apps
line 138

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

<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:

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?

Build a new app
Debug an existing app
Add a feature
Write/run tests
Optimize performance
Ship/release
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

# 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>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free