buildanything 1.7.0 → 1.8.0

package/skills/ios/ios-bootstrap/references/xcode-mcp-config.md

@@ -0,0 +1,29 @@
+# XcodeBuildMCP — MCP config snippet
+
+Add the following under the `mcpServers` object in `~/.claude.json` (user-wide) or `./.mcp.json` (project-scoped).
+
+```json
+{
+  "mcpServers": {
+    "xcodebuildmcp": {
+      "command": "npx",
+      "args": ["-y", "xcodebuildmcp@latest"]
+    }
+  }
+}
+```
+
+## What it gives you
+- Discover schemes, targets, and destinations from `.xcodeproj` / `.xcworkspace`
+- Build, clean, archive via `xcodebuild` with structured output
+- Boot, shutdown, and install apps on simulators
+- Toggle target capabilities (Push, HealthKit, App Groups, iCloud, Sign in with Apple)
+- Read and patch Info.plist / entitlements plists safely
+
+## Verification
+After adding and restarting Claude Code, confirm tools prefixed `mcp__xcodebuildmcp__` appear in the tool list.
+
+## Troubleshooting
+- **`npx` missing** — install Node 20+ (`brew install node`).
+- **Server never initializes** — check Claude Code logs; usually first-run `npx` download stalled behind a proxy.
+- **Multiple Xcode installs** — run `sudo xcode-select -s /Applications/Xcode.app` so the MCP picks up 26.3.

package/skills/ios/ios-debugger-agent/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Thomas Ricouard
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/ios/ios-debugger-agent/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: ios-debugger-agent
+description: Use XcodeBuildMCP to build, run, launch, and debug the current iOS project on a booted simulator. Trigger when asked to run an iOS app, interact with the simulator UI, inspect on-screen state, capture logs/console output, or diagnose runtime behavior using XcodeBuildMCP tools.
+---
+
+# iOS Debugger Agent
+
+> scope=inner dev-loop; Maestro owns E2E
+
+## Overview
+Use XcodeBuildMCP to build and run the current project scheme on a booted iOS simulator, interact with the UI, and capture logs. Prefer the MCP tools for simulator control, logs, and view inspection.
+
+## Core Workflow
+Follow this sequence unless the user asks for a narrower action.
+
+### 1) Discover the booted simulator
+- Call `mcp__XcodeBuildMCP__list_sims` and select the simulator with state `Booted`.
+- If none are booted, ask the user to boot one (do not boot automatically unless asked).
+
+### 2) Set session defaults
+- Call `mcp__XcodeBuildMCP__session-set-defaults` with:
+  - `projectPath` or `workspacePath` (whichever the repo uses)
+  - `scheme` for the current app
+  - `simulatorId` from the booted device
+  - Optional: `configuration: "Debug"`, `useLatestOS: true`
+
+### 3) Build + run (when requested)
+- Call `mcp__XcodeBuildMCP__build_run_sim`.
+- **If the build fails**, check the error output and retry (optionally with `preferXcodebuild: true`) or escalate to the user before attempting any UI interaction.
+- **After a successful build**, verify the app launched by calling `mcp__XcodeBuildMCP__describe_ui` or `mcp__XcodeBuildMCP__screenshot` before proceeding to UI interaction.
+- If the app is already built and only launch is requested, use `mcp__XcodeBuildMCP__launch_app_sim`.
+- If bundle id is unknown:
+  1) `mcp__XcodeBuildMCP__get_sim_app_path`
+  2) `mcp__XcodeBuildMCP__get_app_bundle_id`
+
+## UI Interaction & Debugging
+Use these when asked to inspect or interact with the running app.
+
+- **Describe UI**: `mcp__XcodeBuildMCP__describe_ui` before tapping or swiping.
+- **Tap**: `mcp__XcodeBuildMCP__tap` (prefer `id` or `label`; use coordinates only if needed).
+- **Type**: `mcp__XcodeBuildMCP__type_text` after focusing a field.
+- **Gestures**: `mcp__XcodeBuildMCP__gesture` for common scrolls and edge swipes.
+- **Screenshot**: `mcp__XcodeBuildMCP__screenshot` for visual confirmation.
+
+## Logs & Console Output
+- Start logs: `mcp__XcodeBuildMCP__start_sim_log_cap` with the app bundle id.
+- Stop logs: `mcp__XcodeBuildMCP__stop_sim_log_cap` and summarize important lines.
+- For console output, set `captureConsole: true` and relaunch if required.
+
+## Troubleshooting
+- If build fails, ask whether to retry with `preferXcodebuild: true`.
+- If the wrong app launches, confirm the scheme and bundle id.
+- If UI elements are not hittable, re-run `describe_ui` after layout changes.
+
+
+---
+
+Vendored from: https://github.com/Dimillian/Skills/tree/main/ios-debugger-agent

package/skills/ios/ios-debugger-agent/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "iOS Debugger Agent"
+  short_description: "Debug iOS apps on Simulator"
+  default_prompt: "Use $ios-debugger-agent to build, launch, and inspect the current iOS app on the booted simulator."

package/skills/ios/ios-entitlements-generator/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: ios-entitlements-generator
+description: Generates a .entitlements plist from ios_features flags and syncs Xcode capability toggles via XcodeBuildMCP. Delegates the capability→entitlement table to protocols/ios-frameworks-map.md §4. Use during Phase 4 Foundation.
+version: 0.2.0
+status: ready
+---
+
+# iOS Entitlements Generator (Phase 4)
+
+## Purpose
+Turns the `ios_features` checklist in `.build-state.md` into a correct `.entitlements` plist and syncs the Xcode capability UI. Removes the foot-gun of hand-editing entitlement keys.
+
+## Authoritative mapping source
+**This skill does NOT maintain its own capability→entitlement table.** It DELEGATES to `protocols/ios-frameworks-map.md` **§4 Entitlement Mapping**. Always consult that table at generation time — it is the single source of truth and is kept in sync with iOS SDK releases.
+
+## When this fires
+- Phase 4 Foundation, after architecture decisions finalized
+- A new capability is added mid-project (Push, App Groups, CloudKit, …)
+- Pre-archive audit to confirm entitlements match used capabilities
+
+## Inputs
+- `ios_features` object from `docs/plans/.build-state.md` — boolean flags like `push`, `cloudKit`, `healthKit`, `appGroups`, `signInWithApple`, `associatedDomains`, `keychainSharing`, `weatherKit`, `musicKit`, `networkExtension`
+- `app_groups_ids` (string[], optional)
+- `associated_domains` (string[], optional — e.g. `applinks:app.example.com`)
+- `icloud_container_ids` (string[], optional)
+- `background_modes` (string[], optional — `fetch`, `remote-notification`, `processing`, `audio`, `location`, `bluetooth-central`, `voip`)
+
+## Outputs
+- `<ProjectName>.entitlements` plist at the target's Signing/Capabilities dir
+- `docs/plans/entitlements-summary.md` — diff of added/removed keys, per-capability rationale
+- XcodeBuildMCP capability toggles (Push, HealthKit, CloudKit, App Groups, Sign in with Apple) flipped on in the target UI
+
+## Workflow
+1. **Read state** — load `ios_features` from `docs/plans/.build-state.md`.
+2. **Resolve entitlements** — for each flag set `true`, look up the entitlement key(s) in `protocols/ios-frameworks-map.md §4`. Do not invent keys; if the table doesn't cover it, query `apple-docs-mcp` and surface as a TODO in the summary.
+3. **Merge plist immutably** — read existing `<ProjectName>.entitlements` if present, compute new dict as a merge (never clobber user-added keys), write a new file. Preserve key ordering for clean diffs.
+4. **Sync Xcode capability UI** — for capabilities that require target-level toggles (Push, HealthKit, CloudKit, App Groups, Sign in with Apple, Background Modes), call XcodeBuildMCP's capability-toggle tool so the Signing & Capabilities tab matches the plist.
+5. **Emit summary** — write `entitlements-summary.md` listing each capability, keys added, and values requiring user input (team ID, container IDs, domain list).
+
+## Validation
+- Every key in the output must trace back to a row in `ios-frameworks-map.md §4` or an explicit user-provided value.
+- `aps-environment` must be `development` in debug configs, `production` in release.
+- Associated domains must be prefixed (`applinks:`, `webcredentials:`, `activitycontinuation:`).
+- iCloud container IDs must start with `iCloud.` and match the CloudKit dashboard.
+
+---
+_Part of buildanything iOS mode. Delegates to `protocols/ios-frameworks-map.md §4`. See `protocols/ios-context.md` for persona._

package/skills/ios/ios-hig/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: ios-hig
+description: Use when designing iOS interfaces, implementing accessibility (VoiceOver, Dynamic Type), handling dark mode, ensuring adequate touch targets, providing animation/haptic feedback, or requesting user permissions. Apple Human Interface Guidelines for iOS compliance.
+---
+
+# iOS Human Interface Guidelines
+
+Apple's Human Interface Guidelines define the visual language, interaction patterns, and accessibility standards that make iOS apps feel native and intuitive. The core principle: clarity and consistency through thoughtful design.
+
+## Reference Loading Guide
+
+**ALWAYS load reference files if there is even a small chance the content may be required.** It's better to have the context than to miss a pattern or make a mistake.
+
+| Reference | Load When |
+|-----------|-----------|
+| **[Interaction](references/interaction.md)** | Touch targets, navigation, layout, hierarchy, or gesture patterns |
+| **[Content](references/content.md)** | Empty states, writing copy, typography, or placeholder text |
+| **[Visual Design](references/visual-design.md)** | Colors, materials, contrast, dark mode, or SF Symbols |
+| **[Accessibility](references/accessibility.md)** | VoiceOver, Dynamic Type, Reduce Motion, or accessibility labels |
+| **[Feedback](references/feedback.md)** | Animations, haptics, loading states, or error messages |
+| **[Performance](references/performance-platform.md)** | Responsiveness, system components, or app launch |
+| **[Privacy](references/privacy-permissions.md)** | Permission requests, data handling, or privacy-sensitive APIs |
+
+## Common Mistakes
+
+1. **Touch targets smaller than 44x44 points** — Buttons and interactive elements must be at least 44x44 points (iOS) to accommodate thumbs. Smaller targets cause frustrated users and accessibility failures.
+
+2. **Ignoring Dynamic Type constraints** — Text with fixed sizes doesn't respect user accessibility settings. Use Dynamic Type sizes, test with Large or Extra Large settings, and avoid hardcoded font sizes.
+
+3. **Insufficient color contrast in dark mode** — Colors that work in light mode may fail accessibility in dark mode. Test with Reduce Contrast accessibility setting enabled for both modes.
+
+4. **Over-animating transitions** — Animations that feel smooth at 60fps can trigger motion sickness in users with vestibular issues. Respect Reduce Motion settings and keep animations under 300ms.
+
+5. **Missing VoiceOver labels on custom controls** — Custom buttons, toggles, or interactive views need `.accessibilityLabel()` and `.accessibilityHint()` or they're completely unusable to screen reader users.
+
+6. **Haptic overuse** — Every action does NOT need haptic feedback. Reserve haptics for confirmations (purchase, critical action) and errors. Excessive haptics are annoying and drain battery.
+
+
+---
+
+Vendored from: https://github.com/johnrogers/claude-swift-engineering/tree/main/plugins/swift-engineering/skills/ios-hig

package/skills/ios/ios-hig/references/accessibility.md

@@ -0,0 +1,81 @@
+# Accessibility
+
+Apple Human Interface Guidelines for accessible iOS app design.
+
+## Critical Rules
+
+- Provide meaningful accessibility labels/hints for icon-only controls and custom components
+- Ensure Dynamic Type works end-to-end; avoid layouts that collapse at larger sizes
+- Maintain readable contrast and avoid conveying meaning by color alone
+- Respect platform accessibility settings (Reduce Motion/Transparency) when relevant
+- Prefer system controls that come with good accessibility defaults
+
+## Examples
+
+### Icon-Only Buttons
+
+```swift
+// ✅ Icon-only button with accessible label
+Button(action: model.refresh) {
+    Image(systemName: "arrow.clockwise")
+}
+.accessibilityLabel("Refresh")
+.accessibilityHint("Reloads the list")
+
+// ❌ Icon-only control with no label; VoiceOver reads "arrow.clockwise"
+Button(action: model.refresh) {
+    Image(systemName: "arrow.clockwise")
+}
+```
+
+### Dynamic Type Support
+
+```swift
+// ✅ Dynamic Type with proper layout
+VStack(alignment: .leading, spacing: 8) {
+    Text(item.title)
+        .font(.headline)
+        .lineLimit(2)
+
+    if let summary = item.summary {
+        Text(summary)
+            .font(.body)
+            .foregroundStyle(.secondary)
+            .lineLimit(3)
+    }
+}
+
+// ❌ Hard-coded sizes that don't scale
+VStack(alignment: .leading) {
+    Text(item.title)
+        .font(.system(size: 14))
+        .lineLimit(1)
+}
+```
+
+### Reduce Motion
+
+```swift
+// ✅ Respect Reduce Motion setting
+@Environment(\.accessibilityReduceMotion) var reduceMotion
+
+var body: some View {
+    content
+        .animation(reduceMotion ? .none : .spring, value: isExpanded)
+}
+
+// ❌ Always animate regardless of setting
+var body: some View {
+    content
+        .animation(.spring, value: isExpanded)
+}
+```
+
+## Summary
+
+**Key Principles**:
+1. Use `.accessibilityLabel()` and `.accessibilityHint()` for icon-only controls
+2. Support Dynamic Type with system font styles
+3. Maintain sufficient color contrast
+4. Respect accessibility settings like Reduce Motion
+5. Prefer system controls with built-in accessibility

package/skills/ios/ios-hig/references/content.md

@@ -0,0 +1,142 @@
+# Content
+
+Apple Human Interface Guidelines for content, empty states, writing, and typography.
+
+## Table of Contents
+1. [Empty States](#empty-states)
+2. [Writing and Labels](#writing-and-labels)
+3. [Typography and Dynamic Type](#typography-and-dynamic-type)
+
+## Empty States
+
+### Critical Rules
+
+- Use empty states to **explain what this screen is** and **what to do next**
+- Prefer lightweight guidance (one sentence + primary action) over multi-step tutorials
+- Keep onboarding contextual: explain features at the moment the user needs them
+- Avoid placeholder junk content that looks real; make it obvious when content is sample/demo
+
+### Examples
+
+```swift
+// ✅ Helpful empty state with a clear next step
+ContentUnavailableView {
+    Label("No links yet", systemImage: "link")
+} description: {
+    Text("Save links to find them quickly later.")
+} actions: {
+    Button("Add link", systemImage: "plus") { model.presentAddLink() }
+        .buttonStyle(.borderedProminent)
+}
+
+// ❌ Empty UI with no explanation
+List { }
+```
+
+## Writing and Labels
+
+### Critical Rules
+
+- Prefer **plain language** and short phrases; avoid jargon and developer terms
+- Buttons should describe the action ("Save", "Add link"), not vague labels ("OK", "Yes")
+- Keep terminology consistent across the app (e.g., "Link" vs "URL"); choose one and stick to it
+- Error messages should explain the problem and the next step, without blame
+
+### Examples
+
+```swift
+// ✅ Clear action labels and consistent terminology
+Button("Add link", systemImage: "plus") { model.addLink() }
+Button("Save", action: model.save)
+
+// Error message example
+Text("Could not save link. Check your connection and try again.")
+
+// ❌ Vague and inconsistent
+Button("OK") { model.save() }
+Button("Add URL") { model.addLink() }
+
+// Error message without guidance
+Text("Error: Save failed")
+```
+
+### Writing Guidelines
+
+**Button Labels**:
+- ✅ "Delete", "Save", "Add link"
+- ❌ "OK", "Yes", "No"
+
+**Error Messages**:
+- ✅ "Could not load items. Pull to refresh."
+- ❌ "Error code 404"
+
+**Terminology Consistency**:
+- Choose one term and use it throughout
+- "Link" not "URL" or "Website"
+- "Save" not "Add" or "Create" interchangeably
+
+## Typography and Dynamic Type
+
+### Critical Rules
+
+- Use **Dynamic Type** styles (`.body`, `.headline`, `.caption`) instead of hard-coded sizes
+- Prefer **short, scannable labels**; use secondary text (`.secondary`) for supporting detail
+- Avoid truncation for critical info; if truncation can happen, provide an alternative (multi-line, disclosure, copy)
+- Use appropriate alignment and line limits; avoid overly dense paragraphs
+- Ensure text remains legible in accessibility sizes (test with larger sizes)
+
+### Examples
+
+```swift
+// ✅ Dynamic Type + predictable wrapping for important content
+VStack(alignment: .leading, spacing: 8) {
+    Text(item.title)
+        .font(.headline)
+        .lineLimit(2)
+
+    if let summary = item.summary {
+        Text(summary)
+            .font(.body)
+            .foregroundStyle(.secondary)
+            .lineLimit(3)
+    }
+}
+
+// ❌ Hard-coded sizes and single-line truncation for critical info
+VStack(alignment: .leading) {
+    Text(item.title)
+        .font(.system(size: 14))
+        .lineLimit(1)
+    Text(item.summary ?? "")
+        .font(.system(size: 11))
+        .lineLimit(1)
+}
+```
+
+### Dynamic Type Styles
+
+Use system text styles that scale with Dynamic Type:
+- `.largeTitle`, `.title`, `.title2`, `.title3`
+- `.headline`, `.body`, `.callout`
+- `.subheadline`, `.footnote`, `.caption`, `.caption2`
+
+```swift
+// ✅ System styles that scale
+Text("Main heading")
+    .font(.title2)
+Text("Body content")
+    .font(.body)
+Text("Supporting detail")
+    .font(.caption)
+    .foregroundStyle(.secondary)
+```
+
+## Summary
+
+**Key Principles**:
+1. Use `ContentUnavailableView` for helpful empty states
+2. Write clear, action-oriented button labels
+3. Keep terminology consistent throughout the app
+4. Error messages explain the problem and next step
+5. Use Dynamic Type styles, never hard-coded sizes
+6. Allow important text to wrap (don't truncate critical info)

package/skills/ios/ios-hig/references/feedback.md

@@ -0,0 +1,123 @@
+# Feedback
+
+Apple Human Interface Guidelines for motion, haptics, loading states, and error handling.
+
+## Table of Contents
+1. [Motion and Haptics](#motion-and-haptics)
+2. [Status and Error Feedback](#status-and-error-feedback)
+
+## Motion and Haptics
+
+### Critical Rules
+
+- Motion should be **purposeful**: reinforce state change, hierarchy, or causality—not decoration
+- Keep animations **subtle and consistent**; avoid stacking multiple effects (scale + rotate + blur) for routine interactions
+- Respect accessibility settings (Reduce Motion); don't rely on animation as the only feedback
+- Use haptics sparingly for meaningful moments (confirmations, errors), not for every tap
+
+### Examples
+
+```swift
+// ✅ Subtle animation tied to state change
+withAnimation(.spring(response: 0.35, dampingFraction: 0.85)) {
+    model.isExpanded.toggle()
+}
+
+// ❌ Excessive motion for routine UI; feels noisy and fatiguing
+withAnimation(.easeInOut(duration: 2.0)) {
+    model.isExpanded.toggle()
+}
+// Plus additional scale/rotation/blur effects on the entire screen
+```
+
+### Motion Guidelines
+
+**Purposeful Animation**:
+- State transitions (expanding/collapsing)
+- Hierarchy changes (list reordering)
+- Causality (deletion leading to list reflow)
+
+**Animation Parameters**:
+- Spring response: 0.3-0.4 seconds
+- Damping fraction: 0.8-0.9 (less bouncy)
+- Easing: Prefer springs over linear or custom curves
+
+**Accessibility**:
+- Always respect `@Environment(\.accessibilityReduceMotion)`
+- Provide non-animated alternatives
+- Don't use motion as the only feedback mechanism
+
+## Status and Error Feedback
+
+### Critical Rules
+
+- Always show **state feedback** for async work: loading, success, failure, and empty
+- Prefer **inline** status for local issues (validation) and **alerts** for exceptional interruptions
+- Make errors **actionable**: explain what happened in plain language and offer a next step (retry, fix input, dismiss)
+- Avoid blaming the user; avoid exposing raw system error text
+- Use system patterns for empty states (`ContentUnavailableView`) and progress (`ProgressView`)
+
+### Examples
+
+```swift
+// ✅ Clear empty state and recoverable error with retry
+Group {
+    if model.isLoading {
+        ProgressView("Loading…")
+    } else if model.items.isEmpty {
+        ContentUnavailableView(
+            "No items",
+            systemImage: "tray",
+            description: Text("Add your first item to get started.")
+        )
+    } else {
+        List(model.items) { item in Text(item.title) }
+    }
+}
+.alert("Couldn't load items", isPresented: $model.isShowingError) {
+    Button("Retry", action: model.reload)
+    Button("Cancel", role: .cancel) {}
+} message: {
+    Text("Check your connection and try again.")
+}
+
+// ❌ Silent failures and raw errors; no next step
+List(model.items) { item in Text(item.title) }
+// On error: print(error) and keep stale UI with no feedback
+```
+
+### Status Guidelines
+
+**Loading States**:
+- Use `ProgressView` for async operations
+- Show progress for operations >1 second
+- Provide context ("Loading items…")
+
+**Empty States**:
+- Use `ContentUnavailableView` for empty collections
+- Explain what the view is for
+- Provide a primary action to get started
+
+**Error States**:
+- Use alerts for unexpected errors that interrupt flow
+- Use inline validation for expected errors (form fields)
+- Always provide a recovery action
+
+**Error Messages**:
+- ✅ "Couldn't save item. Check your connection and try again."
+- ❌ "Error: NetworkError.timeout"
+
+**Next Steps**:
+- Retry button for transient failures
+- Fix input guidance for validation errors
+- Dismiss or cancel for unrecoverable errors
+
+## Summary
+
+**Key Principles**:
+1. Keep motion subtle, purposeful, and tied to state changes
+2. Respect Reduce Motion accessibility setting
+3. Always show feedback for async operations (loading, empty, error)
+4. Make errors actionable with plain language and recovery steps
+5. Use system patterns (`ProgressView`, `ContentUnavailableView`, alerts)
+6. Prefer inline validation for expected errors, alerts for exceptional interruptions