@compilr-dev/sdk 0.18.0 → 0.18.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -70,7 +70,9 @@ export function createCanvasTools(config) {
|
|
|
70
70
|
'Bind params in your HTML via CSS custom properties var(--param), [data-bind="param"] text, and ' +
|
|
71
71
|
'[data-show="param"] visibility; for computed updates define window.applyParams(values) in a <script>. ' +
|
|
72
72
|
'Omit canvas_id to create. To EDIT an existing canvas, prefer canvas_edit (str_replace) — it avoids ' +
|
|
73
|
-
're-sending the whole document; only use canvas_write with canvas_id for a full intentional replace.'
|
|
73
|
+
're-sending the whole document; only use canvas_write with canvas_id for a full intentional replace. ' +
|
|
74
|
+
'Before creating a NEW canvas, gather the essentials from the user (purpose, type, key content, style) ' +
|
|
75
|
+
'with ask_user unless they already specified them — authoring on guessed requirements wastes a full pass.',
|
|
74
76
|
inputSchema: {
|
|
75
77
|
type: 'object',
|
|
76
78
|
properties: {
|
|
@@ -35,7 +35,13 @@ export const canvasSkill = defineSkill({
|
|
|
35
35
|
|
|
36
36
|
## STEPS
|
|
37
37
|
|
|
38
|
-
1. **
|
|
38
|
+
1. **Collect the essentials from the user FIRST — this is the standard approach.** A canvas is an expensive authoring pass; building it on guessed requirements wastes that pass and lands wide of what the user wanted. So before you author, use **\`ask_user\`** (batch several questions into ONE call) to gather what the canvas needs:
|
|
39
|
+
- **Purpose & audience** — what is it for, who reads it?
|
|
40
|
+
- **Canvas type** — infographic, carousel, or board? (Offer the choice unless obvious.)
|
|
41
|
+
- **Key content / data** — the actual points, numbers, sections, or slides to include. Don't invent data.
|
|
42
|
+
- **Style / brand** — theme-matched (default) or a specific palette/brand?
|
|
43
|
+
For open design directions (which layout, which visual approach), present concrete options with **\`propose_alternatives\`** instead of guessing.
|
|
44
|
+
**Skip questions the user already answered**, and if they gave full detail or explicitly said "just make it / surprise me / your call", go straight to authoring. Keep it to ONE focused round — a short question batch, never a long interview — then build.
|
|
39
45
|
|
|
40
46
|
2. **Build the canvas in small steps — never one giant tool call.** A canvas is HTML/SVG you emit as tool arguments; a single very large \`canvas_write\` can overrun the output limit, get cut off mid-arguments, and fail. So author it incrementally, and emit each tool call immediately with NO prose preamble (narration competes with the HTML for the same output budget):
|
|
41
47
|
- **2a. First \`canvas_write\`** (type, title, html) = a COMPACT skeleton: the \`<style>\` block, the overall layout, and just the first section or heading. This is the ONLY way to create a canvas — describing it in chat does nothing.
|