Create, edit, or improve a reusable Canvas skill from a concrete workflow. Author a complete organization skill or a new skill inside an existing plugin draft, preserve supporting files, and test the exact published result.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Capture the requested reusable workflow as a complete skill: instructions, useful references, assets and any necessary executable helpers. Choose a narrow trigger and a concrete result. Use the current conversation before asking for examples or missing details. Ordinary writing requests do not imply creating a skill.
Use the canvas_extensions gateway: search for the needed operation, describe its exact schema, then call it with matching arguments. Use directly registered equivalents when the runtime supplies them. Existing tool rights still apply; this instruction cannot expand a specialized agent's selection.
create_canvas_package_draft with operation: "create", kind: "skill", a stable lowercase name and UUID requestId. The server chooses the current organization and verifies creation rights. Do not send an ownership or account override.draftRef and declared child root. Inspect the plugin draft and manifest first. Write the new child into that same complete plugin draft; do not create or install a separate personal skill.edit or explicitly permitted distinct fork. Editing a plugin child means editing its containing plugin. Preserve other children and shared resources.Use common draft list/read/write/delete file operations with their actual schemas and current expectedDraftRevision. Preserve the complete package, including scripts, references, examples and assets. Use returned identities; do not create .canvas/skills, guess hidden server roots or fall back to the legacy personal installer for organization creation.
Keep the entrypoint concise. State the useful outcome, when it applies, important non-obvious decisions, the actual runtime tool recipe and any needed output format. Include concrete examples when they resolve ambiguity. Avoid generic tutorials, redundant checklists, mandatory interviews or an approval stage already covered by the user's request.
Use progressive disclosure: metadata for discovery, SKILL.md when selected, supporting references only at the relevant step. Add a helper script only when it provides real reliability or reusable computation, and test that helper. Link only resources actually supplied in the package or exact runtime context. Keep the user's authorization and account choice intact.
Minimal standalone content:
SKILL.md
agents/canvas.yaml optional UI/workflow metadata
references/ only when useful
scripts/ only when needed
assets/ only when needed
SKILL.md starts with YAML name, a precise description and metadata.version as a string, for example "1.0.0". The name matches the selected root. Optional agents/canvas.yaml can provide interface.display_name, short_description, brand_color, package-local images and skill.version. If both files declare a version, they agree. Changed derived content receives a new independent skill version; the containing plugin version is separate.
A standalone skill may declare workflow.version: 1, integrationCapabilities and its own mcpConnectors in agents/canvas.yaml. A plugin child uses the parent's MCP declarations and may declare its workflow requirements there; it cannot carry its own mcpConnectors. For bundling existing skills or combining multiple integrations, use Plugin Creator and its common composition service rather than copying partial instructions.
Use real Composio toolkit slugs and stable package-local MCP connector names. Declare only needed capabilities and verified tool names. At runtime, use the selected requirement's mapped provider/account, then search the relevant tools, describe the exact returned tool/schema reference and call it with valid arguments. A declaration does not connect an account or grant tools. Preserve setup-required and provider_unavailable as distinct states.
Keep account IDs, connection/profile/definition IDs, tokens, credentials, absolute developer paths and runtime binding receipts out of files. Declare ENV key names when necessary; values stay in Canvas's central Secrets service at /settings?tab=secrets, accessed through existing services. Canvas Email uses its mailbox tools; do not invent a new workflow provider type.
Call validate_canvas_package_draft for the current complete draft and repair precise file/field errors. When creating a plugin child, validate the whole plugin with its parent connector declarations and other children. Draft content stays private and is not executed through a workspace bypass.
For a requested internal saved skill, publish once with fresh metadata/grants/package-head/draft revisions and a stable request ID. Recover uncertain outcomes through operation inspection. A draft-only request remains a draft. Publish does not itself grant use or activate the package: use existing revision-checked resource/grant/activation actions for the requested users. Never broaden other members' edit/manage permissions just to enable a test.
Test representative input through the normal runtime against the exact published revision after permitted use/activation. Check a normal case, a boundary or missing-input case, and the relevant integration failure when applicable. Match evaluation effort to the workflow; a simple subjective writing skill need not run a benchmark suite. Distinguish schema/file validation, actual runtime behavior and external provider availability. If the runtime cannot execute the example, report the remaining check honestly.
Return the saved version or resumable draft link and the concrete validation/test result. New edits start another edit draft; preserve existing published versions and other agent pins.
The optional external evaluation tooling is for an explicitly requested external Claude CLI environment. Its .skill packaging, CLI evaluations and local viewers are not Canvas's normal authoring, installation or testing path.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
中文简介正在准备中。当前显示原文说明。
Applies Canvas brand colors, typography, and visual polish to artifacts that benefit from a consistent product look-and-feel. Use it when brand colors, style guidelines, visual formatting, or company design standards apply.
中文简介正在准备中。当前显示原文说明。
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.
中文简介正在准备中。当前显示原文说明。
Create or improve an organization-managed Canvas plugin that combines complete new or existing skills with optional custom MCP and Composio integrations. Use for reusable multi-skill workflows, plugin composition, plugin editing, and plugin graphics.
中文简介正在准备中。当前显示原文说明。
Use this Canvas-owned clean-room skill to guide collaborative writing for documentation, proposals, technical specs, decision records, PRDs, RFCs, operating guides, and structured memos. Trigger when the user wants help drafting, organizing, refining, reviewing, or testing a document before sharing it.
中文简介正在准备中。当前显示原文说明。
Use this Canvas-owned clean-room skill for creating, reading, editing, reviewing, redlining, commenting, or repairing Word `.docx` documents. Trigger for Word documents, DOCX files, memos, reports, letters, templates, tracked changes, comments, table of contents, headers, footers, page numbers, and Google Docs-targeted documents that should be authored as DOCX first.
中文简介正在准备中。当前显示原文说明。