Update to Flambé

{
  "description": "Track substantial or multi-step work in Flambe as a truthful live call stack. Use the Flambe MCP tools to start, nest, suspend, resume, end, plan, and review work while following Reducer Agent direction.",
  "included_files": [],
  "name": "flambe",
  "skill_md_contents": "---\nname: flambe\ndescription: Track substantial or multi-step work in Flambe as a truthful live call stack. Use the Flambe MCP tools to start, nest, suspend, resume, end, plan, and review work while following Reducer Agent direction.\n---\n\n# Flambe\n\nUse Flambe to record **semantic work units** as a live flame chart. Do not log every command, file open, tool call, or hidden reasoning step. Skip trivial one-offs.\n\nThe MCP server is the execution layer. This skill is the workflow layer.\n\n## Establish context\n\nThe bundled MCP connection accesses **Cloud** at `https://flambe.fly.dev/mcp`.\nIt cannot access **Single Burner** or **Development**. A trace id selects data\ninside one instance; it does not switch instances. Discussing or developing\nSingle Burner does not authorize recording that work in Cloud.\n\nOn the first Flambe interaction in a conversation, and after an explicit switch:\n\n- Resolve the user's intended instance: **Cloud**, **Single Burner**, or **Development**. Use a separately connected local instance only when its tools are available and the user has selected it. If intent is ambiguous and more than one connection is available, ask which instance before reading activity data or writing.\n- Call `flambe_traces` on the intended connection, even if a trace id was mentioned earlier. Verify the returned `instance` matches the requested destination. If that connection is unavailable, explain that it is not connected; never substitute Cloud or another instance.\n- Briefly name the instance when establishing or switching context, for example: \"Using Single Burner for this chat.\"\n- Keep the connection, `instance.id`, and `trace_id` together for this conversation. Reuse a trace id only when it belongs to that verified instance. If the user names a trace, match it inside that instance; otherwise use `default_trace_id`.\n- Pass the exact returned `instance.id` as `expected_instance_id` on every other Flambe tool call, including status reads. Never infer it from a label or copy it between connections.\n- Check `instance` in every result, including errors. On `INSTANCE_REQUIRED` or `INSTANCE_MISMATCH`, stop the attempted operation and rediscover the intended connection. Do not replace the expected id with a different instance's id just to make the request succeed.\n- Stay with the selected instance until the user explicitly switches. On a switch, discard the previous instance's trace/activity ids and rediscover on the new connection.\n- Create one stable conversation-local `agent_id` such as `chatgpt:<8 random lowercase hex characters>` and reuse it for every Flambe tool call in this conversation.\n- Pass `platform: \"ChatGPT\"`.\n- Do not invent an `agent_name`; let the Reducer Agent name the agent.\n\nDo not list threads or categories merely to decide placement. The reducer owns placement.\n\n## Think in a stack\n\nTreat attention as a **call stack**, not a flat to-do list.\n\nWhen work on a parent goal exposes a specific bug, prerequisite, design question, test failure, or verification step, that is a **push**: call `flambe_start` for a nested activity and leave the parent running.\n\nWhen the nested work is complete, **pop** it with `flambe_end` and continue the parent.\n\n- Leave parents running while going deeper.\n- Put nested work under the workstream it serves, not beside the root.\n- When moving to a true sibling, end the current leaf first, then start the sibling.\n- Use `parent_id: null` only for a genuinely new top-level workstream.\n- Omit `parent_id` to let the reducer infer this agent's active parent.\n- Keep the active stack truthful as attention changes. Do not pre-plan a detailed flame or reconstruct one after the fact.\n\n## Tool mapping\n\nUse the MCP tools directly:\n\n- `flambe_start`: begin meaningful work. Keep names concrete and under 255 characters.\n- `flambe_end`: finish work. Prefer an outcome message over a generic \"done\".\n- `flambe_suspend`: explicitly table work that is being paused.\n- `flambe_resume`: resume suspended work.\n- `flambe_status`: inspect active, suspended, or unstarted work.\n- `flambe_plan`: create future or limbo work without beginning it.\n- `flambe_message`: ask the Reducer Agent about scope, drift, or a requested change in approach.\n- `flambe_traces`: establish the connected instance and discover its traces before first use or an explicit switch.\n\n## Every lifecycle call is a proposal\n\nThe reducer may rewrite what you proposed. Always read the complete result from `flambe_start`, `flambe_end`, `flambe_suspend`, `flambe_resume`, and `flambe_message`.\n\nThe result may contain:\n\n- `direction`\n- `reply`\n- `actions_applied`\n- corrected parent/thread placement\n- duplicate reuse or ancestor resumption\n- descendant closure when a parent ends with force\n\nThe returned state is authoritative. Do not undo a reducer rewrite and do not re-issue a proposal merely because the reducer changed it.\n\nIf `direction` is `pause`, `stop`, or `escalate`, stop further work and surface the reducer's reply to the user before continuing.\n\nIf the reducer asks a question in `reply`, answer it before making another substantive stack change, normally with `flambe_message`.\n\n## Ask the reducer before drifting\n\nCall `flambe_message` when you are about to:\n\n- widen scope beyond the activity you started\n- switch approach because the current plan stalled\n- end a root workstream\n- continue while suspecting the work has drifted from the user's request\n- answer a question the reducer asked\n\nDo not use `flambe_message` for routine progress, and do not use it instead of lifecycle tools.\n\nIf the server reports `REDUCER_NOT_CONFIGURED`, do not retry. Continue deterministic lifecycle tracking and surface any unresolved judgment to the user.\n\n## Status lookup\n\nReuse activity ids returned earlier in the conversation.\n\nCall `flambe_status` only when you need to recover a matching open activity, inspect suspended work, or check unstarted work. Prefer:\n\n- `active_only: true` when recovering the current stack.\n- `include_unstarted: true` at the end of substantial work.\n\nIgnore unrelated work owned by other agents.\n\n## Ending substantial work\n\nBefore stopping after substantial work:\n\n1. End the current leaf with its concrete outcome.\n2. Pop completed ancestors when their goals are actually complete.\n3. Call `flambe_status` with `include_unstarted: true`.\n4. If a plausible next activity exists, report it to the reducer with `flambe_message`. Begin it only when the returned direction says to continue.\n\nDo not begin unrelated planned work merely because it exists.\n\n## What belongs in the flame\n\nStart a new activity when the goal or scope meaningfully changes, such as:\n\n- a focused implementation\n- a discovered prerequisite\n- a concrete bug\n- a design decision that needs investigation\n- focused tests\n- verification of the result\n\nDo not create activities for commits, pushes, file reads, shell commands, individual tool calls, or narration of hidden reasoning.\n\nName the action and object, for example `Fix USERPROFILE config resolution`, not `Investigate`, `Implement`, or `Work on tests`.\n\nKeep secrets, credentials, full transcripts, and sensitive payloads out of activity names, descriptions, and messages.\n"
}