@agent-native/core 0.145.5 → 0.145.7

package/corpus/templates/chat/.agents/skills/delegate-to-agent/SKILL.md

@@ -14,11 +14,21 @@ metadata:
 
 ## Rule
 
-The UI never calls an LLM directly. Product workflows are delegated to the
-agent through the chat bridge so users can see, steer, and audit the work.
-Server-side one-shot model calls are an explicit escape hatch for narrow text
-transforms only; use `completeText()` from `@agent-native/core/server` when the
-work intentionally does not need tools, chat history, or run state.
+The app's default AI surface is the agent chat. Any user-facing work that asks
+the model to research, analyze, generate, recommend, synthesize, or reason over
+multiple steps must start or continue in the AgentSidebar so users can see,
+steer, and audit the work. UI buttons use `sendToAgentChat()` with
+`openSidebar: true`, and follow-up or revision text belongs in that same thread
+instead of a second app-local textbox.
+
+Actions are tools, not alternate AI runtimes. Keep them deterministic and
+focused: provider reads, validation, deterministic transforms, CRUD, and
+persistence are good action work. Let the agent orchestrate several such tools
+when the workflow is AI-shaped or user-steerable. Server-side one-shot model
+calls are a rare escape hatch for narrow text transforms only; use
+`completeText()` from `@agent-native/core/server` only when the work
+intentionally does not need tools, chat history, run state, side effects, or
+user steering.
 
 ## Why
 
@@ -35,6 +45,7 @@ sendToAgentChat({
   message: "Generate a summary of this document",
   context: documentContent, // optional hidden context (not shown in chat UI)
   submit: true, // auto-submit to the agent
+  openSidebar: true,
 });
 ```
 
@@ -56,6 +67,10 @@ sendToAgentChat({
 This is still a full agent run: tools, actions, thread state, and run tracking
 all remain active. It simply does not focus or open the sidebar.
 
+Use this silent form only for explicitly background or system-initiated work.
+It is not the default for a user clicking an AI-labeled button; visible work
+should open the sidebar so the user can follow and redirect the run.
+
 **From scripts (Node):**
 
 ```ts
@@ -77,8 +92,9 @@ const result = await completeText({
 });
 ```
 
-Wrap user-facing uses in actions so the UI and agent share the same operation.
-Do not call provider SDKs directly.
+If the narrow exception is exposed to the UI, wrap it in an action so the UI
+and agent share the same operation. Keep it clearly non-conversational and do
+not call provider SDKs directly.
 
 **From the UI, detecting when agent is done:**
 
@@ -97,9 +113,9 @@ The `submit` option controls whether the message is sent automatically or placed
 
 | `submit` value | Behavior                                | Use when                                                                            |
 | -------------- | --------------------------------------- | ----------------------------------------------------------------------------------- |
-| `true`         | Auto-submits to the agent immediately   | Routine operations the user has already approved                                    |
-| `false`        | Prefills the chat input for user review | High-stakes operations (deleting data, modifying code, API calls with side effects) |
-| omitted        | Uses the project's default setting      | General-purpose delegation                                                          |
+| `true`         | Auto-submits to the agent immediately   | Routine operations with clear intent; keep `openSidebar: true` for visible work |
+| `false`        | Prefills the AgentSidebar composer      | Review, edit, or add detail before the run; use the existing sidebar thread   |
+| omitted        | Uses the project's default setting      | General-purpose delegation                                                       |
 
 ```ts
 // Auto-submit: routine operation
@@ -109,61 +125,43 @@ sendToAgentChat({ message: "Update the project summary", submit: true });
 sendToAgentChat({
   message: "Delete all projects older than 30 days",
   submit: false,
+  openSidebar: true,
 });
 ```
 
-## Capture user input first when generating from a prompt
-
-Buttons that produce new content ("New Design", "Create Dashboard", "Make Deck", "Generate Form") need the user's prompt as input. **Never hardcode a generic message** — the result will be a generic generation the user didn't actually ask for.
+## Capture user input in the sidebar
 
-**Bad** — auto-submits a placeholder message; the user never said what they wanted:
+The AgentSidebar composer is the default prompt surface. When a button needs
+the user to describe what to create, prefill that same composer and let the
+user edit or complete it:
 
 ```tsx
 <Button
   onClick={() =>
-    sendToAgentChat({ message: "make a design", submit: true })
+    sendToAgentChat({
+      message: "Help me create a research report from this brief:",
+      context: researchBrief,
+      submit: false,
+      openSidebar: true,
+    })
   }
 >
-  New Design
+  Start in agent
 </Button>
 ```
 
-**Good** — Popover anchored to the button captures the prompt, then submits it:
-
-```tsx
-<Popover open={open} onOpenChange={setOpen}>
-  <PopoverTrigger asChild>
-    <Button>New Design</Button>
-  </PopoverTrigger>
-  <PopoverContent className="w-96">
-    <Textarea
-      autoFocus
-      value={prompt}
-      onChange={(e) => setPrompt(e.target.value)}
-      placeholder="What do you want to design?"
-    />
-    <Button
-      onClick={() => {
-        sendToAgentChat({ message: prompt, submit: true });
-        setOpen(false);
-        setPrompt("");
-      }}
-    >
-      Create
-    </Button>
-  </PopoverContent>
-</Popover>
-```
-
-**Always ask for input first when** the output depends on a prompt the user must provide — "design what?", "deck about what?", "dashboard for which metric?", "form for which use case?".
-
-**Auto-submit without input is fine when intent is unambiguous:**
+Never auto-submit a generic creative prompt when the user has not said what
+they want. Auto-submit without additional input is fine when intent is
+unambiguous:
 
 - "Try to fix" on a tool error — submits the error details with a clear fix instruction
 - "Retry the last operation" after a transient failure
 - Single-purpose buttons where there is nothing meaningful for the user to add
 
-If you find yourself writing `submit: true` with a hardcoded creative verb (`"design a..."`, `"write a..."`, `"build a..."`), stop and add a Popover.
+Use a Popover only for compact, structured parameters the UI must validate,
+such as a date range, target, or approval choice. Do not add a second freeform
+prompt or follow-up textbox for an AI workflow; keep the conversation and
+revisions in the AgentSidebar thread.
 
 ## Delegating to a Sub-Agent (Agent Teams)
 

package/corpus/templates/chat/.agents/skills/frontend-design/SKILL.md

@@ -130,6 +130,7 @@ passed this requirement yet.
 - Do not build custom dropdowns, menus, popovers, modals, or confirmations with manual absolute positioning and click-outside effects.
 - Never use browser dialogs (`window.alert`, `window.confirm`, `window.prompt`). Use `AlertDialog`, `Dialog`, or app-specific confirmation UI.
 - Use Tabler icons for all first-party UI icons. Do not add Lucide, Heroicons, inline SVG icon sets, or emoji icons.
+- Keep inline help/info glyphs next to labels at `size-3` (12px) or smaller than the adjacent text. Preserve a larger hit area on the trigger, not the glyph. Use `guard:allow-large-help-icon` only for deliberate heading documentation or menu action exceptions.
 - Use `useActionQuery` and `useActionMutation` from `@agent-native/core/client` for action-backed UI. Standard CRUD should go through actions, not custom `/api/` routes.
 - Keep UI optimistic where possible: update cache and navigation immediately, then reconcile or roll back on mutation result.
 - Custom styles belong in Tailwind classes, component CSS, or the existing global CSS theme file; avoid inline styles.

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

@@ -1,10 +1,10 @@
 ---
 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.
+  Turn visible project context, 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:
@@ -17,34 +17,72 @@ metadata:
 
 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 no argument, choose the source in this order: visible project context,
+  then the current thread. A fresh Claude or ChatGPT Project is a valid source
+  on its first turn. Treat its visible project instructions, knowledge files,
+  and supplied past runs as the source; a completed thread is not required.
+  Treat the current turn as a request or configuration unless it contains a
+  concrete repeatable 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.
+- When invoked from an Agent-Native app, use its visible project context first,
+  then the current thread, 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.
+Supported source paths today are visible Claude or ChatGPT Project context, the
+current Codex or host 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.
+Claude and ChatGPT Project context is supported only when the host supplies it
+to the model in the current context. The MCP connector does not read hidden
+project chats, private URLs, account settings, or credentials. Do not claim
+private web access, invent an importer, add fake OAuth, or scrape a logged-in
+page. If the needed context is not visible, ask for an export, transcript, or
+attachment and treat that artifact 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.
 
+## Fresh project context mode
+
+When the source is a fresh Claude or ChatGPT Project, build a short source brief
+before creating the app. Read the host-provided context in this order:
+
+1. Project instructions and configuration: goal, audience, constraints, output
+   standards, approved tools, and integration expectations. Treat these as
+   product configuration, not as a transcript.
+2. Knowledge files and attachments: read the relevant files fully, preserve
+   their provenance, and reduce them to bounded references, IDs, URLs, or
+   summaries for the new app. Do not copy secrets or large raw payloads into
+   prompts or SQL.
+3. Past runs or examples that are actually visible in the context: select at
+   most 1-3 successful, representative runs. Extract repeatable decisions and
+   review criteria. Treat one-off answers and private data as examples, not as
+   product behavior. If no runs are supplied, proceed from the instructions
+   and knowledge files and say that examples were not available.
+4. The current turn: use it for the requested app boundary, target workspace,
+   naming, and any explicit corrections.
+
+Record the brief with these headings before handoff: source and provenance,
+project goal, configuration and constraints, knowledge sources, repeatable
+workflow, inputs and outputs, judgment and review points, representative runs,
+integrations and permissions, and unknowns. This is the compact contract for
+the app. It keeps the new app useful without pretending that hidden Project
+history was imported. See [the fresh Project reference](references/fresh-project.md)
+for the host setup and brief template.
+
+If the visible Project context has no concrete repeatable job, ask for one
+focused clarification or a representative artifact. Do not fall back to a
+generic “what app do you want to make?” builder.
+
 ## Source selection guard
 
 The generated app must implement the concrete workflow found in the source. It
@@ -151,6 +189,14 @@ 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.
 
+When the source came from a fresh external Project and the target is a Builder
+workspace, prefer the available Dispatch MCP workspace handoff after writing
+the source brief. Call `start-workspace-app-creation` with a concise prompt,
+the inferred app id, and the brief's repeatable workflow. Pass selected
+workspace resource IDs when they are available, rather than pasting entire
+knowledge files. Continue from the returned workspace path or Builder handoff
+and report the actual verification result.
+
 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.
@@ -167,13 +213,20 @@ 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.
+- Put deterministic reads, writes, approvals, provider fetches, and publishing
+  in focused `actions/` with `defineAction`. The UI and agent must call the
+  same action surface.
+- If a workflow is framed as research, analysis, generation, recommendation,
+  or synthesis, start it in the AgentSidebar and let the agent orchestrate
+  those actions. Do not hide an AI-shaped multi-step workflow behind one
+  opaque action just because the implementation is deterministic.
 - 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.
+- Use `sendToAgentChat({ message, context, submit: true, openSidebar: true })`
+  for intentional button-triggered agent work. Use `submit: false` when the
+  user should review or edit the proposed prompt in the AgentSidebar first.
+  Keep follow-up and revision prompts in that same thread; do not add a second
+  freeform textbox beside the result.
 - 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.

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

@@ -1,4 +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."
+  short_description: "Turn project context or a workflow into a runnable app"
+  default_prompt: "Use the visible project context first, then any supplied workflow. Turn the instructions, knowledge files, and selected successful runs into a new Agent-Native app with clear buttons, run it locally, verify it, and complete the deployment handoff."

package/corpus/templates/chat/.agents/skills/turn-into-app/references/fresh-project.md

@@ -0,0 +1,64 @@
+# Fresh Project source guide
+
+Use this guide when `/turn-into-app` is invoked in a new Claude or ChatGPT
+Project rather than after a completed thread.
+
+## What the host can provide
+
+The source is whatever the host put in the model's current context:
+
+- Project instructions: the job, audience, constraints, quality bar, and
+  approved tools or integrations.
+- Knowledge files and attachments: reference material, templates, examples,
+  and links that the app should use.
+- Past runs: only conversations or outputs the host actually supplied. They
+  are examples and evaluation material, not an automatic import of every
+  private Project conversation.
+- The current request: the app boundary, target workspace, name, and explicit
+  corrections.
+
+Do not infer hidden system prompts, account settings, private history, API keys,
+or credentials. The Dispatch MCP connector can start a workspace app creation,
+but it cannot unlock or scrape private Project content.
+
+## Source brief
+
+Write a compact brief before starting the app:
+
+```text
+Source: host-provided Claude/ChatGPT Project context
+Provenance: project instructions, selected knowledge files, and visible runs
+Project goal:
+Configuration and constraints:
+Knowledge sources:
+Repeatable workflow:
+Inputs and outputs:
+Judgment and review points:
+Representative runs: none, or 1-3 selected examples
+Integrations and permissions:
+Unknowns and follow-up:
+```
+
+Keep source references bounded. Prefer a file name, URL, resource ID, or short
+summary over a large pasted document. Do not put secrets or raw customer data
+in the brief.
+
+## Fresh-box setup
+
+Install the exported `turn-into-app` skill in the host when the host supports
+skills. For a ChatGPT Project or any host that exposes only the MCP connector,
+also place the skill instructions or this reference in the Project
+instructions/knowledge files. Then add and authenticate the Dispatch MCP
+connector from the packaged `adapters/chatgpt-mcp/connector.json`.
+
+In a new Project chat, say:
+
+```text
+Turn this project into an app. Use the visible Project instructions,
+knowledge files, and any selected successful runs as the source. Create the
+app in the connected Agent-Native workspace, keep the source brief bounded,
+and report the real path and verification result.
+```
+
+If the host does not show the Project instructions or files to the model, stop
+and request an export or attachment. Do not claim that the Project was read.

package/corpus/templates/chat/.env.example

@@ -2,4 +2,7 @@
 PING_MESSAGE=pong
 
 # Skip login/signup (local dev / preview only)
+# Auth is enabled when AUTH_DISABLED is unset. Standalone production deploys
+# need a stable BETTER_AUTH_SECRET; BETTER_AUTH_URL is inferred automatically.
+# BETTER_AUTH_SECRET=
 # AUTH_DISABLED=true

package/corpus/templates/chat/AGENTS.md

@@ -13,6 +13,10 @@ workflow needs durable UI around the conversation.
 - Never hardcode API keys, tokens, webhook URLs, signing secrets, private Builder/internal data, customer data, or credential-looking literals. Use secrets/OAuth/runtime configuration and obvious placeholders in examples.
 - Follow the root framework contract: data in SQL, actions first, application
   state for navigation/selection, and shared agent chat for AI work.
+- Keep actions deterministic and focused. For research, analysis, generation,
+  recommendation, or synthesis, start in the AgentSidebar and let the agent
+  orchestrate its tools; keep follow-ups in the same thread instead of adding
+  a second freeform prompt box.
 - Keep the full-page chat route distinct from domain pages. If a workflow needs
   a page, give it a named route and use the right AgentSidebar for contextual
   AI; domain buttons that call `sendToAgentChat()` should open that sidebar.

package/corpus/templates/clips/.agents/skills/actions/SKILL.md

@@ -20,6 +20,24 @@ Before creating any custom REST/API route for app data, inspect `actions/` and t
 
 **Stop trigger:** the moment you are about to create a file under `server/routes/api/` — or add server middleware to guard one — stop and check it against the exception list in *When You Still Need Custom `/api/` Routes* below. If it is not on that list, write a `defineAction` instead. This applies even when you already started the route; abandoning a half-written action to hand-roll routes is the exact failure this rule exists to prevent.
 
+## Keep actions deterministic and composable
+
+An action may call a provider API, validate or normalize data, and persist
+records without being an AI feature. Keep those operations deterministic,
+focused, and independently useful to the agent. Do not put LLM calls or a
+second model runtime in ordinary actions. The only narrow exception is the
+`completeText()` text-in/text-out escape hatch described in
+`delegate-to-agent`; it must not own tools, chat history, run state, side
+effects, or user steering.
+
+When a workflow is framed as research, analysis, generation, recommendation,
+or synthesis, or spans several provider calls and writes, route the user into
+the AgentSidebar and let the agent orchestrate focused actions. Do not hide an
+AI-shaped workflow behind one opaque `generate-*` or `create-*` action just
+because its implementation is deterministic. A visible user-initiated run
+should use `sendToAgentChat({ openSidebar: true })`, and its follow-ups should
+continue in the same thread rather than a separate freeform input.
+
 ## Why
 
 Actions give the agent callable tools with structured input/output, AND they give the frontend a typed client contract through hooks. One implementation serves both the agent and the UI. They keep the agent's chat context clean, they're reusable, and they can be tested independently.

package/corpus/templates/clips/.agents/skills/agent-native-toolkit/SKILL.md

@@ -56,6 +56,11 @@ The repeated app shell has two distinct navigation surfaces:
   labeled as local, preview, or analyze. For original/generated review, stack
   the source above the result by default and use side-by-side only for short,
   highly scannable content.
+- Deterministic implementation does not make an AI-shaped experience
+  deterministic. If the user expects research, analysis, generation,
+  recommendation, synthesis, visible progress, or steering, route the button
+  to the AgentSidebar and let the agent call focused actions. Keep revisions in
+  the same thread instead of adding a second freeform prompt box.
 - Standalone apps with `AgentSidebar` must resolve one assistant-ui runtime
   context. Match direct assistant-ui pins to the installed core/toolkit peer
   graph, use Vite dedupe/aliases when linked dependencies can split contexts,

package/corpus/templates/clips/.agents/skills/delegate-to-agent/SKILL.md

@@ -14,11 +14,21 @@ metadata:
 
 ## Rule
 
-The UI never calls an LLM directly. Product workflows are delegated to the
-agent through the chat bridge so users can see, steer, and audit the work.
-Server-side one-shot model calls are an explicit escape hatch for narrow text
-transforms only; use `completeText()` from `@agent-native/core/server` when the
-work intentionally does not need tools, chat history, or run state.
+The app's default AI surface is the agent chat. Any user-facing work that asks
+the model to research, analyze, generate, recommend, synthesize, or reason over
+multiple steps must start or continue in the AgentSidebar so users can see,
+steer, and audit the work. UI buttons use `sendToAgentChat()` with
+`openSidebar: true`, and follow-up or revision text belongs in that same thread
+instead of a second app-local textbox.
+
+Actions are tools, not alternate AI runtimes. Keep them deterministic and
+focused: provider reads, validation, deterministic transforms, CRUD, and
+persistence are good action work. Let the agent orchestrate several such tools
+when the workflow is AI-shaped or user-steerable. Server-side one-shot model
+calls are a rare escape hatch for narrow text transforms only; use
+`completeText()` from `@agent-native/core/server` only when the work
+intentionally does not need tools, chat history, run state, side effects, or
+user steering.
 
 ## Why
 
@@ -35,6 +45,7 @@ sendToAgentChat({
   message: "Generate a summary of this document",
   context: documentContent, // optional hidden context (not shown in chat UI)
   submit: true, // auto-submit to the agent
+  openSidebar: true,
 });
 ```
 
@@ -56,6 +67,10 @@ sendToAgentChat({
 This is still a full agent run: tools, actions, thread state, and run tracking
 all remain active. It simply does not focus or open the sidebar.
 
+Use this silent form only for explicitly background or system-initiated work.
+It is not the default for a user clicking an AI-labeled button; visible work
+should open the sidebar so the user can follow and redirect the run.
+
 **From scripts (Node):**
 
 ```ts
@@ -77,8 +92,9 @@ const result = await completeText({
 });
 ```
 
-Wrap user-facing uses in actions so the UI and agent share the same operation.
-Do not call provider SDKs directly.
+If the narrow exception is exposed to the UI, wrap it in an action so the UI
+and agent share the same operation. Keep it clearly non-conversational and do
+not call provider SDKs directly.
 
 **From the UI, detecting when agent is done:**
 
@@ -97,9 +113,9 @@ The `submit` option controls whether the message is sent automatically or placed
 
 | `submit` value | Behavior                                | Use when                                                                            |
 | -------------- | --------------------------------------- | ----------------------------------------------------------------------------------- |
-| `true`         | Auto-submits to the agent immediately   | Routine operations the user has already approved                                    |
-| `false`        | Prefills the chat input for user review | High-stakes operations (deleting data, modifying code, API calls with side effects) |
-| omitted        | Uses the project's default setting      | General-purpose delegation                                                          |
+| `true`         | Auto-submits to the agent immediately   | Routine operations with clear intent; keep `openSidebar: true` for visible work |
+| `false`        | Prefills the AgentSidebar composer      | Review, edit, or add detail before the run; use the existing sidebar thread   |
+| omitted        | Uses the project's default setting      | General-purpose delegation                                                       |
 
 ```ts
 // Auto-submit: routine operation
@@ -109,61 +125,43 @@ sendToAgentChat({ message: "Update the project summary", submit: true });
 sendToAgentChat({
   message: "Delete all projects older than 30 days",
   submit: false,
+  openSidebar: true,
 });
 ```
 
-## Capture user input first when generating from a prompt
-
-Buttons that produce new content ("New Design", "Create Dashboard", "Make Deck", "Generate Form") need the user's prompt as input. **Never hardcode a generic message** — the result will be a generic generation the user didn't actually ask for.
+## Capture user input in the sidebar
 
-**Bad** — auto-submits a placeholder message; the user never said what they wanted:
+The AgentSidebar composer is the default prompt surface. When a button needs
+the user to describe what to create, prefill that same composer and let the
+user edit or complete it:
 
 ```tsx
 <Button
   onClick={() =>
-    sendToAgentChat({ message: "make a design", submit: true })
+    sendToAgentChat({
+      message: "Help me create a research report from this brief:",
+      context: researchBrief,
+      submit: false,
+      openSidebar: true,
+    })
   }
 >
-  New Design
+  Start in agent
 </Button>
 ```
 
-**Good** — Popover anchored to the button captures the prompt, then submits it:
-
-```tsx
-<Popover open={open} onOpenChange={setOpen}>
-  <PopoverTrigger asChild>
-    <Button>New Design</Button>
-  </PopoverTrigger>
-  <PopoverContent className="w-96">
-    <Textarea
-      autoFocus
-      value={prompt}
-      onChange={(e) => setPrompt(e.target.value)}
-      placeholder="What do you want to design?"
-    />
-    <Button
-      onClick={() => {
-        sendToAgentChat({ message: prompt, submit: true });
-        setOpen(false);
-        setPrompt("");
-      }}
-    >
-      Create
-    </Button>
-  </PopoverContent>
-</Popover>
-```
-
-**Always ask for input first when** the output depends on a prompt the user must provide — "design what?", "deck about what?", "dashboard for which metric?", "form for which use case?".
-
-**Auto-submit without input is fine when intent is unambiguous:**
+Never auto-submit a generic creative prompt when the user has not said what
+they want. Auto-submit without additional input is fine when intent is
+unambiguous:
 
 - "Try to fix" on a tool error — submits the error details with a clear fix instruction
 - "Retry the last operation" after a transient failure
 - Single-purpose buttons where there is nothing meaningful for the user to add
 
-If you find yourself writing `submit: true` with a hardcoded creative verb (`"design a..."`, `"write a..."`, `"build a..."`), stop and add a Popover.
+Use a Popover only for compact, structured parameters the UI must validate,
+such as a date range, target, or approval choice. Do not add a second freeform
+prompt or follow-up textbox for an AI workflow; keep the conversation and
+revisions in the AgentSidebar thread.
 
 ## Delegating to a Sub-Agent (Agent Teams)
 

package/corpus/templates/clips/.agents/skills/frontend-design/SKILL.md

@@ -130,6 +130,7 @@ passed this requirement yet.
 - Do not build custom dropdowns, menus, popovers, modals, or confirmations with manual absolute positioning and click-outside effects.
 - Never use browser dialogs (`window.alert`, `window.confirm`, `window.prompt`). Use `AlertDialog`, `Dialog`, or app-specific confirmation UI.
 - Use Tabler icons for all first-party UI icons. Do not add Lucide, Heroicons, inline SVG icon sets, or emoji icons.
+- Keep inline help/info glyphs next to labels at `size-3` (12px) or smaller than the adjacent text. Preserve a larger hit area on the trigger, not the glyph. Use `guard:allow-large-help-icon` only for deliberate heading documentation or menu action exceptions.
 - Use `useActionQuery` and `useActionMutation` from `@agent-native/core/client` for action-backed UI. Standard CRUD should go through actions, not custom `/api/` routes.
 - Keep UI optimistic where possible: update cache and navigation immediately, then reconcile or roll back on mutation result.
 - Custom styles belong in Tailwind classes, component CSS, or the existing global CSS theme file; avoid inline styles.