// Build professional native iPhone apps in Swift with SwiftUI and UIKit. Full lifecycle - build, debug, test, optimize, ship. CLI-only, no Xcode. Targets iOS 26 with iOS 18 compatibility.
| name | build-iphone-apps |
| description | Build professional native iPhone apps in Swift with SwiftUI and UIKit. Full lifecycle - build, debug, test, optimize, ship. CLI-only, no Xcode. Targets iOS 26 with iOS 18 compatibility. |
<essential_principles>
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.
Never say "this should work." Prove it:
xcodebuild -destination 'platform=iOS Simulator,name=iPhone 16' build 2>&1 | xcsift
xcodebuild test -destination 'platform=iOS Simulator,name=iPhone 16'
xcrun simctl boot "iPhone 16" && xcrun simctl launch booted com.app.bundle
If you didn't run it, you don't know it works.
| Question | How to Answer |
|---|---|
| Does the logic work? | Write test, see it pass |
| Does it look right? | Launch in simulator, 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.
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.
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.
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?"
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>
**Ask the user:**What would you like to do?
Then read the matching workflow from workflows/ and follow it.
<verification_loop>
# 1. Does it build?
xcodebuild -scheme AppName -destination 'platform=iOS Simulator,name=iPhone 16' build 2>&1 | xcsift
# 2. Do tests pass?
xcodebuild -scheme AppName -destination 'platform=iOS Simulator,name=iPhone 16' test
# 3. Does it launch? (if UI changed)
xcrun simctl boot "iPhone 16" 2>/dev/null || true
xcrun simctl install booted ./build/Build/Products/Debug-iphonesimulator/AppName.app
xcrun simctl launch booted com.company.AppName
Report to the user:
<when_to_test>
Write a test when:
Skip tests when:
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>
All in references/:
Architecture: app-architecture, swiftui-patterns, navigation-patterns Data: data-persistence, networking Platform Features: push-notifications, storekit, background-tasks Quality: polish-and-ux, accessibility, performance Assets & Security: app-icons, security, app-store Development: project-scaffolding, cli-workflow, cli-observability, testing, ci-cd </reference_index>
<workflows_index>
All in workflows/:
| File | Purpose |
|---|---|
| build-new-app.md | Create new iOS 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 | TestFlight, App Store submission |
| </workflows_index> |
Search The Pirate Bay for torrents and extract magnet links via the apibay.org JSON API. Use when asked to "find a torrent", "search pirate bay", "get a magnet link", "download torrent", "find seeders", "top torrents", or any torrent search task. Can operate via CLI tool or direct API calls.
Set up and configure Geoffrey Huntley's original Ralph Wiggum autonomous coding loop in any directory with proper structure, prompts, and backpressure.
Create Model Context Protocol (MCP) servers that expose tools, resources, and prompts to Claude. Use when building custom integrations, APIs, data sources, or any server that Claude should interact with via the MCP protocol. Supports both TypeScript and Python implementations.
Create hierarchical project plans optimized for solo agentic development. Use when planning projects, phases, or tasks that Claude will execute. Produces Claude-executable plans with verification criteria, not enterprise documentation. Handles briefs, roadmaps, phase plans, and context handoffs.
Expert guidance for creating, writing, building, and refining Claude Code Skills. Use when working with SKILL.md files, authoring new skills, improving existing skills, or understanding skill structure and best practices.
Create optimized prompts for Claude-to-Claude pipelines with research, planning, and execution stages. Use when building prompts that produce outputs for other prompts to consume, or when running multi-stage workflows (research -> plan -> implement).