# Autonomous UI Workflow

> Use when building or modifying SwiftUI views autonomously - orchestrates the full UI development loop from spec through research, design, implementation, build verification, and visual validation using Xcode MCP and documentation skills

- Skill: `kmshdev/autonomous-ui-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kmshdev/autonomous-ui-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kmshdev/autonomous-ui-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: kmshdev (https://skillmd.com/u/kmshdev)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/kmshdev/autonomous-ui-workflow

---


## Project Context

- Xcode schemes: !`xcodebuild -list -json 2>/dev/null | jq -r '.project.schemes[]' 2>/dev/null || echo "no schemes found"`
- Recent build errors: !`xcodebuild -list 2>&1 | grep -i error | head -5 || echo "none"`

# Autonomous UI Development Workflow

## Lifecycle Position

Phases 2-4 (Design → Implement → Build). The inner UI development loop. After build is green, proceed to Phase 5 — load `swiftui-view-refactor` and `code-analyzer` for review.

## The Loop

```
Spec → Research → Design → Implement → Build → Review Gate → Preview → Validate → Iterate
```

## Phase 1: Spec

Gather requirements from user input (description, screenshot, Figma URL, or existing view reference). Identify:
- What the component does
- Where it fits in the view hierarchy
- Required interactions (tap, drag, keyboard)
- Data dependencies (AppState properties, bindings)

## Phase 2: Research

Load documentation skills based on what the UI needs:

| Need | Skill to Load |
|------|---------------|
| Glass effects, floating controls | `apple-liquid-glass-design` |
| Icons, SF Symbols | `swiftui-iconography-api` |
| Background materials, shapes | `swiftui-material-api` |
| Text fields, pickers, forms | `swiftui-input-api` |
| Font choices, text styling | `swiftui-typography-api` |
| Colors, gradients, tint | `swiftui-colors-api` |
| Blur, shadow, opacity | `swiftui-effects-api` |
| Sheets, popovers, alerts | `swiftui-presentation-api` |
| Local data storage, offline cache | `swift-actor-persistence` |

Also load project skills: `swiftui-components`, `macos-app-design`, `apple-liquid-glass-design`

## Phase 3: Design

Before writing code:
1. Read existing similar views in the project's Views directory for patterns
2. Decide view hierarchy and component breakdown
3. Plan state: `@State` for local, shared state via project's pattern; if data must survive app restart, load `swift-actor-persistence`
4. Plan design system usage: check CLAUDE.md for project-specific design rules
5. Document the design before implementing

## Phase 4: Implement

Follow project conventions (check CLAUDE.md and existing code):
- Use Xcode MCP tools as primary file interface when available: `XcodeUpdate` for edits, `XcodeRead` for reading, `XcodeWrite` for new files. See `xcode-mcp` for the full tool mapping.
- Use the project's state management pattern
- `#Preview` block at bottom
- Extract views > 100 lines
- Follow project-specific coding standards

## Phase 5: Build

Via Xcode MCP: follow the **BuildFix Loop** from the `xcode-mcp` skill.

If build fails → `XcodeListNavigatorIssues` → fix via `XcodeUpdate` → rebuild (max 5 iterations).
Do NOT claim success without build evidence.

CLI fallback (headless sessions only):
```bash
xcodebuild -project *.xcodeproj -scheme <SchemeName> -destination 'platform=macOS' build
```

## Phase 5b: Review Gate (Before Testing)

After build passes, BEFORE running any tests:

1. Load `code-analyzer` skill
2. Review all changed files for:
   - ARC lifetime hazards (local containers passed as references that outlive their scope)
   - Actor isolation correctness (`@MainActor`, `Sendable` conformance)
   - SwiftData patterns (`ModelContainer` must be retained by the owner of `ModelContext`)
   - Consistency with project patterns (check CLAUDE.md)
3. If issues found → fix → rebuild (BuildFix Loop) → re-review
4. If clean → proceed to Preview/Test

This gate is mandatory. It catches architectural bugs before they reach the test runner and cause MCP tool hangs.

## Phase 6: Preview

Use Xcode MCP `RenderPreview` to capture the view. Read the PNG to verify:
- Content is visible (not blank — watch for lagoonReveal)
- Layout matches intent
- Colors and typography are correct

## Phase 7: Validate

Check against project rules (see CLAUDE.md for project-specific guidelines):
- [ ] Follows project design system conventions
- [ ] Meets accessibility requirements
- [ ] Consistent with existing views
- [ ] No force unwrapping without justification
- [ ] GeometryReader guarded with `> 0` AND `.isFinite`

## Phase 8: Iterate

If validation fails → fix → rebuild → re-preview. One view at a time.