本文へ移動
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(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

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/grida2,6662026年10月9日 更新

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 provider-cost metering against prepaid org credit. Use when bumping model versions, adding new models, updating pricing, or auditing model specs against provider documentation.

日本語の概要は準備中です。原文の説明を表示しています。

gridaco/grida2,6662026年10月9日 更新

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/grida2,6662026年10月9日 更新

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/grida2,6662026年10月9日 更新

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/grida2,6662026年10月9日 更新

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/grida2,6662026年10月9日 更新

gridaco のスキルをすべて見る

このスキルの問題を報告する