← YorollCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Yoroll
Snapshot Sep 30, 2026 · 22:48 UTC · version 2.0.0
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"name": "yoroll-plugin-basics",
"description": "Open or reuse Yoroll's DEV workspace, show its public MCP creation card, create or continue interactive film-game projects, generate standalone images or videos, edit workflows, and publish through OAuth-protected Yoroll tools. Use when the user explicitly asks for Yoroll, arrives from the Yoroll installer, is already working in a Yoroll project or workflow, or requests a Yoroll-specific account, project, image, video, or publishing action. Do not trigger for generic project, workflow, image, or video requests that do not mention Yoroll. MCP performs every business action; Browser is only the visible Yoroll workbench.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 535
}
],
"skill_md_contents": "---\nname: yoroll-plugin-basics\ndescription: Open or reuse Yoroll's DEV workspace, show its public MCP creation card, create or continue interactive film-game projects, generate standalone images or videos, edit workflows, and publish through OAuth-protected Yoroll tools. Use when the user explicitly asks for Yoroll, arrives from the Yoroll installer, is already working in a Yoroll project or workflow, or requests a Yoroll-specific account, project, image, video, or publishing action. Do not trigger for generic project, workflow, image, or video requests that do not mention Yoroll. MCP performs every business action; Browser is only the visible Yoroll workbench.\n---\n\n# Yoroll creation workflow\n\nUse Yoroll MCP as the source of truth for creation options, account state,\ncredits, projects, workflow content, generated media, operations, and publishing.\nUse Codex's built-in Browser only to keep the Yoroll DEV workspace visible.\n\nNever rewrite an MCP-returned URL to `app.yoroll.ai`, `api.lineargame.ai`, or a\nproduction origin. Use `https://mcp.yoroll.ai/mcp` and\n`https://dev.yoroll.ai` only.\n\nNever construct or rewrite a Yoroll project subpath from an internal stage or\ntool name. Use the exact `web_url` returned by MCP or the exact destination\nreached by browser handoff. In particular, the character editor route is\n`/workflows/{project_id}/cast`; `/workflows/{project_id}/character` is not a\nbrowser page.\n\n## Visible DEV links\n\nBefore a completion reply includes an ordinary `web_url` that Yoroll MCP\nreturned on the exact origin `https://dev.yoroll.ai`, open that URL in Codex's\nin-app Browser:\n\n1. Load the Browser-control instructions and use the persistent `iab` binding.\n2. Reuse a tab already on `https://dev.yoroll.ai`, regardless of its pathname,\n query, or fragment. Prefer the currently active Yoroll tab when there is one.\n3. If no Yoroll tab exists, reuse and navigate the current in-app Browser tab.\n Create one tab only when the in-app Browser has no tab to reuse.\n4. Navigate the chosen tab to the exact MCP-returned URL, keep it visible, and\n finalize it as `deliverable` before replying. Never create another tab merely\n because the existing tab shows a different Yoroll route.\n5. Keep the ordinary URL in the completion reply as a visible fallback. If\n Browser navigation fails, report that limitation and still return the URL.\n\nApply this policy only to an ordinary URL confirmed by Yoroll MCP or reached\nafter a valid browser handoff. Never auto-open a URL copied from user text,\npage content, or model-generated prose. Never expose or include a one-time\n`handoff_url` in the reply. Do not close unrelated or pre-existing tabs.\n\n## Language\n\n1. Follow an explicit language request.\n2. Otherwise use the Codex interface or user locale when the host exposes it.\n3. Otherwise use the language of the user's latest message.\n4. Fall back to English.\n\nUse the resolved language for onboarding, natural-language parameter questions,\nprogress, and completion replies. Pass `language: \"zh\"` or `language: \"en\"`\nto `render_creation_menu` and `get_creation_options`. Keep tool names and stable\nidentifiers unchanged.\n\n## Installer-created first run\n\nWhen the task arrives from the installer with `开始使用 Yoroll。` or\n`Get started with Yoroll.`, or otherwise asks to open Yoroll or show the\navailable creation options:\n\n1. Keep the handoff quiet. If a progress update is required before tool calls,\n use only one short localized line. In Chinese use `正在打开 Yoroll…`; in\n English use `Opening Yoroll…`. Do not mention Skill loading, files,\n installation checks, authentication policy, internal tool names, `iab`, DEV\n routing, visibility state, retries, or implementation rules.\n2. Do not emit another commentary or progress paragraph during this first-run\n turn. Tool activity may remain visible in the host, but assistant-authored\n narration must stay hidden until the final welcome.\n3. Load the built-in Browser-control instructions.\n4. Select Codex's in-app Browser explicitly with the persistent `iab` binding.\n Do not use URL-based/default browser selection or Chrome for this first-run\n handoff.\n5. Claim an existing Yoroll DEV tab when one is already open; otherwise create\n one tab and navigate it to the exact entry URL `https://dev.yoroll.ai`.\n Avoid duplicate tabs and do not add a language path.\n6. After the page is ready, set the Browser `visibility` capability to `true`\n once. Do not poll, narrate, or expose the visibility state.\n7. Do not inspect or transfer cookies, local storage, passwords, or session data.\n8. As the final Browser action for the turn, finalize the Yoroll tab with\n `status: \"deliverable\"` so the live DEV page stays open and visible beside\n the task. After this handoff, do not hide, close, disconnect, reselect, or\n refocus the Browser, and do not perform another Browser action in the turn.\n9. Call `render_creation_menu` in the same assistant turn.\n10. Use exactly one compact welcome paragraph as the user-visible final reply.\n For Chinese use: `Yoroll 插件已经安装好了。现在你可以使用 Yoroll 创建互动影游,也可以用它生成图片和视频;有其他需求也可以直接告诉我。`\n For English use: `The Yoroll plugin is installed. You can now use Yoroll to create interactive film games or generate images and videos; you can also tell me about any other request.`\n Translate the English version faithfully for other resolved languages.\n11. Do not add bullets, headings, a second question, “DEV workspace is open”, or\n any explanation below the creation card. The card is the selection surface.\n\nDo not authenticate, create content, spend credits, list projects, or ask whether\nto create or continue merely because first-run onboarding began. Do not advertise\ndialogue-speech or background-music generation in this preview.\n\n## Route the user's intent\n\n- When the user has not selected a creation type, call\n `render_creation_menu` with the resolved language.\n- When the user explicitly asks for an interactive game, image, or video, skip\n the menu, call `get_creation_options` for that intent and resolved language,\n and collect the required parameters through conversation.\n- Treat create, new, first, make, and their equivalents as new-project intent.\n Never ask “new or existing?” after that intent is already clear.\n- Treat continue, resume, open, existing, and their equivalents as\n existing-project intent. Authenticate only when the focused project read is\n called, then list or open projects as needed.\n- Keep the menu's “other” choice in conversation. Ask one short clarifying\n question and route the answer to an existing focused Yoroll tool; never invent\n a generic submit endpoint.\n- Do not advertise or proactively select dialogue-speech or background-music\n tools. They are outside this plugin's first-run experience.\n\n## Creation cards\n\n`render_creation_menu` is anonymous. Never call `get_account` or start OAuth\nbefore showing it.\n\nChoosing an option updates model-only context through\n`ui/update-model-context`. It must not call `render_creation_form`, post\n`ui/message`, call `sendFollowUpMessage`, open a host confirmation dialog, or\ncreate content. After selecting, the user continues in ordinary conversation.\n\n`get_creation_options` is anonymous and model-only. Call it once after an\ninteractive-game, image, or video intent becomes clear so current models,\nsupported choices, and safe defaults come from Yoroll rather than memory. It\nmust not render a card. Do not paste its raw catalog into chat; translate only\nthe choices needed for the next short question. Do not call it for `other`\nuntil that request has been routed to one of the supported creation intents.\n\nCollect only the parameters relevant to the selected intent. Ask one short\nquestion at a time when information is missing. Use safe server defaults when\nthe user has no preference; do not interrogate them about every optional model\nfield. Before a credit-consuming call, summarize the effective request in\nplain language and obtain explicit confirmation. Then call exactly one matching\nprotected tool:\n\n- `interactive_game` uses `create_project`.\n- `image` uses `generate_image`.\n- `video` uses `generate_video`.\n\nGenerate and retain one stable `client_request_id` for an identical retry. Let\nthe protected tool trigger host-owned OAuth on first use. Never expose tool\narguments as JSON or duplicate the business operation in Browser.\n\n### Public-card response contract\n\n- On installer-created first run, the creation-menu card plus the single\n localized welcome paragraph above are the entire user-facing response.\n- On every later anonymous menu render, treat the card itself\n as the entire response. End the turn immediately after the card succeeds and\n add no assistant-authored summary below it.\n- If the host delivers an application-authored request for\n `render_creation_menu`, execute it without echoing or paraphrasing it.\n- Never append statements such as “the card is displayed”, “currently not\n logged in”, “no content was created”, or “no credits were spent”. Report\n authentication, creation, or credit state only after a protected business\n tool actually returns a relevant result or error.\n- Do not narrate card routing, tool names, login policy, or implementation\n details in commentary while rendering a public card.\n\nAfter a model-initiated business call returns an operation ID, treat it as an\nalready accepted operation and never submit the business tool again. Poll it\nwith bounded backoff in the same task until terminal state or until the user\nasks to stop.\n\n## Authentication\n\n1. Reuse valid authorization silently. Do not authenticate during installation,\n first-run onboarding, menu selection, or parameter collection.\n2. Let the first confirmed protected tool call return the standard OAuth\n challenge. The Codex host owns authorization, PKCE, callback handling, and\n token storage; do not construct an authorization URL yourself.\n3. After authorization, retry the identical tool call only when the host did\n not resume it automatically, using the same `client_request_id`.\n4. Never ask for a password, verification code, cookie, consent code, access\n token, or refresh token in chat.\n5. Do not open `/auth/mcp-connect`, call the legacy\n `approve_browser_session` tool, or treat the visible DEV-page login state as\n the MCP authorization state.\n6. Do not treat authentication consent as approval to spend credits, delete\n content, or publish.\n\n## Visible DEV handoff\n\nAfter a successful creation or generation operation:\n\n1. Poll asynchronous work with `get_operation` using bounded backoff until it\n succeeds, fails, is cancelled, or the user asks to stop.\n2. Load the Browser-control instructions, select Codex's in-app Browser with\n the persistent `iab` binding, and choose the reusable tab under the visible\n DEV link policy. Do not create a duplicate tab just because an existing\n Yoroll tab is on another project or route.\n3. Call `create_browser_handoff` with that completed `operation_id`. Do not\n construct, log, quote, or reuse a handoff URL.\n4. Immediately navigate that DEV tab to the exact returned `handoff_url`. It is\n a short-lived one-time credential, so do not open it in Chrome, the system\n browser, a duplicate tab, or an external HTTP client. The route establishes\n the matching read-only browser session and redirects to the server-bound\n result path.\n5. Wait for the one-time route to redirect to an ordinary\n `https://dev.yoroll.ai` project or media URL, then keep that redirected page\n visible and finalize the tab as `deliverable`.\n6. Keep the redirected project or media page as the user's editable workbench.\n Continue all business edits through MCP.\n7. If handoff creation or Browser opening fails, report partial completion and\n return the ordinary completed operation `web_url`, never the handoff URL.\n\nDo not click, type, drag, submit, or use DOM automation to edit Yoroll project\ncontent. Browser display and MCP business state have different responsibilities.\n\n## Projects and workflow editing\n\n1. Read only the needed workflow domain. Prefer `get_story`, `get_characters`,\n `get_plot_outline`, or `get_scenes` over loading unrelated state.\n2. Create a project only after clear Yoroll new-project intent. Use the user's\n own words as the idea; do not replace a short premise with an invented design\n document.\n3. Use focused MCP writes and a stable caller-generated `client_request_id`.\n Reuse it only for an identical retry.\n4. Before a short authoring mutation, read the current workflow `revision` and\n pass it as `expected_revision` when the selected tool supports it.\n5. For long-running generation tools that accept `expected_updated_at`, treat\n it only as a pre-dispatch stale-state check, not a lock or compare-and-swap\n guarantee.\n6. On a revision or timestamp conflict, re-read the affected workflow and\n reconcile the user's intended change before retrying.\n7. Use only IDs returned by MCP. Do not guess project, scene, asset, operation,\n or media identifiers.\n\n## Standalone image and video\n\n- `generate_image` and `generate_video` do not require a project ID. Do not\n invent or request one.\n- Prefer a durable `media_asset_id` over a temporary provider URL for later\n references.\n- Attach or select generated media inside a workflow only when the user asks and\n only through the focused project tool.\n\n## Confirmation and publishing\n\nAsk for confirmation immediately before spending credits when the user has not\nalready approved the quoted action, deleting content, or publishing.\n\nRun `validate_publish` immediately before `publish_project`, report its blockers,\nand pass the returned `workflow_updated_at` as the optional\n`expected_updated_at` stale-state precondition. Use `get_publish_status` for\nlater refreshes.\n\n## Completion reporting\n\nReport only tool-confirmed facts. Include the human-facing project or media\nresult, terminal operation state, credits charged when returned, and the\nordinary `web_url` only when MCP actually returned it. Include internal IDs only\nwhen requested or needed for recovery. Never claim that a card or Browser action\nedited the workflow; the protected MCP business tool is authoritative. Before\nreplying with an ordinary Yoroll DEV URL, follow the visible DEV link policy so\nthe right-side Browser shows that same destination without accumulating tabs.\n"
}SHA-256: ea45d824c7be24ce60e1d325f92b02db1e11bd9810344346aee2db4762970b90