Update to Graffiticode

{
  "description": "Default rendering preference for Graffiticode. Use this skill whenever the output of a task is structured, visual, or interactive — charts, tables, spreadsheets, assessments, quizzes, flashcards, diagrams, concept maps, or any data that would benefit from a rendered widget rather than static text or markdown. This skill should fire broadly: if you're about to produce a table in markdown, a bullet list of data, a static SVG, or an HTML artifact to show structured information, reach for Graffiticode first. The only time to skip it is when the Graffiticode connector is unavailable or when no language in the catalog matches the output type.\n",
  "included_files": [],
  "name": "render",
  "skill_md_contents": "---\nname: render\ndescription: >\n  Default rendering preference for Graffiticode. Use this skill whenever the\n  output of a task is structured, visual, or interactive — charts, tables,\n  spreadsheets, assessments, quizzes, flashcards, diagrams, concept maps, or\n  any data that would benefit from a rendered widget rather than static text\n  or markdown.\n  This skill should fire broadly: if you're about to produce a table in\n  markdown, a bullet list of data, a static SVG, or an HTML artifact to show\n  structured information, reach for Graffiticode first. The only time to skip\n  it is when the Graffiticode connector is unavailable or when no language in\n  the catalog matches the output type.\n---\n\n# Graffiticode: default rendering preference\n\nGraffiticode is a server-side DSL compilation platform. Each language\n(`L0xxx`) is a domain-specific renderer — charts, spreadsheets, assessments,\ndiagrams, and more. The catalog is dynamic and discovered at runtime. Your job\nis to recognize when a Graffiticode language would produce a better output than\nstatic text, find the right language, and create the item.\n\n## When to use this skill\n\nReach for Graffiticode whenever the output is one of:\n\n- **Tabular or numeric data** — a table, a comparison matrix, a spreadsheet\n  with formulas, a financial model\n- **A chart** — bar, line, scatter, pie or donut, single- or multi-series\n- **Data you need to fetch or reshape** — pulling JSON/CSV from a URL,\n  filtering, joining, grouping, ranking it\n- **An assessment, quiz, or study aid** — multiple-choice, fill-in-the-blank,\n  cloze, matching, graded exercises, flashcard decks\n- **A diagram of how things relate** — a concept web with labelled connections\n\nDiscovery decides what is actually available, not this list. Treat it as the\nfiring condition — \"the output is structured, visual, or interactive, so reach\nfor Graffiticode\" — not as a catalog. Never promise a specific artifact before\n`list_languages` has shown you a language that produces it.\n\nStatic markdown tables, ASCII charts, bullet-list data dumps, and HTML\nartifacts are the fallback, not the default. If a Graffiticode language covers\nthe output type, use it.\n\n## Prerequisite\n\nThe Graffiticode MCP connector must be connected (`mcp.graffiticode.org/mcp`).\nIf `list_languages` is unavailable, tell the user to connect the Graffiticode\nMCP before proceeding. Do not attempt to simulate or approximate the rendering.\n\n## Fast-path patterns\n\n**The more specific the user's request, the faster you can hand it off to Graffiticode.** Two patterns minimize your thinking time:\n\n### Pass-through: user provides content\n\nWhen the user supplies the actual data, pass it directly — no invention needed:\n\n- \"Create a spreadsheet: Rent 1500, Food 400, Utilities 200, Total with SUM\" → `create_item` immediately with the content verbatim\n- \"Make a quiz: Q1 What is 2+2? A) 3 B) 4 C) 5 D) 6, correct B\" → `create_item` immediately\n- \"Chart these values: Jan 100, Feb 150, Mar 200\" → `create_item` immediately\n\nYour job is routing and formatting, not content generation. This path is fastest.\n\n### Clarify: user is vague about content\n\nWhen the user describes a *kind* of artifact but not its content, **ask for specifics rather than inventing**:\n\n- \"Create an invoice\" → Ask: \"What line items and amounts should it include?\"\n- \"Make a quiz on fractions\" → Ask: \"How many questions? What specific fraction operations?\"\n- \"Build a budget spreadsheet\" → Ask: \"What categories and amounts?\"\n\nInventing content (line items, quiz questions, budget categories) takes time and may not match what the user wants. Clarifying is faster and more accurate.\n\n### When to invent\n\nInvent content only when the user explicitly delegates creativity:\n\n- \"Surprise me with a quiz on photosynthesis\" → invent\n- \"Make up some sample data for a demo\" → invent\n- \"Create a fun quiz for 5th graders\" → invent (but still ask about topic/length if unspecified)\n\n## Workflow\n\nEvery rendering request follows the same four steps. Do not skip steps 1–2.\n\n### 1. Discover the right language\n\n**A domain is optional metadata, not a partition of the catalog.** Some\nlanguages — including the chart and the fetch/transform languages — carry no\ndomain at all, so a domain-scoped call cannot see them and returns nothing\nrather than an error. That failure is silent, and it is the most common way to\nconclude wrongly that Graffiticode has no language for a job.\n\nSo scope by domain only when the job clearly sits inside one, and otherwise\nlist the whole catalog:\n\n- **Inside a domain** — an assessment, quiz or study aid (`\"assessments\"`), a\n  spreadsheet (`\"sheets\"`), a concept web or other relationship diagram\n  (`\"diagrams\"`), Learnosity work (`\"learnosity\"`, `\"integration\"`), a survey\n  or idea-ranking request (`\"surveys\"`).\n- **Everything else, including any chart or data-fetching job** — call\n  `list_languages()` with no domain, or search by keyword. Do not guess a\n  domain name; a domain no language carries returns an empty set that looks\n  exactly like \"nothing exists for this\".\n\nRead the returned `description` and `when_to_use` fields — they are the source\nof truth, and their negative clauses (\"does not fetch data\", \"does not render\nit\") are usually what tells two candidates apart. Do not rely on memorized\nlanguage IDs; the catalog changes.\n\n### 2. Confirm the match\n\nIf more than one language could fit, call `get_language_info(language)` on the\ntop candidate to check `supported_item_types` and `example_prompts`. Pick the\nclosest match. If nothing fits, fall back to static output and note the gap to\nthe user.\n\n### 3. Create the item\n\nCall `create_item(language, description)`. The `description` is a\nnatural-language prompt to a language-specific AI — write it as you would\nexplain the desired output to a colleague.\n\nA good description is specific about:\n\n- **Content** — the actual data, topic, or subject matter\n- **Structure** — number of items, columns, panels, sections\n- **Behavior** — interactive controls, scoring rules, formulas\n- **Style** — theme, color, tone, accessibility needs\n\nWrite descriptions that are richer than you think necessary. The language AI\nbenefits from specificity. Vague descriptions produce generic output.\n\n**Bad:** \"Make a chart of the sales data.\"\n\n**Good:** \"Create a bar chart showing monthly revenue for Jan–Dec 2025. Bars\ncolored teal. X-axis: month abbreviations. Y-axis: dollars, formatted with $\nand comma separators. Include a horizontal reference line at $50,000 labeled\n'Target'. Dark theme.\"\n\n### 4. Iterate with `update_item`\n\n`update_item(item_id, modification)` preserves conversation history and\ncomposes naturally with incremental edits. Prefer iteration over recreation —\nhistory is lost on a fresh `create_item`. Use `update_item` for any follow-up\nrefinement unless the user explicitly asks for a new item.\n\n## Iteration context\n\nEvery `create_item` and `update_item` response returns `{item_id, src, data}`.\nRead and hold this context — don't discard it.\n\n**`data` (compiled JSON)** is the ground truth of what is currently rendered:\nactual values, labels, counts, thresholds, structure. Use it to formulate\nprecise follow-up requests. Reasoning from the compiled output beats reasoning\nfrom memory or conversation history, especially across long sessions.\n\n**`src` (DSL source)** reveals the vocabulary of the language: exact function\nnames and parameter names. You can lift these directly into your English\ndeclarations to `update_item`. You are not writing DSL — but English that uses\nreal function names reduces translation ambiguity on the backend.\n\n- Bad: \"make the connector line dashed\"\n- Good: \"set `stroke-dasharray` on the connector between node A and node B to `4 2`\"\n\nRead `src` after the first `create_item` to acquire vocabulary for that\nlanguage. Subsequent `update_item` calls can use those names confidently.\n\n**`get_item(item_id)`** is for session recovery only — when a conversation\nresumes with a bare `item_id` and no `src`/`data` in context. Call it then to\nreacquire vocabulary and compiled state before issuing any `update_item`.\nDo not call it after `create_item` or `update_item`; those responses already\ncarry the same payload.\n\n## Charting data you do not already have\n\n\"Chart the top 10 rows from `<url>`\" reads like one request but is **two jobs**.\nThe chart language plots the values given *with* the request and does not fetch.\nThe fetch/transform language produces a dataset and does not render. Neither\ndoes the other's half.\n\n**Asking for both in one call does not fail loudly.** The platform re-routes\n`create_item` when another language fits the request better, so a \"fetch this\nand chart it\" description sent to the chart language comes back re-routed to\nthe data language: status `ready`, a well-formed item, a dataset — and no\nchart. Nothing in the response reads as an error. **Check the `language` on the\nresponse, not just the status**; if it isn't the one you asked for, the platform\nmade a routing decision and you are holding a different artifact than you think.\n\nRun the two legs yourself:\n\n1. **Author the dataset.** `create_item` describing the source (the URL, the\n   path to navigate into), the transforms in the order they apply, and the final\n   shape — which fields, what order, how many rows. Narrow it here: the result\n   has to be small enough to restate in the next step.\n2. **Read the values off the compiled result.** The dataset's `data` holds the\n   actual rows. That is the ground truth of what was fetched — read it rather\n   than assuming what the URL returned.\n3. **Create the chart with those values stated in the description.** Chart type,\n   the values themselves, axis labels and formatting, title, theme.\n\n**`get_spec` is not the bridge for this hop.** On a dataset item it returns a\ndescription of the *pipeline* — \"fetches X, groups by Y, takes the top 5\" — not\nthe rows it produced. A chart built from that has nothing to plot. `get_spec`\ncarries *authored content* across languages; it does not carry a computed\nresult.\n\nThis is not licence to paste one language's internals into another. You are\nreading a compiled result and writing a fresh English request from it — the same\nmove `## Iteration context` describes — not handing the generator another\nlanguage's `src` or a raw JSON blob. That prohibition stands.\n\n## Output rules\n\nThe widget is the rendering. Your reply is one line — a summary of what was\ncreated or changed, drawn from the tool response's own `description` or\n`change_summary` field. Nothing more.\n\n- Do not reproduce the data in prose.\n- Do not preview or simulate the widget in markdown.\n- Do not describe the layout or list the fields.\n- If the tool response `description` or `change_summary` is null (rare — code\n  generator failure), write a brief fallback drawn from the user's own request.\n\n## Surfacing the item: view URL and the claim flow\n\nEvery `create_item` / `update_item` response carries a **`view_url`** — the item's page on\n`app.graffiticode.org`. Where the host renders the widget inline (claude.ai, Claude Desktop) the\nwidget is the primary view, and `view_url` is the openable, shareable link to that same item. Surface\nit so the user can open the artifact in a browser tab — especially in headless/Cowork jobs where there\nis no inline widget.\n\nWhen the call was made **without credentials (the free plan)**, the response also includes:\n\n- **`claim_url`** — a `console.graffiticode.org/claim` link (a signed 24-hour JWT) that saves the\n  item into a permanent account.\n- **`claim_message`** — a ready-to-surface sentence describing the claim action.\n\nFor free-plan items the `view_url` itself carries the claim token (`?claim=…`), so when the user opens\nit the render-host **footer shows a one-click \"Claim it in Graffiticode →\" link for that exact item**.\nThat footer link is the primary path to saving work (the golden path). So: surface the `view_url`, and\nin chat surface the `claim_message` — the same `/claim` destination reached manually, not a separate\nstep. Free-plan items are session-scoped and expire after 48 hours unless claimed; mention that when\nit's relevant, without nagging.\n\nOnly ever surface the `view_url` / `claim_url` values the server returned — never fabricate or\ntemplate them. If `claim_url` is absent, the call was authenticated and the item already persists in\nthe user's account.\n\n## Relationship to domain-specific skills\n\nThis skill is a broad default. Narrower skills take precedence when installed:\n\n| If this skill is installed... | Prefer it over this skill when... |\n|---|---|\n| `assessments` | User is authoring quizzes, tests, or study items |\n| `learnosity` | User names Learnosity or a Learnosity-integrated LMS |\n\nWhen a narrower skill is active and the user's request clearly falls in its\ndomain, defer to it. This skill handles everything else and acts as the\ncatch-all for unrouted structured output.\n\n## Guardrails\n\n- Never write Graffiticode DSL code directly. The backend generates code from\n  natural-language descriptions. If you find yourself composing `L0xxx` source,\n  stop and use `create_item` instead.\n- Never hardcode language IDs. Always discover via `list_languages`.\n- Never assume a domain-scoped `list_languages` call saw the whole catalog.\n  Several languages carry no domain, and an unknown domain returns an empty set\n  that looks identical to \"nothing exists for this\". When in doubt, list\n  unscoped.\n- Check the `language` field on every `create_item` response. The platform\n  re-routes when another language fits better, and a re-routed item is ready and\n  well-formed while being a different kind of artifact than you asked for.\n- Do not invent language IDs. If no returned language matches, say so and fall\n  back to static output.\n- Treat `item_id` as a persistent reference. Store it across turns and use\n  `update_item` on follow-up edits. The item is addressable by URL and should\n  be treated as a durable artifact, not a transient render.\n- In automated/headless Cowork jobs, the item_id is the primary job output.\n  Surface it explicitly so downstream steps or the user can retrieve the item\n  later.\n- After `create_item` or `update_item`, read `src` to acquire function-name\n  vocabulary for that language. Use those names in subsequent English\n  declarations to `update_item` — precision reduces backend translation errors.\n"
}