@zvada/cr8 0.2.0 → 0.3.0

package/skills/cr8-design/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: cr8-design
 description: Design in CR8 as the designer, from a brief or a reference, through its MCP or CLI surfaces. Use for new product screens, landing pages, marketing visuals, App Store screenshots, faithful reproduction of an existing page or picture, and any task where an agent designs on a canvas while a person watches or collaborates.
-allowed-tools: Bash(cr8:*), Bash(npx @zvada/cr8@0.2.0:*)
+allowed-tools: Bash(cr8:*), Bash(npx @zvada/cr8@0.3.0:*)
 ---
 
 # CR8 Design
 
-You are the designer. The person watches the canvas and edits beside you; you work it through MCP or the CLI. CR8's playbooks and styles are the taste, loaded fresh each time; the files under `references/` hold the detail (`canvas_skill` with `name` and `path`, or `cr8 skills get cr8-design --path references/x.md`).
+You are the designer. The person watches the canvas and edits beside you; you work it through MCP or the CLI. CR8's playbooks and styles are the taste, loaded fresh each time; the files under `references/` hold the detail (`read_skill` with `name` and `path`, or `cr8 skills get cr8-design --path references/x.md`).
 
 Use the MCP server or CLI from the installation that supplied this skill. Check unfamiliar commands with `cr8 --help` and `cr8 schema --command TYPE`; if a source checkout describes a command missing from a published fallback, use the matching checkout build or update the installed plugin.
 

package/skills/cr8-design/references/start.md

@@ -13,7 +13,7 @@ Choose by deliverable:
 - `web-app`: dense web and desktop product surfaces.
 - `canvas-foundations`: the default structure and verification discipline; enough on its own for a single simple artboard.
 
-A playbook that lists no styles is used alone. `canvas_guide` is a compatibility alias for older agents; new work names playbooks and styles explicitly.
+A playbook that lists no styles is used alone.
 
 ## Projects
 

package/skills/cr8-flows/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: cr8-flows
 description: Build, run and reuse CR8 Flows, node graphs over image, vector and video models, through its MCP or CLI surfaces. Use when a task needs several generations in sequence or in parallel, a repeatable recipe a person can rerun and edit, a video or vector step, or a chain such as draft, edit, upscale; and when a person asks for variations, a campaign kit, or a pipeline rather than one picture.
-allowed-tools: Bash(cr8:*), Bash(npx @zvada/cr8@0.2.0:*)
+allowed-tools: Bash(cr8:*), Bash(npx @zvada/cr8@0.3.0:*)
 ---
 
 # CR8 Flows
 
-A flow is a small graph saved in the project's `flows.json`: input steps, model steps and output steps, wired by typed ports. The person sees it as cards on a canvas, watches a run step by step, and can rerun or edit it later. Use a flow when the work is more than one generation, when it should be repeatable, or when it needs video, vector or an edit chain; use `canvas_generate` for one picture straight onto a design. This file is the contract; the files under `references/` hold the detail, read with `canvas_skill` (`name` and `path`) or `cr8 skills get cr8-flows --path references/<file>`.
+A flow is a small graph saved in the project's `flows.json`: input steps, model steps and output steps, wired by typed ports. The person sees it as cards on a canvas, watches a run step by step, and can rerun or edit it later. Use a flow when the work is more than one generation, when it should be repeatable, or when it needs video, vector or an edit chain; use `canvas_generate` for one picture straight onto a design. This file is the contract; the files under `references/` hold the detail, read with `read_skill` (`name` and `path`) or `cr8 skills get cr8-flows --path references/<file>`.
 
 ## Start
 
@@ -20,7 +20,7 @@ You mint every id (flow, steps, edges): kebab-case, unique in the project. Steps
 
 ## Run and results
 
-`workflow_run` runs the saved revision and answers with every output; `wait: false` answers at once and `workflow_run_status` follows it; `fromNodeId` reruns one step and what is downstream of it, reusing the rest. A failed run answers a `recovery` sentence. Images and SVGs are copied into the project's `assets/` and recorded in `flow-runs.json` (a clip stays on its cloud path); judge them by looking: `workflow_place_output` with `all: true` makes a review board, and without it places one output on an artboard. Detail in `references/run.md` and `references/results.md`.
+`workflow_run` runs the saved revision and answers with every output; `wait: false` answers at once and `workflow_run_status` follows it; `fromNodeId` reruns one step and what is downstream of it, reusing the rest. A failed run answers a `recovery` sentence. Generated outputs stay on managed cloud paths, with their last result recorded in `flow-runs.json`. Judge them by looking: `workflow_place_output` copies images or SVGs into the project's immutable assets and inserts them in one scene transaction; `all: true` makes a review board, and without it one output is placed on an artboard. Clips stay in Flows. Detail in `references/run.md` and `references/results.md`.
 
 ## Account
 

package/skills/cr8-flows/references/results.md

@@ -2,11 +2,11 @@
 
 ## Where outputs land
 
-A completed run's images and SVGs are copied into the project's `assets/` and recorded in `flow-runs.json` beside `flows.json`, so the Flows home shows what each flow last made and a clone of the repository shows the same. Each output's `file` is that copy's workspace-relative path. A clip stays on its cloud path, watched in Flows; `workflow_place_output` refuses it (`clip_stays_cloud`).
+Flow outputs stay on their managed cloud `src`, with generation provenance. `flow-runs.json` beside `flows.json` records the last result so the graph can show it again; it does not make the output available offline. An output has `file` only when it already references a local project asset. **Add to Design** / `workflow_place_output` copies and validates image or SVG bytes into the project's immutable `assets/` before inserting an asset and layer in one scene transaction. Clips stay in Flows (`clip_stays_cloud`).
 
 ## Judge by looking
 
-Never judge a run by its status. Open each `file`, or make a review board: `workflow_place_output` with `all: true` (CLI `workflow-place ID --all`) puts every output of the last run on one review artboard named after the flow, side by side at equal height, to the right of everything on the design; it answers the board's `artboardId`, its `x`, `y`, `width` and `height`, and `placed`, each output's layer and `file`. Read that artboard (export it with `canvas_export`, or look in the browser). Compose your own artboards clear of the board, since `canvas_doctor` names root artboards that overlap. `canvas_doctor` checks structure and legibility, not the brief.
+Never judge a run by its status. Inspect each output in Flows, open `file` when present, or make a review board: `workflow_place_output` with `all: true` (CLI `workflow-place ID --all`) puts every output of the last run on one review artboard named after the flow, side by side at equal height, to the right of everything on the design; it answers the board's `artboardId`, its `x`, `y`, `width` and `height`, and `placed`, each output's layer and `file`. Read that artboard (export it with `canvas_export`, or look in the browser). Compose your own artboards clear of the board, since `canvas_doctor` names root artboards that overlap. `canvas_doctor` checks structure and legibility, not the brief.
 
 ## Place one output on a design
 

package/skills/cr8-flows/references/run.md

@@ -18,4 +18,4 @@ A run refused before any step with `connection_required` or `connection_expired`
 
 ## What a run answers
 
-On the CLI, `workflow-run` and `workflow-run-status` answer compactly: each step's status and each output with its `file`, the copied path in the project (`designs/<name>/assets/sha256-….webp`) for an image or an SVG; a clip has no `file` and keeps its cloud `src`. `--full` adds the provenance and the prompts sent. Over MCP the answer is the whole run: `status`, `nodeResults` (each step's status, artifact and provider ids), `outputs` (each with `outputNodeId`, `sourceNodeId`, the `asset`, and `file` when the project holds a copy), and on failure `failedNodeId` and `recovery`.
+On the CLI, `workflow-run` and `workflow-run-status` answer compactly: each step's status and each output's managed `src`; `file` is present only for an existing local project asset. New generated images, SVGs and clips stay on their cloud paths until an explicit download or placement. `--full` adds the provenance and the prompts sent. Over MCP the answer is the whole run: `status`, `nodeResults` (each step's status, artifact and provider ids), `outputs` (each with `outputNodeId`, `sourceNodeId`, the `asset`, and `file` when the project holds a copy), and on failure `failedNodeId` and `recovery`.