twl:workflow-observe-loop

Continuously observe a tmux session and aggregate detected issues into a JSON report.

Updated Apr 5, 2026
One-click install
npx skills add https://github.com/shuu5/twill --skill twl-workflow-observe-loop
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: twl:workflow-observe-loop
Source: https://github.com/shuu5/twill/tree/main/plugins/twl/skills/workflow-observe-loop
Command: npx skills add https://github.com/shuu5/twill --skill twl-workflow-observe-loop

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires jq, tmux.

What problem does it solve?

This workflow continuously observes a target tmux session and aggregates detected issues for later review by the co-self-improve controller.

Core Features & Use Cases

  • Continuous observation of a tmux session and aggregation of issues
  • Configurable polling interval, maximum cycles, and stop-on-detect option
  • Produces per-cycle detections and a final aggregated report for decision making

Quick Start

Invoke this workflow from the twl:co-self-improve controller to begin observing the specified window and aggregate detections over time.

Frequently Asked Questions about twl:workflow-observe-loop

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

FAQPage Schema
How do I automate continuous tmux session observation to collect and summarize detected issues?

Continuous tmux session observation is automated by polling a target window at a set interval, collecting per-cycle issue detections, and outputting a final aggregated JSON report for review.

Do I need jq and tmux installed to monitor a tmux session for issues?

Yes, you need both jq and tmux installed to monitor a session, as the workflow relies on bash helper scripts and jq to parse session state and validate inputs for observation.

Can I configure the polling interval and stop monitoring a tmux session automatically when an issue is detected?

Yes, you can configure the polling interval, maximum cycles, and stop-on-detect behavior using OBSERVED_WINDOW, INTERVAL, MAX_CYCLES, and STOP_ON_DETECT parameters to control the monitoring loop.

What is the best way to aggregate detected issues across an extended debugging session in tmux?

The best way to aggregate detected issues is running an automated observation loop that outputs per-cycle detections and a final structured JSON artifact consolidating all findings for downstream consumption.

Why does the tmux observation loop avoid monitoring the initiating window?

The observation loop avoids monitoring the initiating window to prevent recursive feedback, ensuring the polling mechanism only captures activity from the targeted external tmux session window.

Are there limitations when using bash scripts to observe and aggregate tmux session state for issue detection?

A key limitation is that the bash-based observation requires explicit parameter configuration for polling cycles and intervals, and it outputs a structured JSON artifact rather than providing real-time interactive alerts.