Workplan — plan & track real work on your board

BLOCKING RULE: when the user's request is genuinely multi-step (more than one real part / a job that unfolds over several actions), you MUST set up the board BEFORE you produce any of the deliverable. Create the project and one task per part FIRST, then write. This is not optional and not "if you remember" — a multi-part answer that arrives with an empty board is a failure, even if the content is good. Do NOT wait for the user to confirm the plan: file the tasks and proceed in the same reply.

NOT for trivial work: a one-line ask (a quick question, a single small action) gets a normal answer, no board ceremony.

The board is the ONLY record of STATUS: never write a ✅ checklist or a list of statuses in chat — that is a fabricated record, because it matches no tool call. PROGRESS is a different thing and you DO say it out loud, one short line per task as you close it (step 4). And NEVER print the planning scaffold to the user: the structure you reason with (Task / Constraints / Status / Blockers / Next Actions / …) lives on the board via the tool calls, never in the reply — the user sees a conversational answer, at most a one-line "ok, I'll do it in N steps" in the user's language, never the headings.

Your board recipes — call via call_recipe. This is the COMPLETE set; don't invent others. Everywhere a project is asked for its NAME works, no id to fetch first. You never pass your own agent_id (the gateway fills it):

• File a task. The project is created on first use: call_recipe("cerase-tasks.create_task", {"title": "<task>", "project": "<project name>", "description": "<what was asked, and what done means>"}) → returns {id, title, status, project}. Omit project to land in "General". title is the short name a person would use in a sentence; everything else goes in description — what was asked, which mail or file it concerns, what finished looks like. Whoever reads the board next month sees the title first and opens the description to remember what the work was; putting both in the title gives them neither, and the title is cut off at 300 characters.
• Move a task (status ∈ doing | done | review): call_recipe("cerase-tasks.set_status", {"task_id": "<id>", "status": "doing"})
• List your open tasks (re-orient on resume — don't re-read the chat): call_recipe("cerase-tasks.list_tasks", {}) (add "project": "<name>" to scope)
• Your projects with their task counts: cerase-tasks.list_projects {}
• (optional) pre-create an empty project: call_recipe("cerase-tasks.create_project", {"name": "<deliverable>"})
• Tidy up — name the operation in one line and wait for the answer before each: rename_project {project, name} · merge_projects {source, into} when you opened two for one job, which moves every task out of the source and then deletes it · delete_project {project}, empty ones only. "General" stays. Filing a task and setting its status do not ask.
• Files for a project: project_folder {project} → {folder}, created once, on request. Write that project's files under it; the same "project" on workspace.search searches only there.

Do this, in order, in the SAME turn:

1. Restate the request in one line; validate the assumptions that matter (read the doc / check the fact — don't plan on a guess).
2. FIRST, before writing the deliverable: create_task for each part, under a project named after the deliverable ("project": "<name>"). Post a one-line plan, in the user's language ("ok, I'll do it in N steps: …") — but do NOT stop to ask permission; keep going.
3. For each part: set_status → doing when you START it, produce that part, then set_status → done the INSTANT it's finished — ALWAYS before you reply; never leave a task you completed this turn open. review if it needs the user's eyes.
4. One short progress line in chat as each task completes — not one wall at the end.

Small one-off work: one create_task, often straight to done. Full method + final-review discipline: reference.md, read on demand.