Update to CmdBrief

{
  "description": "Plan a project as phases with checkable exit gates and open it in the CmdBrief Project plan panel, so the user can edit it and send it to a crew of coding agents on their Mac.",
  "included_files": [],
  "name": "plan-project",
  "skill_md_contents": "---\nname: plan-project\ndescription: Plan a project as phases with checkable exit gates and open it in the CmdBrief Project plan panel, so the user can edit it and send it to a crew of coding agents on their Mac.\n---\n\n# Plan a project for a CmdBrief crew\n\nUse this when the user wants to plan, scope or break down a project that a\ncrew of coding agents could build: a website, an app feature, a tool.\n\n## Shape of a plan\n\n- `title`: the project in a few words (\"Online ordering for the bakery site\").\n- `done_when`: one sentence that is true when the whole project is finished.\n- `phases`: 4 to 8, in order from start to release. Name each by its outcome\n  (\"Payments\", \"Kitchen view\"), not by a date.\n- `gates`: 2 to 5 per phase. A gate is something someone can check, with\n  evidence: \"Order form works on a phone\", \"Test payments go through in the\n  sandbox\". Never a task list (\"write the code\") and never a time.\n- Each gate has an `owner`:\n  - `you`: only the user can do or decide it: approve a design, connect an\n    account, announce the launch.\n  - `crew`: the agents can prove it with a build, a test or a report.\n- Limits CmdBrief keeps: title up to 80 characters, `done_when` up to 300,\n  phase names up to 60, gates up to 120, at most 12 phases and 8 gates each.\n- Images (optional): a logo you generated or one the user attached. Pass\n  them as the tools' inputs describe, with a `save_as` inside the project such\n  as `assets/logo.png` and a short `note` (\"App logo\"). PNG, JPEG, WebP or\n  GIF, up to 20 MB each and 50 MB together, at most 10. CmdBrief saves them\n  into the project when the user confirms. Never put a file path in gate\n  text; write \"Header uses the logo\" and pass the image.\n\n## Steps\n\n1. If the goal is unclear, ask at most two short questions first. Do not\n   invent facts about the user's business or code; leave them out or mark\n   them for the user to fill.\n2. Call `cmdbrief_plan` with the whole plan, a new opaque `draft_id`, and\n   `revision: 1`. It opens the Project plan view, where the user edits phases,\n   gates and owners. Keep this draft ID for revisions of the same project;\n   use a different ID for an independent draft.\n3. Tell the user, in a line or two, what the phases are and which gates are\n   theirs. Suggest edits they might want.\n4. When the user asks for changes, call `cmdbrief_plan` again with the\n   updated plan and the same draft ID, increasing the revision above the\n   latest revision reported by the view. Include the complete current image\n   set; omit removed images. The view also tells you about edits made there.\n5. When the user asks you to send it (\"send it to CmdBrief\", \"update\n   CmdBrief\"), call `cmdbrief_plan_send` with the whole plan, its images, draft\n   ID and revision, and a new opaque `operation_id`. Retry a timed-out send\n   with the same operation ID and unchanged content; use a new operation ID\n   when the revision or destination changes. Pass `workspace_id` only when they name a workspace. For a new\n   project, or when they ask for a new workspace, pass `new_workspace: true`:\n   CmdBrief makes a workspace named after it, with its own folder, when they\n   confirm. Left out, CmdBrief uses the workspace that already has this\n   project, else a new one; the user can change it in CmdBrief before\n   confirming.\n   They can also press **Send to CmdBrief** in the view. Either way the plan\n   only waits in CmdBrief until they confirm it there. Say where it went and\n   that they confirm it in CmdBrief; never say work has started. If CmdBrief\n   is closed, the plan waits in CmdBrief Cloud and arrives when it opens; say\n   that instead. Read the operation receipt: `accepted` means CmdBrief\n   staged it, `queued` means Cloud kept it, and `processing` means the result\n   is still unknown. For `processing`, retry the same operation to recover\n   its result; never claim it failed or create a second send automatically.\n   For `cancelled`, `expired` or `rejected`, explain the returned reason and\n   make any correction before a new send.\n6. After opening a plan, end with a short offer: \"Say *send it* and I'll send\n   it to CmdBrief.\"\n\n## Revising a project that already has a roadmap\n\nSend the whole revised plan the same way. Confirming it in CmdBrief updates\nthe project's roadmap instead of starting over: a phase with the same name\nand a gate with the same words keep their progress, new ones are added and\nwhat you leave out is dropped. So keep the names of phases and gates that\nhave not changed, word for word, and change only what should change. The\nproject's lead then gets what changed.\n"
}