agentleFS
Sign inStart free
AnastasiyaWAnastasiyaW/claude-code-config/skills/development/control-cli/SKILL.md

control-cli

Skill213 starsChanged 3 days agoMITView on GitHub

Drive and inspect an interactive CLI or TUI with a repeatable local harness, deterministic input, transcripts, and optional profiling. Use for CLI UX checks, prompt flows, startup regressions, hangs, interrupts, resize behavior, or memory growth. Do not use for a non-interactive command that a normal test can cover.

We split this skill into the rules it gives an agent

8 rules. 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 8

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Prefer a repository-native demo or test harness.

    line 9
  2. Distinctive:

    Stop the process and remove temporary sessions, ports, and profiles.

    line 23
  3. Distinctive:

    Prefer stable text markers and accessibility-aware terminal probes over sleeps.

    line 38
  4. Distinctive:

    If a sleep is unavoidable, state why and keep it bounded.

    line 39
  5. Distinctive:

    Never send credentials, destructive commands, or production paths into the controlled session.

    line 43
  6. Distinctive:

    Do not rely on stale screen state after navigation, resize, or a prompt change.

    line 45
  7. Distinctive:

    Do not hard-code paths, ports, or commands from another repository.

    line 46
  8. Distinctive:

    Keep transcripts and profiles private when they contain prompts, source, or user data.

    line 47

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Control CLI

Exercise an interactive terminal program through a small, repeatable harness. Prefer a repository-native demo or test harness; only assemble a temporary PTY or terminal session when the project has no suitable one.

Harness Loop

  1. Identify the command, smallest fixture, expected ready marker, and cleanup condition.
  2. Discover existing package scripts, PTY helpers, expect scripts, demo recorders, or TUI tests.
  3. Launch in an isolated environment with deterministic variables and local disposable data.
  4. Capture the initial screen or transcript.
  5. Send one action at a time and wait for a concrete prompt or screen marker.
  6. Capture the resulting transcript and any requested profile artifact.
  7. Stop the process and remove temporary sessions, ports, and profiles.

On Windows, prefer the project's own test runner or a checked-in Python/Node probe. Use ConPTY or an already-installed PTY helper when available; do not add a dependency just to run a one-off probe. On other systems, tmux, pty, or a repository-supported terminal harness may be appropriate.

Evidence

For a bug fix or regression, run the same deterministic interaction against the baseline and treatment and pass the captures to verify-this. For a hang, keep the last screen, process exit state, timeout, and a stack/CPU sample when available. For memory growth, use equal repetitions and record before/after snapshots or a bounded allocation metric.

Prefer stable text markers and accessibility-aware terminal probes over sleeps. If a sleep is unavoidable, state why and keep it bounded.

Safety

  • Never send credentials, destructive commands, or production paths into the controlled session.
  • Do not rely on stale screen state after navigation, resize, or a prompt change.
  • Do not hard-code paths, ports, or commands from another repository.
  • Keep transcripts and profiles private when they contain prompts, source, or user data.

Gotchas

  • A process that exits successfully before receiving input is not proof that the interactive flow works; assert the ready marker and the expected state change.
  • Fixed sleeps hide race conditions and make a green run non-repeatable.
  • A terminal transcript can miss rendering defects; use a real UI surface for graphical claims.
  • Cleanup must be verified, especially after a timeout or forced interrupt.

Troubleshooting

SymptomLikely causeAction
Harness hangsWrong ready marker or child process owns the terminalCapture the screen, inspect the process tree, then terminate cleanly
Input is ignoredProgram is not in the expected prompt stateWait for a fresh marker and send one action only
Works manually, fails in harnessHidden environment, terminal size, or timing dependencyRecord env/size and replace sleeps with state-based waits
Transcript is emptyOutput is on another stream or the PTY was detachedCapture stdout and stderr through the repo-native harness and verify file size

Source

Adapted from Cursor Team Kit's MIT-licensed control-cli workflow: https://github.com/cursor/plugins/tree/main/cursor-team-kit/skills/control-cli

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free