liveness-discipline

Enforce liveness safeguards for long-running background tasks with bounded timeouts.

6|Updated May 29, 2026
One-click install
npx skills add https://github.com/fusebase-dev/fusebase-flow --skill liveness-discipline
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: liveness-discipline
Source: https://github.com/fusebase-dev/fusebase-flow/tree/main/flow-skills/liveness-discipline
Command: npx skills add https://github.com/fusebase-dev/fusebase-flow --skill liveness-discipline

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Long-running or silent background tasks (such as probes, deployment scripts, fetch loops, browser automation, or dispatched sub-agents) can hang without emitting any completion event, leaving the AI idle indefinitely with no signal that work has stalled. This invisible failure mode leads to wasted time, missed deadlines, and unhandled errors that only surface when a human notices the task is stuck.

Core Features & Use Cases

  • Liveness guarantee enforcement: Requires all long/silent work to be launched with at least one liveness safeguard: in-turn completion with a hard timeout, a bounded wrapper with incremental progress logging, or an explicit BLOCKED-AT return for unbounded waits.
  • Hang diagnosis and recovery: Provides a clear protocol to distinguish slow-but-progressing work from actual hangs by checking activity (log lines, file mtime, byte growth) instead of relying on 0-byte file existence, plus step-by-step recovery steps to stop stalled work, re-run with safeguards, and clean up residue.
  • Zero-trust sub-agent rules: Mandates proactive polling of sub-agent liveness via git progress or process activity (not completion pings) and verification of final output before trusting results, eliminating risks from missing or false sub-agent completion signals.
  • Use case example: If you are dispatching a sub-agent to run a multi-step code review or launching a long deployment pipeline, this skill ensures you will detect stalls immediately and recover instead of waiting indefinitely for a completion event that never comes.

Quick Start

Apply the liveness-discipline skill to attach a bounded timeout and incremental progress logging to any long-running background task before you launch it.

Frequently Asked Questions about liveness-discipline

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent silent hangs in long-running background tasks?

To prevent silent hangs in long-running background tasks, launch work with liveness safeguards like bounded timeouts, incremental progress logging, or explicit BLOCKED-AT returns. This enforces activity-based monitoring to detect stalls instead of waiting indefinitely for missing completion events.

Why does my sub-agent leave the AI idle indefinitely without a completion event?

Your sub-agent leaves the AI idle indefinitely because it lacks zero-trust liveness rules. You must proactively poll sub-agent liveness via git progress or process activity rather than completion pings, and verify final output before trusting results to eliminate risks from missing or false signals.

How to diagnose a hung deployment script versus slow but progressing work?

To diagnose a hung deployment script versus slow progressing work, check activity signals like log lines, file mtime, or byte growth instead of relying on 0-byte file existence. This activity-based hang diagnosis distinguishes actual stalls from ongoing progress before executing safe recovery procedures.

What is the best way to add a timeout wrapper to background fetch loops?

The best way to add a timeout wrapper to background fetch loops is applying a liveness protocol that enforces in-turn completion with a hard timeout or bounded wrappers with incremental progress logging. This satisfies the never-launch-bare protocol requirement for all backgrounded work.

Does this workflow reliability approach work for unbounded waits with no completion event?

Yes, this workflow reliability approach works for unbounded waits by requiring an explicit BLOCKED-AT return. When long-running or silent background tasks emit no completion event, the protocol enforces bounded timeouts or explicit blocked status returns to prevent invisible failure modes.