ticket-cli-ux-tests

Add focused UX tests for loom ticket CLI stdout, stderr, and exit codes.

21|1|Updated Jan 31, 2026
One-click install
npx skills add https://github.com/z3z1ma/agent-loom --skill ticket-cli-ux-tests
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ticket-cli-ux-tests
Source: https://github.com/z3z1ma/agent-loom/tree/main/.opencode/skills/ticket-cli-ux-tests
Command: npx skills add https://github.com/z3z1ma/agent-loom --skill ticket-cli-ux-tests

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill provides a structured approach to add stable, low-noise UX tests for loom ticket CLI behavior, ensuring consistent stdout/stderr and exit-code contracts.

Core Features & Use Cases

  • Define and lock the user-visible CLI contract changes by adding focused UX tests.
  • Use tests/test_ticket_ux.py as the canonical test file and adapt test harness to verify stdout, stderr and exit codes.
  • Enforce minimal, stable assertions and guidance for running gates (ruff, pyright, pytest).

Quick Start

Create or update tests/test_ticket_ux.py to lock the CLI contract and run the project test gates.

Frequently Asked Questions about ticket-cli-ux-tests

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

FAQPage Schema
How do I write deterministic tests for CLI output changes?

The canonical test file for locking loom ticket CLI contracts is tests/test_ticket_ux.py. You update this file to add focused tests whenever CLI output changes, adapting the test harness to verify stdout, stderr, and exit codes.

What test gates do I need to run for CLI UX testing?

To validate CLI UX tests, you must run ruff for linting, pyright for type checking, and pytest for test execution. These gates ensure the user-visible CLI behavior remains stable and the test code adheres to project quality standards.

Why does my CLI test fail when checking stdout and stderr?

CLI tests fail when stdout, stderr, or exit codes deviate from the locked contract. You must update the focused UX tests in the canonical test file to match the new user-visible behavior and ensure assertions remain minimal and stable.

Can I use this approach to test CLI contracts for any command line tool?

This approach is tailored for the loom ticket CLI, requiring a tests directory with a consistent test harness. It focuses on locking user-visible behavior by validating stdout, stderr, and exit codes specifically for the loom ticket command line interface.

What is the best way to lock CLI output contracts without flaky tests?

The best way to lock CLI output contracts is by enforcing minimal, stable assertions in focused UX tests. Validating stdout, stderr, and exit codes deterministically within a consistent test harness prevents flakiness and reduces test noise.