Use the current project and the user's requested feature as the scope. Build working Swift implementations with explicit errors, injected dependencies, preview data and meaningful verification.
- Search the local library for the feature or API. With MCP use
search_local_references; with a checkout runnode scripts/query-library.mjs search "feature". Restrict to source or guides when helpful. - Read only a matching source file or relevant guide section. MCP provides
get_reference_outlineandread_local_reference; the offline command providesoutlineandread. FollownextOffsetwhen you need the complete file. - Prefer canonical source and tests in
samples/andtemplates/. Keep dependencies and availability requirements. Documentation can contain labelled anti-patterns and incomplete examples; do not blindly concatenate its code fences. - Use official Apple links for attribution and changed-API checks. The library is a dated local reference, not Apple's private framework source. A catalog entry does not prove a working implementation exists.
Do not load the whole inventory, all technology topic maps, or the detailed engineering guide by default. Character limits bound tool output; actual token use depends on the model.
- UI-observed models are isolated to
@MainActor; use@Observablewhere supported. - Inject services through protocols and initializers. Keep concrete service construction at the composition root. Previews must work without network or disk.
- Show loading, empty, success and error outcomes. Catch errors deliberately and preserve cancellation semantics.
- Respect deployment availability, privacy permissions and entitlements. Use the installed SDK to validate generated APIs.
- Use shared design tokens, semantic colors and Dynamic Type. Account for VoiceOver, Reduce Motion and iPad layouts.
- Compile and run appropriate tests before claiming code works. Separate inspected source, successful build/test evidence, and unverified runtime/device behavior.
- Follow the user's publication scope. Do not create paid services or publish an app without authorization.
| Task | Local reference |
|---|---|
| Find/reuse full source while keeping context small | docs/tooling/offline-source-library.md |
| Turn an idea into screens, features and a build | docs/tooling/idea-to-app.md, docs/tooling/app-description-workflow.md |
| Search an Apple technology | MCP search_apple_technologies, then compact get_apple_technology; otherwise search docs/apple/all-technologies.md |
| SDK updates or release notes | docs/apple/updates-and-release-notes.md |
| Layered app icon | docs/design/icon-composer.md; preserve editable layers and verify native .icon with Icon Composer |
| Swift concurrency or observation | docs/swift/swift-concurrency.md, docs/swiftui/state-and-data-flow.md |
| Architecture and dependencies | patterns/clean-architecture.md, patterns/mvvm.md |
| Design, colors and typography | docs/design/README.md, docs/design/design-tokens.md |
| Compile-tested implementations | samples/SkillPatterns/, samples/AppleRecipes/ and their READMEs |
| Run an app, see it in a sidebar, or inspect simulator/Duo availability | docs/tooling/ios-simulator-mcp.md, docs/platforms/iphone-duo.md |
| Client setup and MCP | docs/mcp/installation.md, docs/mcp/knowledge-server.md |
| Detailed engineering rules or a broader topic route | docs/agent-engineering-guide.md — search headings before reading the whole file |
For repository maintenance, regenerate mirrors after editing this entry point with scripts/sync-mirrors.sh. Run scripts/hooks/verify-repo.sh, check the local index, and run tests appropriate to changed code. Preserve existing instructions in supporting guides; use an independent reviewer for shipped changes as described in docs/orchestration/verification.md.