lacquer

Consult a stronger model mid-task for a second opinion before committing to an approach, when stuck, or before declaring a non-trivial task done — the fast-executor + strong-advisor pattern, implemented with the Agent and Workflow tools (Claude Code does not expose Anthropic's raw API advisor tool). Use when running on a cheaper/faster model for mechanical work and a hard design/architecture/risk decision needs a stronger check, or when authoring a Workflow script that should get expert review partway through instead of only at the end.

Use when the user says "caveman mode", "talk like caveman", "use caveman", "less tokens", or "be brief", invokes /caveman, or when token efficiency is requested. Switches responses to an ultra-compressed terse style (multiple intensity levels available, ~75% token reduction) while preserving full technical accuracy.

Use right after being corrected on something a CLAUDE.md file should already have told you, when explicitly asked to review CLAUDE.md, or periodically after a session with a lot of back-and-forth — reviews THIS conversation for friction and proposes a bounded CLAUDE.md edit. A lightweight, single-session complement to skill-tuning-loop (which mines many sessions and validates a proposal against held-out cases before surfacing it — reach for that instead when the ask is "make this systematic," not "check right now"). Own version of the dx plugin's `/dx:review-claudemd`.

Generate a solution, evaluate it against explicit pass/fail criteria, refine using the feedback, repeat until it passes or a round cap is hit. Use for tasks with a clear, checkable bar and demonstrable value from iteration — a bug fix that must pass a test suite, code that must satisfy a lint/style rubric, a document that must meet stated requirements. Distinct from advisor-checkpoint (one strategic consult before committing) — this is a convergence loop against a concrete standard.

Use when PR checks fail, CI is red, or GitHub Actions workflows break - systematically inspects failing checks via gh CLI, pulls logs, checks for flakiness and scopes the breaking commit, scopes external checks, then creates fix plan using existing plan skill

Write a structured handoff document before a session ends, before a context-heavy interruption (SSH/tmux disconnect, context running low, a worktree being handed to another worker or agent), or when explicitly asked for a handoff — captures progress, what worked/failed, and the exact next step so a fresh session can resume without re-deriving context. Own version of the dx plugin's `/dx:handoff`.

Run a large batch of independent work items (a fleet-wide harvest, a multi-repo sync-down, an overnight backlog) as a persistent coordinator loop instead of one item at a time. Use when there are enough independent units of work that dispatch-review-merge would otherwise repeat many times in a row, or when the batch should keep making progress across a heartbeat interval instead of stalling until the next message.

Use when you need to find code, a pattern, or a past implementation across GitHub repos — including private ones you have access to — not just the current working directory. grep/Glob only reach the checked-out repo; this reaches everywhere `gh` is authenticated for. Own version of the dx plugin's `/dx:private-github-search`.

The bar a SKILL.md must clear before it ships in this lacquer — tight trigger-oriented frontmatter, single responsibility, no padding, companion files only when genuinely needed. Use when writing a new skill, reviewing an existing one, or auditing the skill set for quality.

Empirically test whether a lacquer skill needs an edit by mining real session transcripts for friction, proposing a bounded fix, and validating it against held-out cases before it ships. Use when a skill in core/skills/ or profiles/*/skills/ keeps getting corrected in practice, when triaging a scheduled tuning-pass PR, or when skill-authoring-standard's manual rubric isn't enough to tell whether a proposed edit actually helps. Distinct from skill-authoring-standard (a static prose rubric checked by a human) — this is an empirical, evidence-gated loop checked by rollouts.

Use when touching widgets, animations, networking configuration, or background/observer cleanup — battery and performance patterns for WidgetKit timelines, SwiftUI animations, Low Power Mode handling, URLSession config, and NotificationCenter/Task cleanup under `@Observable`.

Use when wiring a new app-runtime service key (RevenueCat, Aptabase, …) into a project — setting up `Secrets.xcconfig`, surfacing a key through `project.yml` into `Info.plist`, and reading it at runtime. Distinct from CI/server secrets, which live in GitHub Actions secrets and never touch an xcconfig — see the project's `CLAUDE.md` Secrets section for that split.

Copy-in CI recipes for adding macOS build/test/lint to a project on the ios profile — either a macOS-only app with no iOS target, or a hybrid app that also ships a separate macOS scheme sharing code with an iOS target. Use when scaffolding CI for a new macOS app, or adding a macOS target/scheme to an existing iOS project. The lacquer does not auto-sync macOS CI (only two fleet projects have needed it so far — not enough signal to justify conditional asset sync yet); these are reference recipes you copy into your project's own workflow files, adapted from two real, working implementations (a macOS-only app and an iOS+macOS hybrid).

Use when building or debugging a macOS app and the request involves — (1) AppKit/SwiftUI interop or modernizing AppKit code, (2) App Sandbox / file-access entitlement errors, especially "works in Xcode, fails in TestFlight", (3) menu bar commands, keyboard shortcuts, or a menu item stuck disabled, (4) multi-window scenes (WindowGroup, Window, MenuBarExtra, openWindow), (5) the Settings/Preferences scene, (6) ScreenCaptureKit screen recording or sharing, (7) SwiftUI-on-macOS behavior that differs from iOS (Table, Inspector, NavigationSplitView, focus), or (8) notarized Developer ID distribution outside the App Store.

Use RocketSim to inspect visible UI and interact with iOS Simulator apps. Detects the installed RocketSim version, loads the matching bundled RocketSim CLI guidance, and helps agents read visible accessibility elements, navigate screens, tap, long-press, swipe, type text, press simulator hardware buttons, and automate simulator flows reliably. Use when: (1) the user mentions RocketSim, the rocketsim command, or RocketSim CLI, (2) interacting with an app in the iOS Simulator, (3) navigating or testing a simulator app with AI, (4) reading visible UI state or accessibility elements, (5) tapping, long-pressing, swiping, typing, or pressing simulator buttons, (6) using RocketSim instead of ad-hoc simulator automation.

Diagnose data races, convert callback-based code to async/await, implement actor isolation patterns, resolve Sendable conformance issues, and guide Swift 6 migration. Use when developers mention: (1) Swift Concurrency, async/await, actors, or tasks, (2) "use Swift Concurrency" or "modern concurrency patterns", (3) migrating to Swift 6, (4) data races or thread safety issues, (5) refactoring closures to async/await, (6) @MainActor, Sendable, or actor isolation, (7) concurrent code architecture or performance optimization, (8) concurrency-related linter warnings (SwiftLint or similar; e.g. async_without_await, Sendable/actor isolation/MainActor lint).

Use when a test needs to wait for an async state change instead of a fixed delay — the `no_task_sleep_in_tests` lint rule bans arbitrary `Task.sleep` in tests because it causes flaky failures. Provides the `waitUntil` polling helper to add to a test target instead.

Use when writing, reviewing, or refactoring SwiftUI code — state management, view composition, performance, macOS-specific APIs, or iOS 26+ Liquid Glass adoption. Also triggers whenever an Xcode Instruments `.trace` file is referenced (to analyse it) or the user asks to **record** a new trace — attach to a running app, launch one fresh, or capture a manually-stopped session with the bundled `record_trace.py`.

Refactor a SwiftUI view file for consistent property ordering, MV patterns, view model handling, and Observation usage; split an oversized body via same-file computed view properties or MARK-organized extensions. Use when asked to clean up a SwiftUI view's layout, reorder its properties, or standardize dependency/view-model initialization. For extracting reusable subviews, @ViewBuilder, container patterns, AnyView, or ZStack vs overlay/background composition, use swiftui-expert-skill instead.

Scan Apple's SwiftUI documentation for deprecated APIs and update the SwiftUI Expert Skill with modern replacements. Use when asked to "update latest APIs", "refresh deprecated SwiftUI APIs", "check for new SwiftUI deprecations", "scan for API changes", or after a new iOS/Xcode release. Requires the Sosumi MCP to be available.

Use when validating a user-provided or externally-sourced URL before it reaches `AVPlayer`, `URLSession`, or a `WKWebView` — building a positive- allowlist URL validator, or reviewing existing networking/media code for missing URL validation.

Use when building or reviewing a watchOS app or WatchKit extension — app structure and independent-app configuration, Watch Connectivity / companion-app sync, complications and Smart Stack widgets, controls or Live Activities on watch, background refresh and networking limits, watchOS-specific SwiftUI design conventions, or modernizing an older WatchKit/ClockKit project.

Symbolicate and triage iOS/macOS crash reports (.ips, MetricKit, legacy .crash, Xcode Organizer .xccrashpoint) via the `xcsym` CLI. Use when given a crash file to diagnose, when TestFlight/App Store Connect crashes need triage, when a crash comes back unsymbolicated, or when asked what kind of crash something is.

Scaffold, build, and package SwiftPM-based macOS apps without Xcode project. Use when you need a from-scratch macOS app layout, SwiftPM targets/resources, custom .app bundle assembly, or signing/notarization steps outside Xcode.

Use when stuck, wanting a second implementation or diagnosis pass, or handing a substantial task to Google's Antigravity CLI (agy) through a real subprocess -- a genuinely different agent harness, not just another model. Not relevant when already running under Antigravity CLI itself.

Use when asked to take a GitHub issue number, implement a fix, run builds/tests, commit with a closing message, and push. End-to-end workflow using gh CLI, local code changes, and git.

Capture App Store / TestFlight screenshots from the iOS Simulator at native resolution, downscale to every required display size, and upload to App Store Connect via helm-asc. Use when asked to take/produce/refresh App Store screenshots, marketing screenshots, or screenshots for custom product pages.

Build, run, and debug iOS apps on a simulator. Use when asked to run an iOS app, interact with the simulator UI, capture logs, or diagnose runtime behavior.

Profile native macOS/iOS apps for CPU hotspots, hangs, and hitches using Instruments traces. Use when asked to identify performance hotspots, profile CPU usage, or diagnose slow code paths without opening Instruments.

Create user-facing App Store release notes from git history. Use when asked to generate release changelog, App Store "What's New" text, or release notes based on git tags.

Best practices and patterns for building SwiftUI views and components. Use when creating or refactoring SwiftUI UI, designing tab architecture, composing screens, or needing component-specific guidance.

Expert Core Data guidance (iOS/macOS) covering stack setup, fetch requests & NSFetchedResultsController, saving/merge conflicts, threading & Swift Concurrency, batch operations & persistent history, migrations, performance, and NSPersistentCloudKitContainer/CloudKit sync. Use when setting up a Core Data stack, debugging threading/concurrency crashes, resolving NSMergeConflict or constraint violations, planning a schema migration, integrating CloudKit sync, or diagnosing Core Data performance/memory issues.

Expert guidance for Swift Testing: test structure, #expect/#require macros, traits and tags, parameterized tests, test plans, parallel execution, async waiting patterns, and XCTest migration. Use when writing new Swift tests, modernizing XCTest suites, debugging flaky tests, or improving test quality and maintainability in Apple-platform or Swift server projects.

Implement, review, or improve SwiftUI features using the iOS 26+ Liquid Glass API. Use when asked to adopt Liquid Glass in SwiftUI UI, refactor to Liquid Glass, or review Liquid Glass usage.

Audit and improve SwiftUI runtime performance. Use for requests to diagnose slow rendering, janky scrolling, high CPU/memory usage, excessive view updates, or layout thrash in SwiftUI apps.

Benchmark Xcode clean and incremental builds with repeatable inputs, timing summaries, and timestamped `.build-benchmark/` artifacts. Use when a developer wants a baseline, wants to compare before and after changes, asks to measure build performance, mentions build times, build duration, how long builds take, or wants to know if builds got faster or slower.

Apply approved Xcode build optimization changes following best practices, then re-benchmark to verify improvement. Use when a developer has an approved optimization plan from xcode-build-orchestrator, wants to apply specific build fixes, needs help implementing build setting changes, script phase guards, source-level compilation fixes, or SPM restructuring that was recommended by an analysis skill.

Orchestrate Xcode build optimization by benchmarking first, running the specialist analysis skills, prioritizing findings, requesting explicit approval, delegating approved fixes to xcode-build-fixer, and re-benchmarking after changes. Use when a developer wants an end-to-end build optimization workflow, asks to speed up Xcode builds, wants a full build audit, or needs a recommend-first optimization pass covering compilation, project settings, and packages.

Analyze Swift and mixed-language compile hotspots using build timing summaries and Swift frontend diagnostics, then produce a recommend-first source-level optimization plan. Use when a developer reports slow compilation, type-checking warnings, expensive clean-build compile phases, long CompileSwiftSources tasks, warn-long-function-bodies output, or wants to speed up Swift type checking.

Audit Xcode project configuration, build settings, scheme behavior, and script phases to find build-time improvements with explicit approval gates. Use when a developer wants project-level build analysis, slow incremental builds, guidance on target dependencies, build settings review, run script phase analysis, parallelization improvements, or module-map and DEFINES_MODULE configuration.