@agent-native/core 0.141.7 → 0.144.1

package/corpus/templates/plan/.agents/skills/turn-into-app/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: turn-into-app
+description: >-
+  Turn a proven thread, skill, or workflow into a runnable Agent-Native app
+  with simple buttons, visible agent steps, preview, and deployment handoff.
+  Use when a user invokes `/turn-into-app` or asks to make a workflow into an
+  app.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into App
+
+## Default behavior
+
+This is an end-to-end build skill, not a request for an app proposal.
+
+- With no argument, use the current thread as the source. This is the normal
+  invocation at the end of a successful workflow.
+- With a named skill or local workflow, read that source and package it
+  immediately, even at the beginning of a thread. For example,
+  `/turn-into-app /some-skill` means “turn `/some-skill` into an app.”
+- With an attachment or path, read the supplied artifact as the source.
+- Do not ask the user to restate context that is already in the thread.
+- When invoked from an Agent-Native app, keep the current thread as the source
+  and use the available workspace/coding-agent handoff when the current runtime
+  cannot edit files. Do not claim the app exists without an actual path and
+  verification result.
+
+## Source support
+
+Supported source paths today are the current Codex thread, a named skill, or a
+local workflow/transcript supplied as a path or attachment. An exported
+ChatGPT or Claude transcript can use the same local-file path today.
+
+ChatGPT shared-conversation import and Claude web conversation/project import
+are **coming soon**. Do not claim private web access, invent an importer, add
+fake OAuth, or scrape a logged-in page without an explicit supported adapter.
+If a user gives one of those URLs before an adapter exists, ask for an export or
+transcript instead and treat it as imported source material.
+
+Deliver a fresh app in a new directory, implement the repeatable workflow with
+buttons and agent handoffs, start its dev server, verify the main path, and
+continue through build/deployment handoff. Do not stop at a plan.
+
+## Source selection guard
+
+The generated app must implement the concrete workflow found in the source. It
+must not become a generic “what app do you want to make?” intake form.
+
+- In a delegated or forked task, read the actual referenced source thread and
+  the latest explicit workflow direction in the current task. If they disagree,
+  the latest concrete workflow direction wins.
+- Do not treat a thread that merely discusses building this skill as the product
+  source unless the user explicitly asks to appify that meta-workflow.
+- If the source contains several workflows, choose the latest successful,
+  repeatable job that motivated the request and name it in the handoff. If no
+  concrete job can be identified, stop and report what is missing instead of
+  inventing an app-builder UI.
+
+## UI contract for generated apps
+
+Generated apps must follow the shared Agent-Native surface model:
+
+- Keep the domain workflow on a named route (`/workflow`, `/automations`,
+  `/block`, or the source's equivalent). Preserve the scaffold's full-page
+  chat route instead of replacing it with a domain form while leaving the
+  layout configured as a chat page.
+- Use the right `AgentSidebar` for contextual AI. Every button-triggered
+  `sendToAgentChat` handoff should open or focus that sidebar and keep the user
+  on the current domain page.
+- Use a sans-first SaaS hierarchy for the app shell. Choose a named visual
+  direction in `DESIGN.md` before styling: product mode, audience, palette
+  family, type treatment, composition, shape language, and anti-references.
+  One restrained editorial cue is welcome, but warm beige plus terracotta is
+  not the default and serif type belongs in content previews or a deliberate
+  brand moment rather than the whole tool.
+- Preserve existing brand tokens. For a new unbranded app, choose a
+  product-fitting palette family and compare sibling apps before reusing their
+  accent. Keep shared semantic tokens and Agent-Native behavior consistent
+  while varying the visual world, density, composition, and shape language.
+- Give the AgentSidebar a subtle surface or divider boundary so it is visually
+  distinct from the domain page without becoming a heavy panel wall.
+- Every AI-labeled button must actually call `sendToAgentChat` with bounded
+  context and `openSidebar: true`. Keep `submit: true` for direct execution and
+  `submit: false` only when the user should edit the staged prompt first. Label
+  deterministic local actions as local, preview, or analyze instead of AI.
+- Standalone apps that render `AgentSidebar` must keep one assistant-ui runtime
+  context. Pin the versions compatible with the installed core/toolkit peer
+  graph, and add Vite dedupe/aliases when linked or transitive packages resolve
+  duplicate assistant-ui modules. Verify a fresh AI handoff has no
+  `AssistantUiStaleIndexErrorBoundary` or stale-index console error.
+- Make the left navigation describe domain destinations. Chat is a separate
+  destination, not the label for every app page.
+- Start with one primary action and one compact state. Put setup choices,
+  advanced inputs, diagnostics, and long explanations behind progressive
+  disclosure or later workflow steps.
+- Never use sparkle, wand, magic, robot, or similar decorative AI icons. Use a
+  message or neutral action icon, or no icon when the button label is enough.
+- Before handoff, inspect the first viewport for text density, repeated cards,
+  unrelated forms, and generic helper copy. Remove what the user does not need
+  until the next decision.
+- Run a `distill`, `typeset`, `colorize`, `layout`, `polish`, and `audit` pass
+  as useful named reviews. Make one intervention at a time and commit the
+  chosen direction rather than averaging several options into generic SaaS.
+- For before/after or original/generated review, stack the source first and the
+  result second by default. Reserve side-by-side layouts for short content that
+  remains comfortable to scan at the target width.
+
+## 1. Extract the workflow
+
+Read the full available source before coding. Reduce it to a short working
+brief:
+
+- the user and repeatable job;
+- inputs and outputs;
+- the 1-3 judgment-heavy agent moments;
+- the buttons, review points, and retry states a user needs;
+- data, permissions, integrations, and failure boundaries.
+
+Preserve useful judgment from the source, but do not turn a one-off answer,
+private data, or an unverified result into a product contract. If the source is
+not available or does not contain a repeatable job, say what is missing rather
+than claiming the app is complete.
+
+## 2. Create a fresh app
+
+Choose a short slug from the workflow and create a new directory. Never
+overwrite an existing app. If the user supplied a directory, use it; otherwise
+use `apps/<slug>` inside an existing Agent-Native workspace, or a new sibling
+directory when working outside one.
+
+For a new UI-bearing standalone app, use the current Agent-Native scaffold and
+then read the generated `AGENTS.md`:
+
+```bash
+npx @agent-native/core@latest create <app-directory> --template chat
+cd <app-directory>
+pnpm install
+```
+
+When working inside an existing Agent-Native workspace, create the app from
+the workspace root instead:
+
+```bash
+pnpm exec agent-native add-app <slug> --template=chat
+```
+
+Do not use `create` for an existing workspace; it scaffolds a new standalone
+workspace rather than adding an app to the current one.
+
+Use a first-party template only when it materially fits the workflow. Keep the
+new app independent from the source thread's working tree unless the user
+explicitly asks to extend an existing app.
+
+Read the generated `DESIGN.md` before building the first screen and fill in the
+visual direction as part of the app brief. Do not copy the previous app's
+palette just because its tokens are nearby.
+
+## 3. Turn the workflow into buttons and agent work
+
+Implement the smallest useful surface around the extracted brief. The app
+should make the repeated path obvious without hiding the agent's judgment:
+
+- Give each important repeated moment a clear button, such as “Analyze,”
+  “Suggest options,” “Draft,” “Review,” or “Publish.” Use the source's actual
+  vocabulary when it is clear.
+- Put deterministic reads, writes, approvals, and publishing in `actions/`
+  with `defineAction`. The UI and agent must call the same action surface.
+- Use application state for the current screen, selected item, and focused
+  object so the agent can see where the user is.
+- Use `sendToAgentChat({ message, context, submit: true })` for intentional
+  button-triggered agent work. Use `submit: false` when the user should review
+  or edit the proposed prompt first.
+- Pass IDs, URLs, and bounded summaries in context. Do not paste large provider
+  dumps into prompts, call an LLM directly from the browser, or invent fake
+  progress.
+- Make agent results visible, editable, retryable, and attributable. Keep
+  irreversible actions behind an explicit review or confirmation point.
+
+Use the existing shadcn/ui primitives, Tabler icons, shared composer, and
+optimistic action patterns. Do not add a parallel CRUD API route for an action.
+
+## 4. Keep onboarding shared
+
+Use the framework's existing setup experience. The app should offer the normal
+“Connect Builder” and “Add your own keys” paths for AI setup. Do not create a
+second credential form or hardcode a provider key.
+
+In local-development instructions, add a brief note that a developer can set
+an environment variable such as `ANTHROPIC_API_KEY` or `OPENAI_API_KEY` before
+starting the app; after restart, the setup prompt is no longer shown when the
+key is available. Keep real secrets out of source, examples, and generated
+content.
+
+Turn-into-app apps should commit an `agent-native.json` app configuration so a
+plain `pnpm dev` has the right first-run behavior without extra flags:
+
+```json
+{
+  "version": 1,
+  "onboarding": {
+    "firstRun": {
+      "development": "connect",
+      "production": "connect-and-integrations"
+    }
+  }
+}
+```
+
+`connect` keeps the Connect Builder / Add your own keys choice visible and
+skips only the generic “This app is an agent.” integrations catalog. The
+production value includes that catalog for a hosted app. Do not replace this
+with a local credential form or remove the shared onboarding. In development,
+the shared Connect Builder card also explains the deployment-level
+`ANTHROPIC_API_KEY` / `OPENAI_API_KEY` fallback and links to the full
+environment-variable guide.
+
+When the onboarding default needs code rather than a static mode map, add an
+optional `agent-native.config.ts` with the same returned shape:
+
+```ts
+import { defineAgentNativeConfig } from "@agent-native/core/config";
+
+export default defineAgentNativeConfig(({ isDev }) => ({
+  version: 1,
+  onboarding: {
+    firstRun: isDev ? "connect" : "connect-and-integrations",
+  },
+}));
+```
+
+The Vite preset loads this file automatically on supported Node versions. The
+JSON file remains the portable, inspectable fallback. See the [Agent-Native
+app configuration guide](/docs/agent-native-config) for precedence, supported
+modes, and the boundary between committed config and deployment secrets.
+
+For an account-free local preview, create the ignored local `.env` file with
+`AUTH_DISABLED=1` before starting the dev server. This is only for loopback
+development; never commit or deploy this setting. AI/provider connections still
+use the normal onboarding flow or the documented environment-variable keys.
+
+## 5. Run it immediately
+
+From the new app directory:
+
+```bash
+pnpm dev
+```
+
+For a fresh local test app, use the ignored `.env` with `AUTH_DISABLED=1` so the
+domain UI opens without an account; the committed app config makes shared
+onboarding visible. Keep the process running so the user can try the app. Read
+the actual server output and report the real local URL. If the app needs installation or a setup step,
+complete it when possible and distinguish “not configured” from an unavailable
+credential store.
+
+## 6. Verify, build, and deploy
+
+Exercise the actual happy path, not only the source files:
+
+1. Load the reported URL and confirm the main route renders.
+2. Confirm the shared onboarding state or a configured local key.
+3. Click the primary workflow button and confirm the intended agent handoff.
+   Also click every other AI-labeled button and confirm it opens the same
+   contextual sidebar with the expected prompt or staged context.
+4. Confirm the result, action persistence, application state, and sync path.
+5. Check the dev output for browser/runtime errors, and capture input, result,
+   and agent-sidebar states so the complete flow is reviewable.
+
+Then run the supported build. For a standalone app, use the generated app's
+documented build and hosting path. For an app inside a workspace, use the
+workspace deploy command, for example:
+
+```bash
+npx @agent-native/core@latest build
+npx @agent-native/core@latest deploy --preset netlify
+```
+
+Use `vercel` or another supported preset when that is the configured target.
+Attempt deployment when the user requested it or the project already has the
+required provider configuration. If external authentication, a production
+secret, or a hosting decision is missing, finish local verification and report
+the exact remaining handoff without claiming a live deployment.
+
+Label evidence separately: locally running, locally verified, build-ready,
+deployed, and live-verified are different states.
+
+## Handoff
+
+End with the new app directory, local URL, visual direction, what the buttons do,
+account-free local-preview status, verification performed, deployment URL if it is real,
+and one precise pending step when something could not be completed. Keep the
+handoff short enough to use in a demo or recording.

package/corpus/templates/plan/.agents/skills/turn-into-app/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into App"
+  short_description: "Turn a thread or skill into a runnable app"
+  default_prompt: "Scan the current thread, turn the workflow into a new Agent-Native app with clear buttons, run it locally, verify it, and complete the deployment handoff."

package/corpus/templates/plan/.agents/skills/turn-into-skill/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: turn-into-skill
+description: >-
+  Capture a proven thread or workflow as a reusable Agent-Native skill and save
+  it as a personal or organization resource. Use when a user invokes
+  `/turn-into-skill` or asks to save a workflow for reuse.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into Skill
+
+This is a packaging-and-save workflow, not a request for a proposal. A skill
+is the lightweight path for a repeatable job that mostly needs guidance and
+existing app actions. Use `turn-into-app` when the job needs a dedicated UI,
+new persistent domain state, or a distinct app route.
+
+## Default behavior
+
+- With no argument, use the current thread as the source.
+- With a named skill, local workflow, transcript path, or attachment, read that
+  source and package it immediately.
+- Do not ask the user to restate context already present in the source.
+- Default to a personal skill unless the user explicitly asks for a team,
+  organization, or all-app skill, or passes `shared` as the scope.
+- If the current thread only discusses creating a skill, do not package that
+  meta-workflow unless the user explicitly asks for it.
+- Treat an explicit `/turn-into-skill` invocation as authorization to save the
+  resulting skill, but never overwrite an existing skill at the target path
+  unless the user clearly asks to update it.
+
+## 1. Extract the repeatable workflow
+
+Read the full source before writing. Reduce it to a concise working brief:
+
+- the repeatable job and the user outcome;
+- when the skill should trigger;
+- required inputs, context, permissions, and integrations;
+- the ordered steps and the one to three judgment-heavy decisions;
+- expected outputs, verification, retry, and failure boundaries.
+
+Preserve the useful judgment from the source, not its transcript. Do not turn
+one-off answers, private data, customer data, secrets, or unverified claims into
+the skill's contract. If no repeatable job can be identified, stop and report
+what is missing instead of inventing generic guidance.
+
+## 2. Author the skill
+
+Create a single `SKILL.md` with:
+
+- a short hyphen-case name and a description under 40 words that says what the
+  skill does and when to use it;
+- `user-invocable: true` so it can be selected from the app's `/` picker;
+- `scope: both` so the saved skill can guide the app runtime and connected
+  coding agents;
+- concise sections for purpose, trigger, inputs, workflow, verification, and
+  failure or retry behavior.
+
+Write imperative, reusable instructions. Keep exact action names, field rules,
+and decision criteria when they matter. Use placeholders for credentials and
+provider data. Do not paste the source transcript, large dumps, or ephemeral
+thread details into the saved skill.
+
+Choose a new slug when the target path already exists. Read an existing skill
+before changing it, and update it only when the user explicitly requested an
+update.
+
+## 3. Save at the requested scope
+
+Skills are resources at `skills/<slug>/SKILL.md`.
+
+| User intent | Save path |
+| --- | --- |
+| Just me or personal reuse | Use the `resources` tool with `action: "write"`, `scope: "personal"`, `visibility: "workspace"`, and the generated skill content. |
+| Shared organization or app reuse | Use the `resources` tool with `action: "write"`, `scope: "shared"`, `visibility: "workspace"`, and the generated skill content. |
+| Every workspace app | Use `create-workspace-resource` with `kind: "skill"`, `scope: "all"`, the generated path, name, description, and content. |
+| Only selected apps | Use the workspace resource flow with `scope: "selected"` only when the user names the app set. |
+
+For an all-app workspace skill, use the workspace resource action when it is
+available. If the current app does not expose it, discover or delegate to the
+configured Dispatch workspace agent. Do not silently save a personal skill and
+report it as shared. If organization approval is queued, report that the skill
+is pending approval rather than claiming it is active.
+
+Set `visibility: "workspace"` for an explicitly requested saved skill. Use
+`agent_scratch` only for temporary drafting, then promote or rewrite it before
+reporting the skill as saved.
+
+## 4. Verify and hand off
+
+After saving, read the exact `skills/<slug>/SKILL.md` resource back at the
+target scope. Confirm that the frontmatter name, trigger description, and full
+workflow body are present. If the read-back fails or the save returned an
+approval request, say so plainly and include the actual pending state.
+
+Report:
+
+- the skill name and path;
+- whether it is personal, organization-wide, or selected-app;
+- the trigger users can invoke from `/`;
+- the verification result and any approval or setup still required.
+
+## Related skills
+
+- `turn-into-app` — package the same source as a UI-bearing app with buttons,
+  agent handoffs, and a domain workflow.
+- `create-skill` — general skill format and authoring rules.
+- `capture-learnings` — lightweight memory for preferences and corrections,
+  rather than reusable workflows.
+- `self-modifying-code` — safety boundaries when the agent edits app source.

package/corpus/templates/plan/.agents/skills/turn-into-skill/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into Skill"
+  short_description: "Save a proven workflow as a reusable skill"
+  default_prompt: "Read the current thread, distill the repeatable workflow into a concise user-invocable skill, save it at personal or organization scope, verify the saved resource, and report its path."

package/corpus/templates/slides/.agents/skills/create-deck/SKILL.md

@@ -1,11 +1,16 @@
 ---
 name: create-deck
-description: How to create a new deck with slides from scratch. Read this before creating any deck. Contains exact HTML templates for every slide layout — no codebase exploration needed.
+description: >-
+  Create a new deck with slides from scratch. Use before creating a deck or
+  standalone visual; resolve source fidelity, creative context, and the active
+  design system before using the fallback HTML patterns in this skill.
 ---
 
 # Creating a Deck
 
-**Do not explore the codebase.** Everything you need is here.
+**Do not explore the codebase for routine deck creation.** Use the app actions
+and linked skills. This does not override the active design system, Creative
+Context, reference deck, or source material that the app already provides.
 
 ## Workflow
 
@@ -34,6 +39,26 @@ step from generation. Persist the immutable `contextPackId` and concise reuse
 labels with the deck's generation provenance; never infer provenance later from
 rendered slide HTML.
 
+## Direction and source checkpoint
+
+Before authoring slide HTML, make a compact deck brief with the audience, job,
+narrative thesis, one-sentence visual direction, active design-system tokens,
+reference-deck composition pattern, image treatment, and known fit risks. The
+linked Agent-Native design system controls tokens, typography, spacing, imagery,
+and slide chrome. Impeccable-inspired advice about hierarchy, subtraction,
+contrast, and polish is a review lens, not a competing theme. If the request is
+open-ended and no approved direction exists, ask one targeted guided question
+or present a bounded choice before writing; do not silently pick a new brand
+language.
+
+When the source is a transcript or meeting notes, extract the audience's
+terminology, goals, objections, decisions, owners, dates, metrics, and open
+questions before outlining. Preserve exact names, numbers, dates, and requested
+quotes; retain speaker/source attribution; distinguish quotation, paraphrase,
+inference, and unresolved claim. Do not invent connective claims to make the
+story smoother. Keep factual evidence separate from visual references and
+record the source/version identifiers in provenance when available.
+
 When creative context is available, pass the pre-generation search result's
 `contextPackId` to `create-deck`, pass deck-wide `reuseLabels`, and add
 `creativeContextReuseLabels` to each slide that reused a specific item/version.
@@ -68,8 +93,10 @@ The block deliberately omits the reference deck's slide sequence. Call
 case the patterns do not cover.
 
 A reference deck and a design system are independent: the design system wins on
-tokens (color, type, spacing), the reference deck wins on slide-level
-composition and markup idiom. Apply both when both are present.
+tokens (color, type, spacing, imagery, and slide defaults), the reference deck
+wins on slide-level composition and markup idiom. Apply both when both are
+present. Generic templates in this skill are fallback patterns only. Never let
+a reference screenshot or deck silently transfer its brand tokens.
 
 Decks the user has starred are their intended reference decks. `list-decks`
 reports `starred` so you can offer them when the user asks for something "like
@@ -122,11 +149,17 @@ pnpm action add-slide --deckId=<id> --layout content --content "..."
 Every slide's `content` must use this exact outer div:
 
 ```html
-<div class="fmd-slide" style="padding: 80px 110px; display: flex; flex-direction: column; justify-content: flex-start; font-family: 'Poppins', sans-serif;">
+<div class="fmd-slide" style="padding: 80px 110px; display: flex; flex-direction: column; justify-content: flex-start; font-family: var(--ds-body-font, sans-serif);">
   <!-- slide content here -->
 </div>
 ```
 
+The literal values in the examples below are fallback values for a deck with no
+linked system. When a system is linked, use its hydrated values or the renderer
+variables (`--ds-accent`, `--ds-bg`, `--ds-text`, `--ds-text-muted`,
+`--ds-heading-font`, `--ds-body-font`, `--ds-radius`) instead of copying
+Poppins, cyan, white, black, or a stock radius into new markup.
+
 ## Fit budget
 
 The canvas is fixed at its aspect-ratio dimensions. With the standard 16:9
@@ -141,6 +174,16 @@ when the saved HTML is rendered.
 
 Background is pure black (`bg-[#000000]`) — set by the renderer, not the slide HTML.
 
+## Bounded visual QA
+
+Before calling the deck complete, render every changed slide at its canonical
+aspect-ratio dimensions and make one batched review pass. Check hierarchy and
+source fidelity, overflow or clipping, contrast, minimum readable text,
+placeholder remnants, broken or missing images, asset fit, and preserved
+`data-slide-object-id` values. Fix the findings in one correction pass and
+recheck. Do not claim full-deck or pixel-perfect fidelity unless the whole deck
+was rendered and compared.
+
 ## Ready-to-Use Templates
 
 Copy and fill in the bracketed values. Use `\` to escape quotes inside the JSON string.

package/corpus/templates/slides/.agents/skills/design-systems/SKILL.md

@@ -1,7 +1,30 @@
+---
+name: design-systems
+description: >-
+  Apply, inspect, or create slide design systems. Use before generating or
+  restyling slides when colors, typography, spacing, imagery, or slide defaults
+  need to be resolved.
+---
+
 # Design Systems
 
 Design systems store brand identity tokens (colors, fonts, spacing, logos) that are applied to all slides in a deck.
 
+## Precedence
+
+The active linked design system is the source of truth for slide tokens,
+typography, spacing, imagery, and custom CSS. Resolve it before authoring HTML.
+An explicit user accessibility or brand constraint can change the direction;
+do not silently detach or replace the system. Then apply the following layers:
+
+1. Explicit current-turn content and brand constraints.
+2. The explicitly selected, personal, or workspace design system.
+3. Approved Creative Context assets and a reference deck's composition patterns.
+4. Generic create-deck and slide-editing examples as fallback only.
+5. Impeccable-inspired guidance as a bounded review lens for hierarchy,
+   subtraction, contrast, density, and polish, never as a replacement palette
+   or component grammar.
+
 ## Data Model
 
 Design systems are stored in the `design_systems` SQL table. Each has a `data` column with JSON tokens:
@@ -95,13 +118,26 @@ compose approved pieces, lightly adapt a real example, generate from narrow
 references, then net-new only when the corpus is empty. A context pack is an
 immutable generation snapshot, not a mutable design system.
 
-When generating slides, replace default values with design system tokens:
+When generating slides, read the hydrated system and write a compact deck-level
+visual direction before choosing a layout. Keep the system's tokens fixed while
+varying slide composition, hierarchy, and narrative to fit the source. Replace
+default values with design system tokens:
 
 - `#00E5FF` -> `colors.accent`
 - `Poppins` -> `typography.headingFont` / `typography.bodyFont`
 - `#000000` background -> `colors.background`
 - `rgba(255,255,255,0.55)` -> `colors.textMuted`
 
+The hardcoded values in the `create-deck` and `slide-editing` examples are
+fallbacks, not overrides. If a token is absent, use the nearest semantic token
+or a neutral fallback and record the gap; do not invent a new brand color or
+font without an explicit decision.
+
+Before calling a deck ready, render the changed slides and perform one bounded
+review for system consistency, hierarchy, contrast, overflow, missing assets,
+placeholder remnants, and editable-object preservation. Fix the batch once and
+recheck; do not claim brand fidelity from successful action responses alone.
+
 ## Tweaks
 
 The Tweaks panel provides live CSS variable overrides:

package/corpus/templates/slides/.agents/skills/image-generation-via-a2a/SKILL.md

@@ -59,6 +59,12 @@ grounding, the completed-vs-failed task handling, and the ready-to-render
 preview markdown this action returns — which is how image results end up in
 chat as bare links instead of visible images.
 
+Slides owns the semantic job of the image: its slide role, audience, crop, and
+must-preserve content. Assets owns library and preset selection, style anchors,
+generation settings, and provenance. Include the active design system's
+image-style guidance in the prompt context, but do not ask Assets to invent a
+competing brand direction.
+
 Drop the returned `previewUrl` into the slide HTML's `<img src="...">`.
 
 ## Showing the result in chat

package/corpus/templates/slides/.agents/skills/slide-editing/SKILL.md

@@ -1,6 +1,9 @@
 ---
 name: slide-editing
-description: How to edit individual slides -- content formatting, HTML styling rules, updating slide content in the database.
+description: >-
+  Edit individual slides, including content formatting, HTML styling, and
+  bounded source and visual-fidelity checks. Use when changing an existing
+  slide rather than creating a new deck.
 ---
 
 # Slide Editing
@@ -23,7 +26,13 @@ Every slide uses this wrapper:
 
 ## Styling Rules
 
-All generated slides follow these conventions:
+These are fallback defaults only. When a design system is linked, its hydrated
+tokens control color, typography, spacing, borders, imagery, and slide defaults;
+a reference deck controls composition and markup idiom only. The generic
+Impeccable-inspired quality bar can flag hierarchy, contrast, density, and
+anti-pattern issues, but it cannot replace the active system.
+
+When no system is linked, generated slides may use these conventions:
 
 | Element | Style |
 |---------|-------|
@@ -67,6 +76,10 @@ To edit a slide's content:
 5. For browser/editor code, enqueue granular deck operations through
    `patch-deck` / `DeckContext.tsx` instead of replacing the whole deck JSON.
 
+6. For factual edits, compare changed text against the retrieved source and
+   preserve quote, speaker, date, metric, and uncertainty status. Existing HTML
+   or visual similarity is not proof of source fidelity.
+
 If retrieval produces a new immutable context pack, keep its `contextPackId`
 and reuse labels with the deck provenance. Existing slide HTML is not proof of
 which source version influenced it.