跳到正文
cccskills
免费在 GitHub 公开

dotcanvas

Author and edit a Grida `.canvas` board — a `.canvas.json` manifest plus document files (references, generated images, notes) placed on an infinite canvas. Use when working on a `.canvas` bundle or arranging visuals/design work spatially. For a linear deck/presentation, use the `slides` skill instead.

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md4.6 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

A .canvas is a Grida design board — a directory bundle, not a single file. You work it like any other files: with read_file / write_file / edit_file (no special canvas tool). It is the durable, spatial home for a piece of work: reference images, generated outputs, and notes, arranged on an infinite canvas. Prefer a .canvas board for freeform visual/design work; for a linear deck / presentation / pitch / slideshow, use the slides skill.

Structure

  • The bundle is a folder whose name ends in .canvas (e.g. poster.canvas/).
  • .canvas.json (the manifest) holds the STRUCTURE: which documents are on the board, their placement, order, and the editor mode.
  • Each document's CONTENT is a separate file (or a URL) referenced by its src.
  • Manifest shape (only src is required per document):
    {
      "editor": "board",
      "documents": [
        {
          "src": "https://…/ref.jpg",
          "id": "ref1",
          "layout": { "x": 0, "y": 0, "w": 480, "h": 320 }
        },
        {
          "src": "outputs/hero.png",
          "id": "hero",
          "layout": { "x": 520, "y": 0, "w": 768, "h": 512 }
        }
      ]
    }
    
  • editor: "board" = freeform infinite canvas (placement via layout). editor: "slides" = linear deck (order) — see the slides skill.
  • layout is { x, y, w, h, z? } in world space (z = paint order, optional). A document with no layout is unplaced — the host positions it; set a layout to place it deliberately.

Working pattern

  • To start, make the bundle folder first — a NEW directory whose name ends in .canvas (e.g. poster.canvas/); a plain folder, or files loose in the workspace root, is NOT a board and won't open. Then write_file its .canvas.json and each document file INSIDE that folder. To add to an existing board, read_file .canvas.json first (preserve version/$schema/editor and any unknown fields), then write the FULL updated manifest back.
  • A document's src may be a URL (a pointable reference — a picked library image, used as-is, no download) OR a file path inside the bundle. Both are first-class placed documents.
  • To place a generated image (or any produced file) on the board: materialize it into the bundle, then reference it. Copy it from your scratch dir into the bundle with the shell — e.g. cp <scratch>/image-….png <board>.canvas/outputs/hero.png — then add a document whose src is that bundle-relative path. (A src can point at any file the host can read, but a file inside the bundle is the durable, portable choice.)
  • To move / resize / reorder, edit the layout (and document order) in the manifest. The human can also drag pins directly — re-read .canvas.json before editing so you don't clobber their changes (last write per file wins).

Show the result

  • Treat presentation as the first production milestone, not the final "validate and open" step. For a new board, establish a meaningful renderable checkpoint early: the manifest references at least one existing, valid document with a basic visible composition. Call surface_open immediately with the workspace-rooted .canvas bundle directory (for example, /poster.canvas), then continue building and polishing it while the user can watch. Intentionally use a lightweight initial composition instead of authoring the finished board before opening it. Do not wait for all content, assets, polish, preview generation, exhaustive validation, or task completion.
  • Never open an empty bundle or a broken manifest. Open only when the manifest references at least one existing, renderable document. Pass the bundle directory, never its .canvas.json manifest.
  • For an existing primary board, open it after reading its manifest and before substantial edits.
  • If the .canvas bundle itself is mounted as / in a dedicated file surface, it is already presented; do not call surface_open just to reopen it.
  • Treat presentation as auxiliary: continue regardless of the result, never retry based on presentation status, and do not call surface_open after every write.
  • Use surface_list_open only when the current host surface state is materially useful. It is not required before surface_open.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Grida AI agent system work: `@grida/daemon` (DaemonServer, loopback HTTP perimeter, files/workspaces, secrets store, daemon discovery) and `@grida/agent` (the agent tenant: sessions, providers/BYOK, runtime/tool execution, skills discovery, prompts, tiers, sandbox hosts). Use for `packages/grida-daemon/**`, `packages/grida-ai-agent/**`, desktop sidecar protocol changes, agent chat transport, and bugs in agent state or streams. For pure Electron window, preload, menu, deep-link, or CDP work, use `desktop`.

中文简介正在准备中。当前显示原文说明。

gridaco/grida26892026年10月19日 更新

ai-models

免费

Research, compare, and update shared AI model JSON for TypeScript, web, and Rust consumers. Covers text model tiers, image and video generation models, image tool models, release provenance, pricing data sourcing, and product-side catalogue cost estimates. Use when bumping model versions, adding new models, updating pricing, or auditing model specs against provider documentation.

中文简介正在准备中。当前显示原文说明。

gridaco/grida26892026年10月19日 更新

React-specific code shape in the Grida editor. Hooks cannot be tested or benchmarked and silently break tuned UX under layered composition, so they are barred from the engine and main system — load-bearing logic lives in classes and namespaces, hooks only as thin edge wires. `data-testid` follows component-root discipline: one per significant component, not scattered. Use when authoring React in `editor/grida-canvas-react/`, `editor/components/`, `editor/scaffolds/`, or `editor/app/*`.

中文简介正在准备中。当前显示原文说明。

gridaco/grida26892026年10月19日 更新

code-ts

免费

TypeScript code shape inside a well-named module — taste, not lint. Prefer one class or namespace per file (the unit a test targets) over scattered free exports; consolidate related code, don't fragment. The unit of code should be the unit of spec. Use when authoring TS in `editor/grida-canvas*`, `editor/lib/`, or `packages/*`. Sibling to the `naming` skill; React-specific shape lives in `code-react`.

中文简介正在准备中。当前显示原文说明。

gridaco/grida26892026年10月19日 更新

database

免费

Use BEFORE editing any file in `supabase/migrations/` or `supabase/schemas/`, OR when the user runs a `/database` subcommand (`compact local migration`, `rls scenarios`, `align`). Encodes the three contracts that protect the Grida database layer: applied migrations are immutable, RLS implementation mirrors tests (never the reverse), `schemas/*.sql` is the human-readable end-state. Companion to `supabase/AGENTS.md` (RLS, grants, security boundaries).

中文简介正在准备中。当前显示原文说明。

gridaco/grida26892026年10月19日 更新

desktop

免费

Grida Desktop Electron shell and release-impact work: BrowserWindow, preload, `window.grida`, menus, protocol/deep links, file associations, Forge, path-scoped bridge security, Electron-only UI bugs, and CDP / Playwright verification. Use for `desktop/`, `editor/app/desktop/**`, `editor/scaffolds/desktop/**`, `editor/lib/desktop/**`, `/desktop/*` CSP, GRIDA-SEC-004, and deciding whether linked-package or hosted-renderer changes require a native Desktop version bump or coordinated release. For implementing daemon/agent-tenant core behavior, use `agent-system` as well.

中文简介正在准备中。当前显示原文说明。

gridaco/grida26892026年10月19日 更新

查看 gridaco 的全部技能

报告此技能的问题