Iterate on existing FLORA work
Hosted MCP generation inputs are plural: call flora_create_generations with { "generations": [{ "workspace_id": "ws_…", "project_id": "prj_…", "type": "image", "prompt": "…" }] } (1–20 items). Put per-generation fields, including optional model, params, and reference_node_ids, inside each item. Read generations[] in the response; retain successful entries' run_id and handle failures individually. Poll flora_list_generations with { "run_ids": ["run_…"] }, even for one run; add technique_id for technique runs. Never retry successful items because another item failed.
Use dedicated tools for this workflow, including batches. execute is deprecated; use it only for an SDK operation without a dedicated tool. SDK examples below describe orchestration: use the corresponding dedicated tools, issue independent calls concurrently, retain every run id, and poll in later calls. Do not choose execute just to combine calls.
A FLORA project outlives the conversation. Its canvas, every generation, and the
cost of each are all still there, so revision starts from what exists rather than
from a blank prompt.
Input: a project reference and the change wanted.
Output: what is on the canvas today, plus any regenerated assets.
Steps
Find the project. flora_list_projects (most recently active first) and
match on the user's wording. Never create a project when the user named an
existing one — ask if the name is ambiguous.
Read what is there. flora_get_canvas for structure and how nodes connect;
flora_list_canvas_nodes for the media nodes and their asset URLs. Use
flora_list_generations to see what was made, with cost and status.
Identify the assets the user means. Name them back before changing anything.
"Two hero images, both generated Tuesday" is confirmable; "the ones you meant"
is not.
Apply the change. Regenerate with flora_create_generations, or re-run the original
technique with flora_run_technique when the asset came from one —
flora_list_technique_runs shows which technique produced what.
Report the new outputs, their cost, and where they landed on the canvas.
Rules
- Read before writing. The user may have edited the canvas between turns.
- Additive only. Regenerating adds new nodes; it does not replace the
originals. Say so, so the user knows the earlier version is still there.
- Confirm before spending. State the cost of the regeneration and wait.
- You cannot see any asset. You have URLs, node labels, and generation
metadata. Reason from those; never claim to have looked at the artwork.
- Prefer the narrowest read that answers the question. A whole-canvas dump on a
large project is mostly noise.
1---2name: flora-canvas-iterate3description: Find and build on work that already exists in a FLORA project — inspect a canvas, review past generations and what they cost, and regenerate specific assets with new direction applied. Use when the user refers to a named project, "my canvas", or earlier work ("the hero images from last week", "what's in the Meridian project"). Do not use to start new work in an empty project.4---56# Iterate on existing FLORA work78Hosted MCP generation inputs are plural: call `flora_create_generations` with `{ "generations": [{ "workspace_id": "ws_…", "project_id": "prj_…", "type": "image", "prompt": "…" }] }` (1–20 items). Put per-generation fields, including optional `model`, `params`, and `reference_node_ids`, inside each item. Read `generations[]` in the response; retain successful entries' `run_id` and handle failures individually. Poll `flora_list_generations` with `{ "run_ids": ["run_…"] }`, even for one run; add `technique_id` for technique runs. Never retry successful items because another item failed.910Use dedicated tools for this workflow, including batches. `execute` is deprecated; use it only for an SDK operation without a dedicated tool. SDK examples below describe orchestration: use the corresponding dedicated tools, issue independent calls concurrently, retain every run id, and poll in later calls. Do not choose `execute` just to combine calls.1112A FLORA project outlives the conversation. Its canvas, every generation, and the13cost of each are all still there, so revision starts from what exists rather than14from a blank prompt.1516**Input:** a project reference and the change wanted.17**Output:** what is on the canvas today, plus any regenerated assets.1819## Steps20211. **Find the project.** `flora_list_projects` (most recently active first) and22 match on the user's wording. Never create a project when the user named an23 existing one — ask if the name is ambiguous.24252. **Read what is there.** `flora_get_canvas` for structure and how nodes connect;26 `flora_list_canvas_nodes` for the media nodes and their asset URLs. Use27 `flora_list_generations` to see what was made, with cost and status.28293. **Identify the assets the user means.** Name them back before changing anything.30 "Two hero images, both generated Tuesday" is confirmable; "the ones you meant"31 is not.32334. **Apply the change.** Regenerate with `flora_create_generations`, or re-run the original34 technique with `flora_run_technique` when the asset came from one —35 `flora_list_technique_runs` shows which technique produced what.36375. **Report** the new outputs, their cost, and where they landed on the canvas.3839## Rules4041- **Read before writing.** The user may have edited the canvas between turns.42- **Additive only.** Regenerating adds new nodes; it does not replace the43 originals. Say so, so the user knows the earlier version is still there.44- **Confirm before spending.** State the cost of the regeneration and wait.45- **You cannot see any asset.** You have URLs, node labels, and generation46 metadata. Reason from those; never claim to have looked at the artwork.47- Prefer the narrowest read that answers the question. A whole-canvas dump on a48 large project is mostly noise.