Idea: Apple Intelligence support-pilot companion + design-gap analysis

Apple Intelligence support-pilot companion

Raised by Chris 2026-07-16, during the skilled-AutoPlayer brainstorm (see docs/superpowers/specs/2026-07-16-skilled-autoplayer-balance-signal-design.md). Parked here as its own idea rather than folded into that night’s build — it’s a different kind of feature (native platform integration, narrative writing) with real open questions, not something to hand to an unattended overnight swarm without its own dedicated brainstorm.

The idea, two related but separable pieces

1. In-fiction companion using on-device Apple Intelligence. Framed as a support pilot monitoring the player from a space station, occasionally radioing in with advice — Chris’s own framing, and a good one: it turns a hard platform limitation (below) into a fictional feature rather than an inconsistency to explain away.
2. Using an LLM to spot design gaps from AI-player telemetry. Reading the soak/fun-signal data (death-tick distribution, build diversity, weapon dud/overpower rates — see the skilled-AutoPlayer spec) and asking qualitative questions a pure stats pass won’t: do we need more ranged options, is there a gap between “fast/weak” and “slow/powerful” archetypes, etc.

What’s actually confirmed (checked 2026-07-16, verify again before building — this space moves fast)

• Apple’s Foundation Models framework (native Swift access to the on-device Apple Intelligence model) ships with iOS 26 / iPadOS 26 / macOS 26, on Apple Intelligence-capable hardware. It is not available on tvOS. Current Apple TV hardware doesn’t run Apple Intelligence at all; a future Apple TV model is reported as the first that will, but that’s not the hardware this project tests on. So Chris’s own read — “probably only iPhone and Mac” — is right, and Apple TV (this project’s primary live target) is out for now regardless of framework work done elsewhere. This also conveniently answers the “why is the AI silent on the TV build” question — piece 1’s fictional framing means it doesn’t need to appear there at all.
• This project has no existing GDExtension / native Swift bridge for gameplay — /sim is pure GDScript by design (see root CLAUDE.md § Architecture), and platform/tvos/’s only hand-maintained native code is 3 small patched files in patches/ inside the export shell, not a general native-module workflow. Calling Foundation Models from GDScript means building that bridge from scratch — real, unscoped engineering, not a quick add.

Open questions for a real brainstorm (not answered here)

• Does the companion read live sim state each session, or does it comment on the aggregate soak/telemetry data (i.e., is it a live in-game feature, or a dev-facing analysis voice)? These are very different builds — piece 1 (in-fiction, live, on iOS/Mac only) vs. piece 2 (offline analysis over JSON reports, platform-independent, arguably buildable today with no native bridge at all — literally just asking an LLM, any LLM, to read the fun-signal JSON and write commentary).
• If piece 1 is live in-game: what triggers a message (level-up? boss-kill? player struggling?), how often, and does bad advice ever risk feeling patronizing rather than charming?
• Latency/quality of the on-device model for this use case — untested.

Platform-uniform fallback: a non-AI version of the same character (added by Chris while parking this)

Rather than the companion simply not existing on tvOS, give it a rule-based backend there — same in-fiction “support pilot” character, but driven by authored heuristic triggers reading sim state (low HP, an empty weapon slot, a redundant upgrade pick, boss approaching, a long no-damage-taken streak, etc.) instead of a generated model. This needs no native bridge at all — plain GDScript, same pattern as any other rule-based dev/UX feature already in the project — and would ship everywhere immediately, with the on-device model version on iOS/Mac being a strictly richer variant of the same character rather than a platform-exclusive feature. Worth designing the trigger/message system as the shared foundation FIRST (ships on every platform, including tvOS today) with the Apple Intelligence backend as an enhancement layered on top later, rather than designing the AI version first and retrofitting a fallback.

Recommendation

Piece 2 needs no new engineering and no platform gate — it’s just asking an LLM to read the fun-signal JSON reports (already being built) and write a gap-analysis section. Cheap enough to fold into the same overnight report-writing step rather than treating it as a separate project. Piece 1 is the real idea and deserves its own brainstorm → spec cycle when there’s room for it: native bridge scoping, the trigger/writing design, and confirming Foundation Models integration actually behaves well called from a Godot-hosted app before committing further.