Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
cursor avatar

Control Cli

  • 1.3k installs
  • 2.5k repo stars
  • Updated August 5, 2026
  • cursor/plugins

control-cli is a Cursor plugin skill that builds local harnesses to drive, inspect, and profile interactive CLIs and TUIs for developers who need deterministic terminal UX testing without external services.

About

control-cli is a Cursor plugin skill for exercising interactive command-line and terminal UIs through a repeatable local harness. It reuses an existing repo test or demo harness when available, otherwise assembles one from standard local tools to reproduce bugs, verify keyboard flows, capture before-and-after transcripts, and check startup regressions, memory leaks, hangs, and resize behavior. Developers reach for control-cli when a CLI or TUI needs systematic validation instead of manual terminal poking, especially for prompt sequences, interrupts, and layout checks before release.

  • Wraps shell commands with guardrails
  • Handles cwd, env, and argument patterns
  • Chains multi-step CLI pipelines
  • Surfaces stdout/stderr for debugging
  • Keeps human out of repetitive terminal ops

Control Cli by the numbers

  • 1,267 all-time installs (skills.sh)
  • +203 installs in the week ending Aug 5, 2026 (Skillselion tracking)
  • Ranked #98 of 550 CLI & Terminal skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/cursor/plugins --skill control-cli

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1.3k
repo stars2.5k
Last updatedAugust 5, 2026
Repositorycursor/plugins

How do you test an interactive CLI deterministically?

Operate external CLIs—package managers, cloud tools, test runners—from the agent with correct flags, cwd, and safety checks.

Who is it for?

CLI maintainers who need reproducible terminal sessions to debug prompts, hangs, layout issues, or startup regressions locally.

Skip if: Developers running one-off package manager installs without a custom interactive TUI to validate, because control-cli targets repeatable CLI and TUI harness workflows.

When should I use this skill?

The user needs to reproduce a CLI or TUI bug, verify keyboard flows, profile hangs, or capture terminal transcripts with a local harness.

What you get

Local CLI harness scripts, deterministic input sequences, and before-and-after terminal transcripts for regression comparison.

  • Local CLI harness
  • Deterministic input scripts
  • Terminal transcripts

Files

SKILL.mdMarkdownGitHub ↗

Control CLI

Use a repeatable local harness to exercise an interactive CLI instead of poking at it manually. First reuse the repo's own test/demo harness if it exists; otherwise assemble a temporary harness from standard local tools.

What It Is Used For

  • Reproducing CLI/TUI bugs with deterministic input.
  • Verifying keyboard flows, prompts, interrupts, resize behavior, and terminal layout.
  • Capturing before/after transcripts for bug fixes.
  • Profiling startup time, slow operations, hangs, or memory growth.
  • Recording a short terminal demo when output is easier to show than explain.

Harness Loop

1. Identify the command under test and the smallest reproducible workspace. 2. Discover existing local harnesses: package scripts, e2e tests, demo recorders, expect scripts, or PTY helpers. 3. If no harness exists, launch the CLI in an isolated terminal session with deterministic env vars. 4. Capture the current screen before interacting. 5. Send one action at a time: text, Enter, arrows, Escape, Ctrl-C, resize. 6. Wait for a concrete screen pattern or prompt before the next action. 7. Save the transcript and any profile artifacts. 8. Kill the session cleanly.

Harness Options

  • Repo-native harness: prefer checked-in scripts because they know the app's startup, env, and prompts.
  • tmux: managed sessions, capture-pane, send-keys, attach/detach.
  • PTY probe: use a short Python, Node, or Expect script when tmux is unavailable.
  • Runtime inspector: use Node or Bun inspector for CPU profiles, heap snapshots, and live evaluation.
  • Terminal recorder: use repo-local demo tools or asciinema-compatible tools when the user asks for a demo.

Minimal tmux Harness

SESSION="cli-harness-$(date +%s)"
tmux new-session -d -s "$SESSION" -- <command-under-test>
tmux capture-pane -pt "$SESSION"
tmux send-keys -t "$SESSION" "help" Enter
tmux capture-pane -pt "$SESSION"
tmux kill-session -t "$SESSION"

For Node CLIs:

NODE_OPTIONS="--inspect=127.0.0.1:0" tmux new-session -d -s "$SESSION" -- <node-cli-command>

Read the terminal output to find the inspector URL, then use Chrome DevTools-compatible tooling if profiling is needed.

Minimal PTY Harness

Use a PTY script when you need deterministic waits in a repo that does not have tmux or a demo harness. Keep it temporary unless the user asks to add a reusable test.

import os
import pty
import select
import subprocess
import time

master_fd, slave_fd = pty.openpty()
proc = subprocess.Popen(
    ["<command>", "<arg>"],
    stdin=slave_fd,
    stdout=slave_fd,
    stderr=slave_fd,
    close_fds=True,
)
os.close(slave_fd)

deadline = time.time() + 30
buffer = b""
while time.time() < deadline:
    ready, _, _ = select.select([master_fd], [], [], 0.25)
    if not ready:
        continue
    chunk = os.read(master_fd, 4096)
    buffer += chunk
    if b"<ready text>" in buffer:
        os.write(master_fd, b"help\n")
        break

print(buffer.decode(errors="replace"))
proc.terminate()
os.close(master_fd)

If the CLI needs richer terminal control, use pty.fork() or an existing PTY library.

Profiling Recipes

  • Startup regression: capture baseline and treatment startup timings under the same machine, env, and command.
  • Slow operation: start a CPU profile, perform the operation, stop the profile, and compare top self-time functions.
  • Memory leak: force GC if available, take a heap snapshot, perform the operation repeatedly, force GC again, and take another snapshot.
  • Hang: capture the screen, active handles/resources, and a stack/CPU sample before interrupting.

Guardrails

  • Prefer deterministic waits over sleeps. If you must sleep, explain why.
  • Do not send credentials or destructive commands into a controlled session.
  • Keep the harness in /tmp unless the repo already has a testing/demo harness.
  • Do not hard-code paths from another repository. Adapt commands to the current repo's scripts and runtime.
  • Clean up tmux sessions, temp dirs, inspector processes, and demo artifacts unless the user asks to keep them.

Related skills

How it compares

Pick control-cli over manual terminal testing when interactive CLI sessions need scripted reproduction and saved transcripts.

FAQ

Does control-cli require external services?

No. control-cli builds or reuses a local harness to drive interactive CLIs and TUIs without external services. It is meant for deterministic terminal UX checks on a developer machine.

What problems does control-cli help debug?

control-cli helps debug CLI and TUI startup regressions, memory leaks, hangs, prompt flows, interrupts, resize behavior, and layout issues by scripting input and saving terminal transcripts.

CLI & Terminalintegrationsdevops

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.