executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
servingGuide Otter controller, worker, Gradio, local CLI, endpoint, import, port, and load-bit serving workflows.
Independent GitHub snapshot · Automated classification · Original documentation governs
Use this sub-skill when the task is to expose Otter or Flamingo generation through a local controller/worker service, Gradio image/video UI, direct text-generation CLI, or HTTP streaming endpoint.
--checkpoint_path, --model_name, --num_gpus, --load_bit, controller/worker URLs, and concurrency.prompt, optional base64 image/video frames, and generation_kwargs.--model-name, --device, --num-gpus, and conversation templates.--repo-root only when the user is working in an Otter checkout and wants checkout-specific diagnostics.pipeline.constants, Gradio versions, worker registration, GPU memory, image payloads, or stalled streaming, use troubleshooting.| Need | Start with |
|---|---|
| Three-process controller + worker + Gradio plan | serving topology |
| Generate commands with custom ports/model path | build_serving_commands.py |
| Check imports without starting services | check_serving_imports.py |
| Understand controller/worker endpoints | API reference |
Diagnose missing pipeline.constants or flamingo import | troubleshooting |
Choose fp16, bf16, int8, int4, or fp32 | serving topology |
Serving launches long-running processes, opens network ports, can download or load large checkpoints, and may allocate multiple GPUs. Do not start controller, worker, Gradio, or Flask services unless the user supplies the model/checkpoint, host/port policy, GPU budget, and explicit permission to launch them.