@lampdotdev/lamp 0.0.0-stage → 0.35.0

package/Resources/skills/android-design/SKILL.md

@@ -0,0 +1,159 @@
+---
+name: android-design
+description: How a good Android app looks and behaves - Material 3 theme and color roles, layouts for phones, foldables and tablets, navigation and predictive back, which component for which job, empty, loading and error states, motion and accessibility. Read before designing or restyling an Android app's screens.
+---
+
+# Designing an Android app
+
+The person should feel they're holding an app Google might have made: calm surfaces, one accent, rounded shapes, big
+readable type, and everything where Android people expect it. It's Jetpack Compose with Material 3 (version 1.4 in
+these apps). Everything below compiles with the libraries already in app/build.gradle.kts.
+
+## Theme
+
+- Keep the scaffold's `AppTheme`: dynamic color from the wallpaper on Android 12 and later, and a scheme of your own
+  before that. Make that scheme from the app's one accent: `lightColorScheme(primary = …, primaryContainer = …,
+  secondary = …, tertiary = …)` and its dark twin, each container a lighter (light theme) or deeper (dark theme) tone
+  of its color, with its `on…` color legible on it.
+- Color by role, never by hex in a screen: `primary` for the one most important action, `primaryContainer` and
+  `secondaryContainer` for things to stand out softly (a selected card, a highlighted number), `tertiaryContainer` for
+  a contrasting accent, `surface` with `surfaceContainerLow` … `surfaceContainerHighest` for layers (a card on a page
+  is one step higher than the page), `onSurfaceVariant` for secondary text, `outlineVariant` for dividers, `error` and
+  `errorContainer` for problems. A color that isn't a role (a category's own color, a chart's series) still gets a
+  light and a dark value.
+- Type from `MaterialTheme.typography` only: `displayLarge`/`displayMedium` for a hero number or a timer,
+  `headlineSmall`…`headlineLarge` for a screen's big title, `titleMedium`/`titleLarge` for a card's or a list item's
+  title, `bodyLarge` for reading, `bodyMedium` for supporting text, `labelLarge` for buttons and `labelMedium`/
+  `labelSmall` for chips and captions. A number that changes uses `fontFeatureSettings = "tnum"` so it doesn't jiggle.
+  Sizes are in sp, so the person's font size applies.
+- Shapes from `MaterialTheme.shapes`: `extraLarge` (28 dp) for a hero card or a sheet, `large` for cards, `medium`
+  for smaller containers, `small` for chips and fields, `CircleShape` for avatars and icon buttons. Current Android is
+  generous with roundness and size: a big rounded card with a large number in it reads better than a dense table.
+
+## Edge to edge and insets
+
+- The app draws behind the status and navigation bars (`enableEdgeToEdge()` in MainActivity). `Scaffold` hands its
+  content the padding that keeps it clear of them and of its own bars: pass it on, and for a list give it as
+  `contentPadding` (`LazyColumn(contentPadding = innerPadding)`), so the list scrolls under the bars and its last item
+  ends above the gesture bar rather than being cut off.
+- A text field near the bottom needs `Modifier.imePadding()` (or the Scaffold's `contentWindowInsets`) so the keyboard
+  doesn't cover it. A screen without a Scaffold uses `Modifier.safeDrawingPadding()`.
+- A game or a full-screen viewer can hide the system bars with `WindowCompat.getInsetsController(window,
+  window.decorView).hide(WindowInsetsCompat.Type.systemBars())`, with `systemBarsBehavior =
+  BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE`; nothing else should.
+
+## Every screen size
+
+Phones, foldables and tablets run the same app, and the window can be resized. Choose the layout by the width the app
+has, read at the top of the screen with `BoxWithConstraints` (no extra library): under 600 dp is compact (a phone held
+upright), 600 to 840 medium (a foldable open, a small tablet, a phone on its side), 840 and over expanded.
+
+- Compact: one pane, a bottom `NavigationBar` for three to five top-level destinations.
+- Medium and expanded: a `NavigationRail` at the start edge in place of the bottom bar, and a list beside its detail
+  (the list about 360 dp wide, the detail filling the rest) where a phone would go from one to the other. Selecting
+  in the list changes the pane beside it, not the screen.
+- Content never stretches across a wide window: reading text and forms stay within about 640 dp, centered or beside
+  something else. Grids use `LazyVerticalGrid(GridCells.Adaptive(minSize = 160.dp))` so columns follow the width.
+- Never lock the orientation, and don't assume the window is the screen.
+
+## Navigation and back
+
+- Screens are destinations in Navigation 3: each a `@Serializable` class or object implementing `NavKey`, the stack
+  `rememberNavBackStack(Home)` (it survives Lamp's reopen and Android's), and `NavDisplay` showing its top with an
+  `entryProvider`. Going to a screen adds to the stack; back removes from it.
+- Back is the system's gesture, with its predictive preview of where it leads (on by default for these apps): let
+  `NavDisplay` handle it. Use `BackHandler` only to close something on the screen itself (a search, a selection, a
+  sheet's own state), never to ask "are you sure you want to leave?".
+- Top-level destinations (the bottom bar's) don't stack on each other: switching to one replaces the stack's root, and
+  each keeps its own scroll position.
+- The top app bar: `CenterAlignedTopAppBar` or `TopAppBar` for an ordinary screen; `LargeTopAppBar` with
+  `TopAppBarDefaults.exitUntilCollapsedScrollBehavior()` for a collection's home, whose big title shrinks into the bar
+  as the list scrolls (connect it with `Modifier.nestedScroll(scrollBehavior.nestedScrollConnection)`). An up arrow
+  (`Icons.AutoMirrored.Rounded.ArrowBack`) only on screens below the top level. At most two or three action icons;
+  the rest in an overflow menu (`DropdownMenu` from `Icons.Rounded.MoreVert`).
+
+## The right component for the job
+
+- The one main thing to create: a `FloatingActionButton`, or `ExtendedFloatingActionButton` with a word when the icon
+  alone isn't obvious, shrinking to its icon as the list scrolls (`expanded = !listState.canScrollBackward`). One per
+  screen, and none on a screen whose job is reading.
+- Rows of things: `ListItem` (headline, supporting text, a leading icon, avatar or picture, a trailing value, switch or
+  chevron) in a `LazyColumn`, with `HorizontalDivider` only where items run together. Cards (`Card`, `ElevatedCard`,
+  `OutlinedCard`) for things that are each a little page (a recipe, a place), not for every row.
+- Choosing: `FilterChip`s in a scrolling row for filters, `SingleChoiceSegmentedButtonRow` for two to five views of the
+  same thing, `Switch` for on and off (in a `ListItem`'s trailing slot for settings), `RadioButton`s or a menu
+  (`ExposedDropdownMenuBox`) for one of many, `Slider` for an amount, `DatePickerDialog` and `TimePicker` for when.
+- Searching: a `SearchBar` at the top of a collection, or a search action that opens one.
+- More about one thing, or a few actions on it: a `ModalBottomSheet`. A dialog (`AlertDialog`) only for a choice that
+  can't wait or can't be undone.
+- After deleting or archiving: do it at once and offer Undo in a `Snackbar` (`SnackbarHost` in the Scaffold), rather
+  than asking first. Lists can delete or archive with a swipe (`SwipeToDismissBox`), with the same Undo.
+- Content fetched from the network or the AI: `PullToRefreshBox` around the list.
+- Icons from `Icons.Rounded` throughout (one style per app), `Icons.AutoMirrored.Rounded` for ones with a direction.
+- `TopAppBar`, the search bar, bottom sheets, date and time pickers, `SwipeToDismissBox`, `PullToRefreshBox` and
+  `ExposedDropdownMenuBox` need `@OptIn(ExperimentalMaterial3Api::class)`: put `@file:OptIn(ExperimentalMaterial3Api::class)`
+  at the top of a file that uses them.
+- Not in this version of Material, so don't reach for them: `MaterialExpressiveTheme`, `LoadingIndicator`,
+  `ButtonGroup`, `FloatingToolbar`, `SplitButton`, `FloatingActionButtonMenu`, `NavigationSuiteScaffold` and the
+  adaptive list-detail scaffolds. The layouts above do their jobs with what's here.
+
+## Every state
+
+Design each screen in every state it can be in, since the person will see all of them:
+
+- Empty: an icon (48 to 64 dp, `onSurfaceVariant`), a short headline, one sentence and the one action that fills it,
+  centered in the space. Not a blank list.
+- Loading: a `CircularProgressIndicator` in the space the content will take, or a `LinearProgressIndicator` under the
+  top bar while what's on screen is refreshed; for a list, a few placeholder rows in `surfaceContainerHigh` shapes
+  reads calmer than a spinner. An AI call shows what it's doing ("Writing a summary…"), and its result arrives with
+  a fade.
+- Failed: say what went wrong in plain words and offer Try Again, in place of the content; a failure of something in
+  the background is a Snackbar.
+- Lots: long names wrap or end in an ellipsis (`maxLines`, `overflow = TextOverflow.Ellipsis`), and a list of
+  thousands is still a `LazyColumn` with `key = { it.id }`.
+- Big text: at the largest font size (twice the default) nothing overlaps or is cut off; rows grow taller, and a row of
+  buttons wraps (`FlowRow`).
+- Dark: everything by role, so it follows the system; check that a picture or a custom color still reads.
+
+## Motion
+
+Motion says where something came from and where it went, quickly and with a little spring.
+
+- Appearing and disappearing: `AnimatedVisibility` (fade with expand or slide), `AnimatedContent` or `Crossfade`
+  when one thing becomes another, `Modifier.animateContentSize()` when something grows.
+- Lists: `Modifier.animateItem()` on each item, so adding, removing and reordering move rather than jump.
+- Values: `animateFloatAsState`, `animateColorAsState` and friends with `spring(dampingRatio =
+  Spring.DampingRatioMediumBouncy, stiffness = Spring.StiffnessMediumLow)` for things the person touched,
+  `tween(200 to 300 ms)` for fades.
+- Feel: `LocalHapticFeedback.current.performHapticFeedback(HapticFeedbackType.LongPress)` on a long press, a toggle
+  or a completed drag; not on every tap.
+
+## Touch and accessibility
+
+- Every touch target at least 48 by 48 dp (an `IconButton` already is), with 8 dp between neighbors.
+- Icon-only buttons have a `contentDescription` saying what they do ("Delete note"), decorative images `null`.
+  Headings are marked `Modifier.semantics { heading() }`; a row that's one thing to tap is one element
+  (`Modifier.clickable` on the row, `mergeDescendants`).
+- Text contrast at least 4.5 to 1 on its background (the `on…` roles are), and never color alone to say something:
+  pair it with an icon or a word.
+
+## Games
+
+A game draws itself: a `Canvas` filling the screen, its loop in `LaunchedEffect` with `withFrameNanos`, input from
+`pointerInput` (`detectTapGestures`, `detectDragGestures`). Material's controls are for its menus and score screen
+only. Hide the system bars while playing, keep the game's state in a class the Canvas reads, and save the score and
+progress with LampStore.
+
+A game has sound: a short effect (under a second) for each thing the player does or meets, from `SoundPool` with each
+sound loaded once (files in `app/src/main/res/raw`, .ogg or .wav, or what the `assets` tool brought into
+`app/src/main/assets`, opened with `context.assets.openFd("<pack>/<file>")`), and music only when it suits, quiet (0.3
+to 0.4) under effects at 0.6 to 0.8, from a `MediaPlayer` with `isLooping`. Look in the `assets` tool first; only for what nothing there fits, make the effects in code: a
+few hundredths of a second of a wave written into an `AudioTrack` (`MODE_STATIC`), with soft ends so it doesn't click.
+Pause the music when the activity stops and release both when it's destroyed. Its settings turn sound and music on and
+off, kept with LampStore. The emulator plays it on the Mac's speakers.
+
+## Checking it
+
+Look at each screen with `look_at_app` as you build it, with real-looking content in it (several items, long and short
+names) and empty. Compare against the list above: the bars clear of the system's, one accent, roles not hex, the
+type scale, nothing smaller than 48 dp to tap, and every state designed.

package/Resources/skills/app-ai/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: app-ai
+description: AI inside the app - whether it belongs at all (asked for, worth offering with one question first, or left out), Apple's on-device frameworks first, LampAI for open-ended text and pictures, decisions for judging things by what they mean, checked actions for doing what the person asks, setup and where data goes, untrusted text, and dates. Read before writing any of it.
+---
+
+# AI inside the app
+
+## Whether AI belongs, and asking first
+
+Lamp never adds AI the person didn't ask for. Keep it in mind as one way to make an app better, not the point of every
+app: most need none. Decide from what they want to get done, the kind of app, the data it has and what a wrong answer
+would cost.
+
+- **Asked for**: the request itself is for what AI does ("summarize my emails", "understand what I say", "suggest a
+  name"). Build it with the smallest block that does it, and say in a sentence what it does and where it's worked out.
+- **Worth offering**: AI would add something definite (understanding what they type, reading what they hand the app,
+  drafting) but they didn't ask for it. Before writing any of the app, ask with one `ask` that says what they're
+  making and what AI would do in it, in their words: "I see you're making a recipe box. Want AI to turn a pasted recipe
+  into a card and find recipes by what's in your fridge?", answered No thanks or Yes, in that order, so leaving it to
+  you means none. Then build: with that AI after a yes, without it otherwise.
+- **Leave it out**: exact rules already do it, the gain is vague, or facts, timing or anything in real time would get
+  less reliable. Ordinary code, and no question about AI.
+
+Don't pester. Offer AI at most once for an app, where it would change what the app can do, never for small changes or
+in every reply. A no is for that app alone: write "AI: offered, declined" in its APP.md (not in Lamp's notes about the
+person), don't offer AI in that app again unless they bring it up, and still offer it in other apps where it fits.
+
+A kitchen timer with three presets and a loud alarm has no AI and no question about it: durations, scheduling and the
+alarm are code. A remote "with buttons for my TV" is buttons, and "Want AI to turn 'movie night' into a routine for
+your TV and speaker?" is worth one question before building it. "Let me say 'movie night' and have it use my TV and
+speaker" asks for it, so it's built: a routine the person reviews and saves, which then runs from its button with no AI.
+
+Which block: Apple's frameworks where one fits; `ask(..., as:)` for a structured draft; a decision for a judgment by
+meaning; a checked action (below) for a request that changes something. Arithmetic, ids, permissions, what's saved and
+what's true stay in code. A model's confidence is never permission to change something.
+
+When AI goes in (asked for, or after a yes), write its contract in APP.md under the feature, a few lines: what it
+gives the person, which block, what's sent and where it's worked out (from `LampAI.status`, below), what it may
+change, what the app checks, what happens without it, and the case that proves it works. Keep it current as the feature changes.
+
+## On-device frameworks first
+
+Prefer Apple's on-device frameworks whenever one fits the job: they're instant, free, private and work offline.
+
+- Text in images or PDFs, barcodes and QR codes, faces, body or hand poses, cutting a subject out of its background,
+  image tags or similarity → Vision (VisionKit's ImageAnalysisOverlayView for Live Text in an image view).
+- Speech to text → Speech (SFSpeechRecognizer, with requiresOnDeviceRecognition when supported).
+- Reading text aloud → AVSpeechSynthesizer.
+- Language detection, names and places, sentiment, semantic search → NaturalLanguage (NLTagger, NLEmbedding).
+- Recognizing sounds → SoundAnalysis.
+- Photo filters and effects → Core Image.
+- Translation → Translation, inside `if #available(macOS 15, *)` on the Mac and `if #available(iOS 18, *)` on iPhone.
+
+The app already declares microphone, speech recognition and camera permissions (and calendars, reminders, contacts
+and photos; on the Mac also Bluetooth and Mail); request authorization before use and handle denial in the UI.
+
+## LampAI for the rest
+
+For open-ended AI work those frameworks can't do (summarizing, extracting, rewriting, answering questions,
+generating text, understanding what a picture means), use `LampAI.ask(...)` from LampSupport.swift. Read its doc
+comment for usage. Never call AI APIs directly, never ask the user for API keys. It accepts `images:` (`NSImage` on
+the Mac, `UIImage` on iPhone, `LampImage` in an app for both) when the AI needs to look at photos or screenshots. To
+create or edit pictures, use `LampAI.makeImage(...)`, `LampAI.editImage(...)` or `LampAI.editImages(...)`; these take
+10–60 seconds. Show a ProgressView while waiting and show errors in the UI.
+
+## Doing what the person asks: checked actions
+
+`LampAI.act` in Swift is a `LampActSession` (its comment has the whole API) holding the app's own tools: reads that look
+things up and writes that change them, each a few lines over the app's data and its ordinary commands. The AI proposes
+calls, Lamp checks their shapes, the app's `check` says whether that exact change is allowed now, and its `run` makes it
+and returns a receipt. Lamp keeps the loop, its limits (4 AI steps between questions, 6 changes a request, 3 questions
+back, the route's time), cancellation, questions back and the receipts.
+
+```swift
+struct Rename: Decodable { let id: String; let name: String }
+
+let session = LampActSession(about: "A list of rooms. Ask which room when two could fit.", tools: [
+    .read("rooms", "Every room: id and name.") { store.rooms.map { ["id": $0.id, "name": $0.name] } },
+    .write("rename", "Renames one room.", args: ["id": .text("A room's id from rooms"), "name": .text("The new name")], as: Rename.self,
+           check: { r, _ in store.room(r.id) == nil ? "There's no room with that id." : r.name.isEmpty ? "Say the new name." : nil },
+           run: { r, _ in try store.rename(r.id, to: r.name); return LampActReceipt("Renamed to \(r.name)") }),
+])
+let result = await session.ask(typed).result
+if let question = result.question { askBack(question, offering: result.choices) }   // then session.answer(reply)
+else { status = result.summary }
+```
+
+- Show the feature where `await LampAI.status(.act)` says it's available, with what answers and where its `processing`
+  is (`remote` for a service, Claude Code and Codex included; `onDevice` for a model on this Mac). When it isn't, keep
+  the feature visible with its `reason` and a "Set up in Lamp" button (`LampAI.openSetup(for: .act)`), or "Open Lamp" /
+  "Update Lamp" when `setup` says so; keep the typed draft, and every manual control working. Check again when the app
+  comes back to the front, and never send the draft by itself after setup. Available is no guarantee: show the actual
+  failure (`result.error`) with the request kept and an explicit Try Again.
+- A tool is a named read or write over the app's own data, ids in and ids out: never "run this", never an address the
+  AI gives, never another app. Device names, messages and pages are data, not instructions.
+- Every write's `check` looks its items up again by id and says in a sentence why it can't be done now (gone, not
+  connected, can't do that, out of range); make the final check and the change one step for local data, or have `run`
+  check the revision again. Make the ids of what a write adds from `call.key`, so the same change delivered twice finds
+  it instead of adding a second.
+- Say what happened from `result.done` (the receipts), `failed`, `skipped` and `stopped`, which is what `summary` does:
+  never from the AI's `reply`, which is shown only for a question or when nothing changed. A receipt says what the code
+  knows: "Sent" when a device took a command, never "The TV is on".
+- Offer `result.choices` as buttons for a question; only the first answer counts (`session.answer` returns nil after).
+- Cancel (`turn.cancel()`) when the person stops or closes it. A change already sent stays in the receipts as sent:
+  never say nothing happened. Don't retry a change whose outcome is uncertain by yourself; show what's left for the
+  person to run again.
+- For a change with real consequences (a device, a message, money), let the AI build a draft the person reviews and
+  confirms with the app's own button, rather than act at once. Confirming is the app's policy for that change; it isn't
+  what makes the arguments safe, `check` is.
+- Not on a phone away from the Mac: actions need Lamp, and `status(.act)` says so there.
+
+A web page's `LampAI.act` is the same contract in lamp.js: the web-app skill's "Doing things for the person".
+
+## Decisions
+
+When the app has to judge things by what they mean, decisions are the tool. `LampAI.isTrue`, `LampAI.choose`,
+`LampAI.rate` and `LampAI.decide` call a decision model (Jev) that is smart, very fast (well under a second) and
+extremely cheap (about $0.04 per million input tokens: judging hundreds of items costs a fraction of a cent). In an app
+whose AI was asked for or accepted, where it sorts, filters, labels, prioritizes, groups, matches, routes, moderates or
+flags things by what they are or mean (file names, messages, notes, titles, descriptions, what the person meant), use
+one rather than keyword lists, regexes, extension rules or other hand-written heuristics that guess at meaning. In an
+app without AI, judging by meaning is a reason to offer it (above), not to add it. Where an exact rule
+decides it (a size, a date, a type the system reports), that's code, not a decision. It's fine to judge every item
+individually.
+
+To judge a list, hand the whole list to `LampAI.isTrue(_:each:)`, `LampAI.choose(_:from:each:)`,
+`LampAI.rate(_:levels:each:)` or, for several questions per item, `LampAI.decideEach(items, questions)`: they run
+about 12 at a time, keep the order, report `progress: { done, total in }` on the main thread and return one
+`LampVerdict` per item (`item`, `probability` / `choice` / `score` / `confidence`, and `error` for an item that
+couldn't be judged). Pass `remember: seconds` to save verdicts so unchanged items aren't judged again until they
+expire (e.g. a week for files, a day for messages). Never write your own TaskGroup, loop, progress counter or verdict
+cache for this. Ask several questions about one thing in one `decide` call. Use code for exact facts (sizes, dates,
+duplicates, arithmetic) and combine them with decisions: pass the facts in as part of the state. Use the returned
+probabilities and confidence to choose between acting automatically, suggesting, and asking the user. Decisions take
+text or JSON-friendly data, not images.
+
+## Untrusted text
+
+Text the person didn't type into the app themselves is untrusted: emails, messages, notifications, web pages, file
+contents, the clipboard, anything read from another app. It can contain instructions aimed at the AI ("ignore the
+above and…"). Never interpolate it into a prompt: pass it as `data:` (`LampAI.ask("Summarize this email in one
+line.", data: email.body)`), and Lamp fences it off so the AI works on it without obeying it. In decisions it goes in
+`about:`, with the question in your own words. Don't write regexes, keyword filters or "sanitizing" code against it.
+Fencing helps the AI read it as material rather than orders, but it is no guarantee: what the app does with an answer
+is held by the app's own code, a write's `check`, ids looked up again, the person's review of anything consequential.
+
+## Dates and times
+
+`LampAI.ask` already tells the AI the current date, time and time zone, so don't add them yourself. Give the AI a
+date with `LampAI.when(date)` (it writes "Mon 5 Oct 2026 at 15:00 (in 44 minutes)", with the distance worked out in
+code); Dates inside `about:` are written that way automatically. Get a date back by asking for ISO 8601 and decoding
+into a `Date` property with `ask(..., as:)`, or with `LampAI.date(from:)`. Always keep the `Date` itself and work out
+"in 44 minutes", "overdue" or "ended" in code when it's shown (`Text(date, style: .relative)` or a TimelineView keeps
+it current); never store or display a relative time the AI wrote, because it's wrong minutes later.

package/Resources/skills/app-intents/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: app-intents
+description: Giving the app's main actions to Siri, Shortcuts, Spotlight and the Action button with App Intents - the intent structs, AppShortcuts phrases, entities, what the build needs, and what to tell the person. Read before writing or changing Sources/Intents.swift.
+---
+
+# App Intents
+
+## Writing them
+
+In Sources/Intents.swift, `import AppIntents` and write a struct per action: `struct AddItemIntent: AppIntent` with
+`static let title: LocalizedStringResource = "Add Item"`, its inputs as `@Parameter(title: "Item") var item:
+String`, and `func perform() async throws -> some IntentResult & ProvidesDialog` that does the work with the app's own
+code (LampStore and the rest: it runs in the app, started without a window when it isn't open) and ends
+`return .result(dialog: "Added \(item)")`; `static let openAppWhenRun = true` only for one that has to show the app.
+
+Then one `struct AppShortcuts: AppShortcutsProvider` whose `static var appShortcuts` lists them,
+`AppShortcut(intent: AddItemIntent(), phrases: ["Add an item to \(.applicationName)"], shortTitle: "Add Item",
+systemImageName: "cart")`: that is what Siri hears and Spotlight and Shortcuts show with no setup. Every phrase names
+`\(.applicationName)`, and a phrase can name only a parameter that is an `AppEnum` or `AppEntity`, never a String. For
+the app's own things (lists, notes, places), an `AppEntity` with an `EntityQuery` lets Shortcuts pick one.
+
+Titles and phrases are plain literals: the build reads them from the code and fails on what it can't read.
+
+## Checking and telling the person
+
+When the build warns that Xcode isn't installed, the app works but the system doesn't see its intents: say so.
+Nothing here can run an intent, so check that the build succeeds and that what perform calls works in the app, then
+tell the user in a sentence what to say to Siri or search for.
+
+A Mac app's App Intents work when Lamp signs it for the user's Apple developer team; when it can't, `look_at_app`
+says so, and you tell the user how to turn them on as it says.

package/Resources/skills/app-kinds/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: app-kinds
+description: How each kind of app (tool, companion, collection, dashboard, canvas, utility, game or toy) is laid out, looks and talks on a Mac and on iPhone, made natively or as a web app, and on a Mac where the app works - a window, or a utility that works where the person already is. Read before writing a new app or changing an app's kind.
+---
+
+# The kinds of app
+
+Everything the person didn't say about the look follows the app's kind; their own direction always wins over it. A
+style they gave wins over the kind's look but keeps its structure: a "cozy" water tracker is a companion app, made
+cozy. Every kind feels like Apple made it, following the Human Interface Guidelines of the app's platform. Put the
+kind in APP.md's first line (`Kind: companion`), and never name kinds to the person.
+
+What follows names SwiftUI's pieces. A web app is laid out the same way in HTML and CSS: the system font
+(`-apple-system, system-ui`), light and dark (`prefers-color-scheme`), a grid of cards for LazyVGrid, a side panel for
+an inspector, a sheet as a dialog over the page, a chart drawn in SVG, symbols as small SVG icons kept in Web/, and a
+spring as a CSS transition. A menu bar icon, a widget and a haptic are native code's (the web-or-native skill).
+
+## On a Mac: where the app works
+
+Before the kind, decide where the app works. A utility that works where the person is or in the background, and a
+menu bar app, are made natively (the web-or-native skill).
+
+- When the wish acts on something the user already has in front of them in another app (the text they selected, the
+  post or message they're writing there, the file or page they're looking at), don't make a window to paste or drop
+  it into: make a utility that works where they are. A `LampHotKey` takes the selection: read it from the focused
+  element through Accessibility (kAXFocusedUIElementAttribute, then kAXSelectedTextAttribute; `LampPermissions` asks
+  for Accessibility), and when that gives nothing, send ⌘C and read the clipboard, putting back what was on it. Show
+  the result in a small floating panel that doesn't take focus from their app (an NSPanel with `.nonactivatingPanel`
+  at `.floating` level, near the mouse) with the one or two actions that make sense (put it back in place by pasting,
+  copy, save), or put it straight back in place when that's what they asked for; the menu bar icon holds the
+  settings, where the shortcut can be changed.
+- When the wish waits or watches for something (a folder, a time, the calendar, a site, the clipboard), it's a
+  utility too: it works in the background and reaches the user with a notification, never a window they must open
+  to check. Such a utility declares `{"background": true}` in `capabilities.json` at the app's root: then it opens at
+  login and keeps running, and Lamp tells the user so (don't explain it yourself; put Open at Login in its Settings
+  so they can turn it off). What runs at a time or every so often uses `LampSchedule`.
+- A window is for what the user brings things to and comes back to: writing, collecting, browsing, playing.
+- Collecting from wherever the user finds things (recipes from any website, articles, quotes, products) is both: the
+  window to keep and find them in, and a way to save from where they are without coming to the window: a hotkey that
+  takes the page or selection in front of them (the current tab's address from Safari, Chrome or Arc through
+  AppleScript, or the selected text) and saves it with a brief floating confirmation, besides dropping or pasting a
+  link.
+
+A menu bar app is written as the menu-bar skill says.
+
+## Tool
+
+Notes, inventory, lists, logs, a CRM: keeping and finding things. The base design in your rules, exactly. Dense and
+calm: system colors, the accent color, SF Symbols, no illustration. It's judged on how fast things are found, added
+and changed.
+
+## Companion
+
+Water, a timer, habits, mood, a plant, breathing: a small ritual come back to many times a day.
+
+- One main screen built around one picture of where you are now (the glass, the timer, the plant), not a list or a
+  sidebar; history is one step away. That picture is art from `make_art`, never shapes drawn in code, and it always
+  shows the state: animate it (fill it with a mask, grow, move or scale it), never a static picture beside a progress
+  bar.
+- A palette of two or three colors that suit the subject, as named colors with light and dark versions; text and
+  controls keep system colors. The one number that matters is large (.largeTitle or bigger, .rounded design).
+- The main action is one big, obvious button or a tap on the picture, with a spring animation (on iPhone, and a
+  haptic: sensoryFeedback); something small and pleasant happens when a goal is met, and nothing nags.
+- Short, warm words with a little personality ("Nice. Two to go."), never at the cost of clarity.
+- Reminders come as notifications; on a Mac it also shows its state in the menu bar (LampMenuBar with
+  `dockIcon: true`, its label the time left or the count).
+- One first screen is allowed when the app can't work without a choice (a daily goal), with a sensible default
+  filled in; never a tour.
+
+## Collection
+
+Recipes, books, wines, trips, records: things nice to look at. Pictures lead, in an adaptive grid of cards
+(LazyVGrid) with large images and titles under them; a list as an option, not the default. The detail is a full page
+with a large picture at the top and the facts below, like an album in Music. Every item has a picture: the user's own
+photo, or else art from `make_art` for the kind of item, so the grid is never gray placeholders; the empty state
+shows some of that art too, so a new app doesn't open on a blank page. Search, sort and filter as Photos does
+(toolbar menus, scopes), not as a form.
+
+## Dashboard
+
+Spending, fitness totals, a server's status: look, understand, leave. The one or two numbers that matter come first
+and large, details below. Swift Charts for anything over time, kept simple: no grid clutter, the latest point marked,
+values labeled where they matter. Color means good, warning or bad and nothing else; a soft gradient from the state
+behind the main number is the only decoration. No art. On a Mac, when it's checked often, a menu bar icon shows the
+main number.
+
+A dashboard on a TV, glanced at from across a room (a family calendar or chore board, a scoreboard, a photo frame), is
+designed as the tv-design skill says.
+
+## Canvas
+
+Drawing, diagrams, layout, long writing: making a thing. A minimal interface with the content front and center.
+
+- On a Mac: a larger toolbar (labels under the icons where there's room) holds the tools, never a palette drawn on
+  the canvas; settings for the selection go in an `.inspector`, hidden when nothing is selected. Proper windows:
+  DocumentGroup with a window per document, tabs, full screen, and a focus mode that hides the toolbar and inspector.
+- On iPhone: the canvas goes edge to edge; tools in a bottom toolbar, settings for the selection in a sheet with
+  detents (an inspector on iPad), and a tap on empty canvas hides the chrome. DocumentGroup for documents.
+
+Undo for everything, autosave, export; every gesture (drag, resize, pinch) also has a command or button. No art: the
+user's work is the only thing to look at.
+
+## Utility
+
+A clipboard history, automations, a folder watcher: works while you do other things. Quiet: a notification only when
+something needs the user.
+
+- On a Mac it lives in the menu bar (LampMenuBar) with a Settings window, and has no main window unless it has
+  something to show. When it has one main thing to turn on and off (pause syncing, keep awake, watch the folder), a
+  click on the icon does it, the icon shows the state with two clearly different symbols, and a right-click shows the
+  menu (LampMenuBar's switch). Otherwise a click shows a menu (LampMenuBar(menu:)). Prefer a menu, with toggles as
+  checkmarks, to a panel; a panel only for what a menu can't do (a search field over a long history, a preview, a
+  slider you watch while dragging).
+- On iPhone it does its work through App Intents (Shortcuts and Siri) and the share sheet wherever it can, and the
+  app itself is one screen: its settings and what it did recently.
+
+## Game or toy
+
+Played rather than used: fully custom, with no standard chrome while playing; pause, settings and scores are standard
+and large. SwiftUI animation for the simplest toy in a native app. Anything played in real time is a game, made web
+by default wherever Lamp has a host for a page (the web-or-native skill): open the game skill, which says what it's
+drawn with and has its controls, sound, saves and smoothness for each way it's made.

package/Resources/skills/apple-watch/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: apple-watch
+description: The app's Apple Watch app and its complications (Watch/) - the watch app, complications on a watch face, the data the phone shares with them, taps sent back to the phone, and workouts saved to Health. Read before writing or changing anything in Watch/.
+---
+
+# An Apple Watch app with complications
+
+## The watch app
+
+Write it in SwiftUI in a `Watch/` folder at the app's root, starting with Watch/WatchApp.swift: one `@main` App whose
+WindowGroup ends in `.lampWatch()`, which keeps complications current while the watch app is closed, and a screen or
+two of big controls. The watch app's icon is the app's.
+
+## Complications
+
+They go in Watch/Complications/: one `@main` `WidgetBundle` of `StaticConfiguration`s with `.supportedFamilies` from
+`.accessoryCircular`, `.accessoryRectangular`, `.accessoryInline` and `.accessoryCorner`, and
+`.containerBackground(.fill.tertiary, for: .widget)`.
+
+Neither the watch app nor its complications share code with Sources/ or have LampSupport.swift: declare the Codable
+types they read in each folder. Watch/LampWatchSupport.swift and its copy in Complications/ are Lamp's: never edit
+them.
+
+## The data
+
+- In the app, `LampWatch.share(Today(…), as: "today")` at launch and whenever it changes.
+- On the watch, `@LampWatched("today") var today: Today?` in a view, or `LampWatch.read(Today.self, from: "today")` in
+  a complication's timeline, nil until the phone has first shared.
+- A tap on the watch: `LampWatch.send("addGlass", 1)`, done in the app by `LampWatch.onAction { name, payload in … }`
+  set at launch (`payload.decode(Int.self)`), which shares what changed.
+
+## Workouts
+
+A workout on the watch, saved to Health with heart rate, calories and distance: `@StateObject private var workout =
+LampWorkout()` from Watch/LampWatchSupport.swift, `try await workout.start(.running)`, `pause()`, `resume()`,
+`await workout.end()`, with `{"healthkit": true}` in capabilities.json. The simulator's watch measures nothing, so
+check it starts and ends.
+
+## Trying it and saying so
+
+Lamp opens the watch app on an Apple Watch simulator beside the iPhone; `look_at_app` and `use_app` see only the
+iPhone, so don't try them on the watch. Say in a sentence that it's on the watch, and that a complication is added by
+editing a watch face.