sync: update skills from runtypelabs/core@02d9739

skills/runtype-build-product/SKILL.md

@@ -23,30 +23,19 @@ Before designing or creating resources:
 - Flow build: `get_build_instructions(task="generate-flow", description=..., name=...)`.
 - Capability scoping: `get_build_instructions(task="explain-capabilities")`.
 
-Then fetch only the docs needed for the current design:
-
-- `get_platform_documentation(topic="surface-types")`
-- `get_platform_documentation(topic="flow-step-types")`
-- `get_platform_documentation(topic="product-schema")`
-- `get_platform_documentation(topic="types-fpo")`
-- `get_platform_documentation(topic="types-flow-steps")`
-- `get_platform_documentation(topic="types-entities")`
-- `get_platform_documentation(topic="types-surface-configs")`
-- `get_platform_documentation(topic="builtin-tools")`
-- `get_platform_documentation(topic="agent-skills")`
-- `get_platform_documentation(topic="orthogonal-tools")`
-- `get_platform_documentation(topic="external-tools")`
-- `get_platform_documentation(topic="models")`
-- `get_platform_documentation(topic="dashboard-links")`
-- `get_platform_documentation(topic="mock-ecommerce")`
-- `get_platform_documentation(topic="persona-embed")`
-- `get_platform_documentation(topic="persona-fullscreen-assistant")`
-- `get_platform_documentation(topic="sdk-reference")`
-
-Also read MCP resources directly when available for richer coverage:
-`runtype://types/fpo-template`, `runtype://guide/subagent-delegation`,
-`runtype://catalog/skills`, `runtype://catalog/provider-native-search`, and
-`runtype://catalog/ucp-commerce`.
+Then fetch only relevant `get_platform_documentation` topics:
+
+| Need                           | Topics                                                                    |
+| ------------------------------ | ------------------------------------------------------------------------- |
+| Product/FPO shape              | `product-schema`, `types-fpo`, `types-fpo-template`                       |
+| Flow step configs              | `flow-step-types`, `types-flow-steps`                                     |
+| Delivery and embeds            | `surface-types`, `types-surface-configs`, `persona-embed`                 |
+| Tools and credentials          | `builtin-tools`, `external-tools`; use `vendor` for one Orthogonal vendor |
+| Models                         | `models` plus account `list_model_configs`                                |
+| Validation or go-live blockers | `validation-errors`, `setup-readiness`                                    |
+
+Build instructions route deeper subjects such as skills, subagents, retrieval, commerce,
+and evals. Do not fetch every catalog in advance or read the same topic again as a resource.
 
 ## Design Policy
 
@@ -75,7 +64,7 @@ finding, and ask whether to use UCP or the traditional commerce path before proc
 
 ## Build Loop
 
-1. Discover account state with `get_me`, `list_products`, `list_agents`, `list_flows`,
+1. Discover only the account state the task needs with `get_me`, `list_products`, `list_agents`, `list_flows`,
    `list_tools`, `list_model_configs`, and product-scoped `list_surfaces` when relevant.
    These large inventory tools use compact string previews by default; keep that shape
    for discovery, use `agent_type` when narrowing agents, and call the matching `get_*`
@@ -91,18 +80,24 @@ finding, and ask whether to use UCP or the traditional commerce path before proc
 4. Validate before creating: `validate_product`, `validate_flow`, `validate_product_flow`,
    `validate_product_agent`, `validate_product_surface`, `validate_product_tool`, and
    `validate_code` for custom JS or transform code.
-5. Create in a reviewable order: tools/secrets, agents/flows, product, capabilities,
-   surfaces, surface items, schedules, client tokens, and evals.
+5. `create_product` creates an empty container, not an FPO import. Create the required
+   agents/flows and tools, attach capabilities and surfaces using returned IDs, and create
+   schedules or credentials only when requested delivery requires them. Read
+   `get_product_setup` before testing integrations; complete authorized setup or return
+   the remaining human-action links. A bare flow does not need product setup.
 6. Test at the user-facing layer. Use `execute_agent`, `dispatch`, `execute_tool`,
    `run_flow`, `submit_batch`, `submit_eval`, `trace_execution`, and
-   `trace_conversation` as appropriate.
+   `trace_conversation` as appropriate. Use fixtures/sandbox targets for side effects; do
+   not send live messages, charge money, or activate recurring work merely to smoke-test.
+   Report validation, setup readiness, tested behavior, and untested paths separately.
 
 ## Guardrails
 
 - Never invent schemas or model IDs; fetch docs and model configs.
 - Do not inline credentials. Use `{{secret:KEY}}` and secret intake.
 - Read before update; preserve fields the user did not ask to change.
-- Treat `update_agent` as wholesale replacement unless live docs say otherwise.
+- Check update semantics in the live schema; preserve sibling config fields when replacing
+  nested objects. `update_flow.steps` replaces the entire step list.
 - Surface-level evals catch orchestration and formatting issues that per-agent evals miss.
 - If a product needs deeper or newer platform rules than this skill names, fetch
   `platform-catalog` and focused direct resources instead of appending feature

skills/runtype-sdk-marathon/SKILL.md

@@ -27,11 +27,12 @@ Code-first modes:
 
 - Stored: create persistent agents/flows in Runtype.
 - Upsert on execute: code is the source of truth and overwrites the Runtype copy when run.
-- Virtual: definition is sent over the wire and not persisted.
+- Virtual: the definition is supplied per execution without creating a saved agent/flow.
+  Execution logs, traces, and retention policies still apply; this is not a zero-retention mode.
 
 Default to stored or upsert for production workflows because dashboard inspection, logs,
-evals, and versioning are easier. Use virtual for tests, one-offs, privacy constraints,
-or temporary generated flows.
+evals, and versioning are easier. Use virtual for tests, one-offs, or temporary generated flows; verify retention separately
+for privacy-sensitive workloads.
 
 Use local tools when execution must happen in the user's browser or server. Use hidden
 parameters when auth context, tenant ids, or sensitive request data must not appear in the
@@ -46,18 +47,20 @@ npm install -g @runtypelabs/cli
 npx @runtypelabs/cli@latest <command>
 ```
 
-Authenticate:
+Check auth before changing it:
 
 ```bash
-runtype auth login
-runtype auth whoami
+runtype auth status
 ```
 
-Export a key for stdio MCP or CI only when needed:
-
-```bash
-export RUNTYPE_API_KEY=$(runtype auth export-key)
-```
+That checks stored login/signup state only. If `RUNTYPE_API_KEY` is configured, verify
+it with `runtype auth whoami --no-tty` instead and reuse that account. Otherwise reuse
+a stored authenticated account; for a pending signup follow its `next` command. New
+accounts use `runtype auth register --email <email>` then `runtype auth verify <code>`.
+Browser-only `runtype auth login` requires the user's interactive terminal, not a coding
+harness. For existing-account or installation recovery, follow
+`https://runtype.ai/.well-known/agent.md`. Never ask for API keys in chat; have the user
+configure credentials privately. `RUNTYPE_API_KEY` authenticates CLI commands in CI.
 
 Common commands include `runtype agents list`, `runtype dispatch`, `runtype flows create`,
 `runtype records create`, `runtype schedules`, `runtype models`, `runtype batch`,

skills/runtype/SKILL.md

@@ -34,20 +34,22 @@ schema, catalog, or creation guidance:
 - `get_platform_documentation(topic=...)` for schemas, surface traits, tool catalogs,
   SDK docs, Persona embed docs, dashboard links, and type definitions.
 
-If MCP is not connected, use the CLI-to-MCP golden path instead of presenting several
-equivalent setup choices:
-
-1. Authenticate the CLI with `runtype auth login` so this session can keep working.
-2. Run `runtype install-mcp`. It installs this skill, configures the current harness for
-   `https://api.runtype.com/v1/mcp/protocol`, and starts client-owned OAuth when possible.
-3. Continue the current session with CLI commands. Tell the user to restart or reload the
-   harness because a running agent may not discover a newly configured MCP connection.
-4. In the next session, use MCP first and call `get_build_instructions` before building.
-
-Do not choose an API key merely to avoid a restart. Headless API-key setup is an exception
-for environments where browser OAuth is genuinely impossible; follow `https://runtype.com/auth.md`
-only after confirming that constraint with the user. The full public setup script is at
-`https://runtype.ai`.
+If MCP is not connected, check `runtype auth status` for stored login/signup state.
+If `RUNTYPE_API_KEY` is configured, verify it with `runtype auth whoami --no-tty` instead;
+`status` ignores environment credentials. Reuse valid authentication before resuming
+a stored pending signup using its `next` command. For a new account,
+use `runtype auth register --email <email>` then `runtype auth verify <code>` — both work
+without a TTY or browser. Do not run browser-only `runtype auth login` from a coding harness.
+
+Run `runtype install-mcp` for the current harness, follow its action/restart status,
+and keep working through the CLI while MCP is unavailable (`runtype mcp tools` and
+`runtype mcp call <tool>` bridge the hosted tools). Use MCP once its tools actually appear;
+configuration alone does not prove the connection is active.
+
+For installation or auth recovery, read the public setup script at
+`https://runtype.ai/.well-known/agent.md`; the raw auth protocol is at
+`https://runtype.com/auth.md`. Existing-account credentials must be configured privately,
+not pasted into the conversation. Only install or sign up when the user requests setup.
 
 ## Route To Focused Skills