hermes-skills/remote-build-coordination/SKILL.md

name, description, version, author, license, metadata, when_to_use, when_not_to_use

name	description	version	author	license	metadata	when_to_use	when_not_to_use
remote-build-coordination	Coordinate multi-piece remote builds by writing self-contained task files and dispatching peer agents (kimi-c) to execute on remote targets via SSH. Sequential piece-by-piece verification with sudo wall fallback.	1.0.0	Hermes Agent	MIT	hermes tags category related_skills orchestration remote build peer-agent ssh coordination autonomous-ai-agents ask-kimi-c dynamic-workflow	Multi-piece build on a remote target where the coordinator researches/writes specs and a peer agent executes Sequential pieces where each depends on the prior one completing The coordinator must not run build commands directly — only the peer does (except sudo fallback)	Single-step remote command — just SSH directly Parallel independent pieces — use dynamic-workflow fan-out instead The coordinator can run commands directly — skip the peer dispatch layer

Remote Build Coordination

Coordinate multi-piece builds on remote targets by writing self-contained task files and dispatching peer agents to execute them. The coordinator researches, writes specs, and verifies. The peer agent (kimi-c) runs commands on the target via SSH. One piece at a time.

Core Pattern

1. Research First

Before writing any task file, probe the target to understand current state:

• What's installed, what's running, what models/files are in place
• What failed before and why
• What custom node APIs, loader behaviors, or tool-specific quirks apply

Use sshpass for all remote probes. Never assume state — always verify.

2. Write the Build Task File

Create /tmp/kimi-build-N.txt (N = piece number). The file must be fully self-contained — the peer has no memory of your conversation.

Required sections:

• Header: BUILD TASK — Piece N of M: <title>
• Scope guard: "Execute ONLY this piece. Do not proceed to other pieces. Report results and stop."
• Target: SSH connection details (host, user, password)
• Critical Context: What's already done, what's in place, what's running, what failed before, why this approach
• Steps: Numbered, exact commands with expected output. Include verification commands (ls, stat, curl) before the main work.
• Report format: Structured output the peer must return (wall-clock time, VRAM peak, output paths, errors, success/failure)

Rules for task files:

• All remote commands use absolute paths or explicit cd before execution
• Never assume files from prior pieces exist — include verification steps
• Include exact node types, parameter names, and file paths for tool-specific APIs (e.g., ComfyUI custom nodes)
• The task file IS the spec — if the peer deviates, the file was ambiguous

Pre-dispatch validation: If the task file contains tool-specific API details (node names, parameter values, scheduler names, step semantics), validate them with better-search before dispatching. Task files written from memory often contain bugs in parameter semantics (e.g., end_step is exclusive, not inclusive) or enum values (e.g., dpm++_sde fails with Lightning LoRA — use euler). A 3-loop better-search costs ~2 minutes and prevents a failed render that wastes 10+ minutes.

3. Dispatch to Peer Agent

hermes -p kimi-c chat -q "Read /tmp/kimi-build-N.txt and execute the build task described there. <additional constraints>" -Q --max-turns 30 --yolo

For long-running tasks (renders, model downloads, builds >5 min), use background mode:

terminal(background=true, notify_on_complete=true, command="hermes -p kimi-c ...")

Include the web search mandate when the peer needs to verify facts: "Use mcp_searxng_searxng_web_search for every claim and cite the source URL. Do not rely on parametric knowledge or reason about what a command 'would show.' Run the real command, run the real search."

4. Verify Results

When the peer returns:

• Spot-check file existence on the target (ssh ... ls -lh)
• Verify service health (curl the endpoint)
• Check logs for errors
• Only then write the next piece's task file

5. Sudo Wall Handling

If the peer hits a sudo wall, it reports the exact command needed. The coordinator runs it directly — this is the only exception to "coordinator never runs build commands."

Continue Until Done (NON-NEGOTIABLE)

When the operator says "continue until done," "don't stop," "go until complete," or "I am not going to be at the PC" — you do NOT stop between pieces. Chain them: dispatch piece N, wait for completion, immediately write and dispatch piece N+1. Do not pause for user confirmation. Do not report "ready for next direction." Do not kill a running process and wait for the next instruction. The operator is not at the PC and wants the pipeline built end-to-end without intervention.

• If you kill a process (user says "stop"), immediately re-dispatch — do not wait for the next instruction
• If the operator previously said "don't stop" and you stopped anyway, that's a failure. Re-dispatch immediately.
• After each piece completes, immediately write the next task file and dispatch — no gap, no summary, no "ready for..."

After the build works end-to-end:

1. Dispatch ask-dev to validate the build
2. Review findings — only apply accurate fixes, push back on wrong ones
3. Dispatch kimi-c to apply fixes
4. Repeat until ask-dev says CLEAN
5. Dispatch ask-claude for final adversarial review

Pitfalls

• Stale state assumptions. The peer may assume files exist from prior pieces. Always include verification steps.

• Path assumptions. The peer's cwd is not the target's cwd. Use absolute paths.

• Foreground timeout. Renders and large downloads exceed 600s. Use background mode for >5 min tasks.

• Model ignorance. The peer may not know specific tool APIs (custom node names, GGUF loader behavior). Research and include exact details in the task file.

• Task file API bugs. Tool-specific parameter values written from memory are often wrong. end_step is exclusive (not inclusive), scheduler names vary by LoRA type, and node chains have version-specific requirements. Validate with better-search before dispatching if the task file contains API details you're not 100% certain about. A 3-loop better-search costs ~2 minutes and prevents a failed render that wastes 10+ minutes.

• Wrong profile. Always use -p kimi-c explicitly — the sticky default may be a different profile.

• Missing --yolo. Without it, dangerous-command prompts fail closed (60s timeout → deny) in headless mode.

• Pasting file content into the prompt. Point the peer at the file path instead. Saves tokens and avoids transcription errors.

• Don't lose the original goal during infrastructure testing. When the operator's goal is "build X that does Y" and the plan starts with infrastructure pieces (install deps, verify models, smoke-test renders), it's easy to get absorbed in making the infrastructure tests perfect and forget they're scaffolding. After every infrastructure piece completes, re-read the plan's Goal section and ask: "Does this piece move us toward the goal, or am I optimizing scaffolding?" If the piece is infrastructure, state explicitly: "This is scaffolding — the real goal is X. Moving to the next piece that directly serves X." Real failure (July 2026): operator's goal was story-driven narrative video with consistent characters and audio; agent spent 7 build attempts perfecting T2V renders of "a mountain lake at golden hour" — useful for verifying the pipeline works, but not the goal. Operator had to redirect.

• Smoke-test assumptions before expensive commits. Before investing hours in training or large downloads, smoke-test the exact workflow with a minimal configuration. Any plan step that costs >1 hour should be gated on a <10 minute smoke test of the underlying assumption. Real example: the plan assumed A14B GGUF I2V would work, but all prior renders used TI2V-5B. A 5-minute smoke test (Piece 8b) verified the dual-expert GGUF I2V workflow before committing 15-20 hours to LoRA training.

• Iterative plan validation before building. For plans with load-bearing technical claims (model compatibility, VRAM, training times, tool support), validate the plan before dispatching builds. The pattern: (a) write the plan, (b) dispatch Claude for adversarial review with web search mandate, (c) for every disputed claim, dispatch focused deep-research to verify against primary sources, (d) update the plan with verified corrections, (e) re-dispatch Claude, (f) repeat until Claude says CLEAN, (g) only then start building. In the AI video pipeline session: 4 Claude rounds + 2 deep-research correction passes were needed. Claims that were wrong: Fun Control is a lightweight ControlNet (actually a full 64GB model), LoRA training takes 4 hours on RTX 4090 (actually 15-20 hours), Phantom works with Wan 2.2 (Wan 2.1 only), LightX2V is T2V-only (I2V LoRA exists since Aug 2025). Each wrong claim would have wasted hours of build time. The loop cost ~$3 in Claude tokens and prevented days of failed builds. See references/iterative-plan-validation.md.

• Verify Claude's tool-specific API claims before applying. Claude is thorough at finding gaps but can be wrong about tool-specific details (scheduler names, parameter semantics, node chains, version compatibility). After Claude's adversarial review, identify any claims about tool-specific APIs and dispatch better-search to verify against primary sources (official workflows, GitHub issues, community guides). Only apply Claude's API claims that research confirms. Real example (Piece 8c, July 2026): Claude recommended flowmatch_distill scheduler for Lightning LoRA. Better-search confirmed the official LightX2V I2V workflow uses euler, and flowmatch_distill has an open color-shift bug (GitHub Issue #782). Applying Claude's recommendation without verification would have introduced a known bug.

• Peer-written scripts need review before execution. When the peer writes a Python script (render orchestrator, API submission loop, ffmpeg pipeline), the orchestrator MUST read and validate it before running. Common peer script bugs: double-wrapped JSON payloads (template already has "prompt" key), wrong frame extraction (extracting frame 0 instead of last frame), incorrect API endpoint paths, and missing error handling. Pattern: after the peer writes a script, read_file it, spot-check the API calls and ffmpeg commands, fix any bugs, then run it directly via terminal(background=true).

• Verify deliverable dimensions before proceeding. When the task specifies a target (e.g., "60-second video"), the peer may complete all steps but produce the wrong output (e.g., 24.5s instead of 60s). The orchestrator should verify the key dimension (duration, file size, frame count) before accepting the result and moving to the next piece. If the dimension is wrong, go back and fix the root cause (e.g., audio timing) rather than patching downstream.

• Mid-build errors: research before re-dispatching. When a build piece fails or produces wrong output, do NOT immediately re-dispatch with a guess at the fix. Dispatch better-search or deep-research to find the root cause and verified fix first. Then update the build task file with the corrected approach, then re-dispatch. Guessing wastes render time (each failed render = 3-12 minutes). A 3-loop better-search costs ~2 minutes and prevents multiple failed re-dispatches. Real example (Piece 8c, July 2026): render failed with "attention mode not available." Better-search confirmed SageAttention was installed but ComfyUI needed restart. Without the research step, the coordinator might have tried reinstalling SageAttention, changing attention_mode, or switching schedulers — all wrong fixes.

• Peer installs a Python package but doesn't restart the service that needs it. When the build task involves pip install for a running service (ComfyUI, a web server, etc.), the peer may install successfully but the running process still has the old module cache. The render then fails with "module not found" or "attention mode not available" even though the package is installed. Mitigation: when the build task includes a package install for a running service, add an explicit step: "After pip install, restart the service (kill + relaunch) so it picks up the new package. Verify the restart succeeded before submitting work." The coordinator should also be ready to SSH directly and restart the service if the peer's render hangs with VRAM stuck at idle. Real example (Piece 8c, July 2026): SageAttention 1.0.6 installed successfully but ComfyUI wasn't restarted; render failed with "Selected attention mode not available." Coordinator had to SSH, kill the process, and relaunch. See references/sageattention-comfyui-restart.md.

• When the peer hits the turn limit, the coordinator finishes mechanical steps directly. If the peer reports "Reached maximum iterations" but the remaining work is mechanical (calculations, file concatenation, ffmpeg commands, scene plan generation), the coordinator should finish those steps directly rather than re-dispatching. Re-dispatching wastes turns re-establishing context and the peer may hit the limit again. Only re-dispatch when the remaining work requires reasoning or decision-making. Real examples (July 2026): Piece 10 (F5-TTS) — peer generated all 8 audio files but hit the 30-turn limit before calculating scene frame counts and concatenating audio. Coordinator finished both steps directly via SSH. Piece 8c fixes — peer installed SageAttention and submitted the render but hit the 30-turn limit before the render completed. Coordinator monitored the render directly.

• Killing a process and waiting for the next instruction violates "Continue Until Done." When the operator said "don't stop" / "continue until complete" / "I am not going to be at the PC," killing a running build process and waiting for the next instruction is a direct violation. The correct action: immediately re-dispatch the same piece. Do not pause, do not summarize, do not ask "ready for next direction?" — just re-dispatch. The operator is not at the PC and expects the pipeline to keep building. Real failure (July 2026): coordinator killed Piece 11 dispatch (proc_94ff404e0af7) and waited. Operator: "why did you stop?????" Re-dispatched immediately after the correction.

• Test videos need concrete, recognizable scenarios. When the operator asks for a test video, use a specific story with named characters and a clear setting — not abstract dialogue. "A guy walks into a bar and talks to a female bartender about getting fired" is testable. "Two characters having a philosophical conversation on a park bench" is vague and hard to evaluate. The test should make it obvious whether the pipeline is working: can you see the bar? The bartender? The man? Does the dialogue match the scene descriptions? Concrete scenarios expose pipeline gaps that abstract ones hide.

Reference Files

• references/build-task-template.md — Template for self-contained build task files
• references/iterative-plan-validation.md — Claude + deep-research validation loop pattern
• references/sageattention-comfyui-restart.md — SageAttention install + ComfyUI restart recipe
• references/wan22-a14b-gguf-lightning-config.md — Verified working ComfyUI config for Wan 2.2 I2V-A14B GGUF + Lightning LoRA (node chain, sampler settings, VAE, scheduler, performance benchmarks)
• references/ollama-cloud-models-build-agents.md — Top Ollama cloud models for autonomous build agents (July 2026): DeepSeek V4 Pro (best all-around, 1M context), Kimi K2.7-Code (best tool-calling), DeepSeek V4 Flash (best value), GLM-5.2 (best long-horizon stability)
• references/audio-generation-tts-fallback.md — Audio generation for video pipelines: F5-TTS speed issues, edge-tts fallback with rate control, voice selection, silence padding, scene plan calculation, video padding