Run any Skill in Manus with one click

tap-live-channel

Stars6

Forks0

UpdatedJuly 23, 2026 at 23:12

Attach a read-only tap to one named channel of a running StreamLib node and collect a bounded sample of raw bags to confirm data is actually flowing. Use to answer "are frames/samples really moving through this link?" — after inspecting the graph, to verify a `submit`/`connect` produced live output, or to spot-check behavior before and after a `hot-swap-live-processor`. Wraps `streamlib tap`.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

tatolab

tatolab/streamlib

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	tap-live-channel
description	Attach a read-only tap to one named channel of a running StreamLib node and collect a bounded sample of raw bags to confirm data is actually flowing. Use to answer "are frames/samples really moving through this link?" — after inspecting the graph, to verify a `submit`/`connect` produced live output, or to spot-check behavior before and after a `hot-swap-live-processor`. Wraps `streamlib tap`.

tap-live-channel

Proof-of-life for a link. A channel is named {source_processor}/{source_output_port} — the source processor plus the output port it publishes on. Tapping collects a bounded sample of raw bags off that channel and prints a hex preview plus byte length per bag; it does NOT decode pixels or audio samples, so treat it as "bytes are flowing, and roughly this many per bag," not as a rendered frame.

Steps

1. Get the channel name from the live graph

Run inspect-live-graph and read the source processor and its output port, then join them:

{source_processor}/{source_output_port}   e.g.  camera/frames

2. Tap a bounded sample

The channel is a positional argument; --count bounds how many bags to collect before returning:

streamlib tap --node <runtime_id> camera/frames --count 10
# or
streamlib tap --url <control_url> camera/frames --count 10
# or, when exactly one node is live:
streamlib tap camera/frames --count 10

Each collected bag prints as a hex preview and a byte length. Omitting --count uses the tool's own default sample bound.

3. Interpret the sample

Bags arrive, non-zero byte lengths — data is flowing on that link; the source processor is producing.
Byte lengths change frame-to-frame — live, varying content (e.g. a moving camera image) rather than a stuck buffer.
Zero bags / the call blocks then returns empty — nothing is publishing on that channel; re-check the channel name against the graph, and confirm the source processor is running (states/metrics in inspect-live-graph).

Notes

tap has NO --output flag. To persist the sample as evidence, redirect stdout (streamlib tap ... > frames.json) — see capture-node-evidence.
Read-only: a tap never mutates the graph and never disturbs the real subscribers on the channel.
The channel positional and --count can appear in either order; the node is selected by --url / --node exactly like the other verbs.

More from this repository

same repository

milestone-loop

tatolab/streamlib

Run one reconciler pass of the standing milestone-loop — the turn procedure each `/work-on-milestone` firing invokes. Use when a loop firing (or the owner directly) needs to move the focused milestone one bounded step toward "merged, or waiting on the owner or on blockers." Checks the kill switch, probes rig capability, launches the milestone-loop workflow, and surfaces anything needing the owner. To START the loop on a milestone rather than run a single pass, use work-on-milestone.

2026-07-256

work-on-milestone

tatolab/streamlib

Drive a whole milestone to done with the standing loop — resolve the milestone, set the goal, and register the recurring reconciler that runs passes until every issue is merged or parked. Use when the owner says "work on <milestone>", "start the loop on <milestone>", "close out <milestone>", or wants the loop running without hand-typing a /loop invocation. Also the place to stop or re-target a running milestone driver.

2026-07-256

work-on-ticket

tatolab/streamlib

Take one ticket end-to-end in the current session with the owner present — the interactive counterpart to the standing loop. Use when they say "work on issue N", "let's do this ticket", "pick up X and I'll answer questions as you go", or want to drive a single issue to a PR now. Same workflow, same composed stages, same verifier as the loop — but questions come inline instead of parking.

2026-07-256

loop-status

tatolab/streamlib

Render the milestone-loop's current picture into one status board — what it's acting on, what's waiting on the owner (oldest first), what it's watching, recent outcomes, and spend. Use when asked "what's the loop doing", "loop status", "what's waiting on me", or before deciding whether to nudge or pause the loop. Read-only — it reports, it never acts.

2026-07-256

draft-design

tatolab/streamlib

Architecture-first entry point — recon the current code with the relevant domain experts, then produce a design brief for the owner (mermaid diagram, trade-offs, decisions taken, and an explicit decisions-for-owner list) posted to the issue. Use before building anything engine-zone, when a feature needs a shape decided, or when the owner asks to "design X first" or "draft the approach for this issue". Nothing builds until they approve in a comment.

2026-07-246

author-and-submit-processor

tatolab/streamlib

Write a brand-new processor from source and submit it into a running StreamLib node as a fresh instance, optionally wiring its ports to existing processors in one transactional step, then confirm it landed and is producing. Use when adding a new stage to a live pipeline during development — a new filter, sink, or generator — without restarting the app. Wraps `streamlib submit` then `graph` + `tap` to confirm.

2026-07-236

name	tap-live-channel
description	Attach a read-only tap to one named channel of a running StreamLib node and collect a bounded sample of raw bags to confirm data is actually flowing. Use to answer "are frames/samples really moving through this link?" — after inspecting the graph, to verify a `submit`/`connect` produced live output, or to spot-check behavior before and after a `hot-swap-live-processor`. Wraps `streamlib tap`.

tap-live-channel

Steps

1. Get the channel name from the live graph

Run inspect-live-graph and read the source processor and its output port, then join them:

{source_processor}/{source_output_port}   e.g.  camera/frames

2. Tap a bounded sample

The channel is a positional argument; --count bounds how many bags to collect before returning:

streamlib tap --node <runtime_id> camera/frames --count 10
# or
streamlib tap --url <control_url> camera/frames --count 10
# or, when exactly one node is live:
streamlib tap camera/frames --count 10

Each collected bag prints as a hex preview and a byte length. Omitting --count uses the tool's own default sample bound.

3. Interpret the sample

Bags arrive, non-zero byte lengths — data is flowing on that link; the source processor is producing.
Byte lengths change frame-to-frame — live, varying content (e.g. a moving camera image) rather than a stuck buffer.
Zero bags / the call blocks then returns empty — nothing is publishing on that channel; re-check the channel name against the graph, and confirm the source processor is running (states/metrics in inspect-live-graph).

Notes

tap has NO --output flag. To persist the sample as evidence, redirect stdout (streamlib tap ... > frames.json) — see capture-node-evidence.
Read-only: a tap never mutates the graph and never disturbs the real subscribers on the channel.
The channel positional and --count can appear in either order; the node is selected by --url / --node exactly like the other verbs.