Ver código fonte

docs(skills): fleetflow — two-surfaces convention (live grid vs inline snapshot card)

0xDarkMatter 2 semanas atrás
pai
commit
f4461ef3bc
1 arquivos alterados com 9 adições e 2 exclusões
  1. 9 2
      skills/fleetflow/SKILL.md

+ 9 - 2
skills/fleetflow/SKILL.md

@@ -177,12 +177,19 @@ The ones to actually use:
 
 **Live monitor** ([assets/ff-monitor.html](assets/ff-monitor.html)): a
 zero-dependency page reproducing the native /workflows progress surface — run
-header with per-lane pips, an agent grid with state dots, elapsed/tools/
+header with square per-lane pips, a mono/technical agent grid, elapsed/tools/
 commits/tokens, and expandable per-agent detail (activity, last commit, error
 tail, artifact). Wire-up: copy it into the run dir as `index.html`, run
 `ff-status --watch 3 --out <rundir>/status.json`, serve the run dir with any
 static server, open in a browser/preview panel. It polls `status.json` every
-2.5s.
+2.5s. Live claude-brain lanes are introspected via the session transcript in
+their isolated config dir; codex lanes via their `--json` event stream.
+
+**Two surfaces, like the native tool.** The served monitor is the *live*
+grid (the Background-tasks panel analogue). In-chat, the orchestrator emits a
+compact *snapshot* card at phase boundaries (spawn, phase change, all-done) —
+chat-widget sandboxes cannot poll localhost, so the inline card is a
+moment-in-time render by design, re-emitted rather than self-updating.
 
 All follow the Skill Resource Protocol: stdout is data, chatter on stderr,
 semantic exit codes (`0` ok, `2` usage, `3` cached/missing, `7` unreachable,