ot-integration-tests

Generate and run integration tests by exploring the live application through a configured browser provider.

Updated Sep 10, 2026
One-click install
npx skills add https://github.com/triage-software/skills --skill ot-integration-tests-triage-software
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ot-integration-tests
Source: https://github.com/triage-software/skills/tree/main/skills/ot-integration-tests
Command: npx skills add https://github.com/triage-software/skills --skill ot-integration-tests-triage-software

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing integration and E2E tests usually means guessing selectors, hardcoding URLs, and booting a fresh environment for every run. This Skill removes that guesswork by exploring the running application first, reusing a shared test environment, and producing executable tests that match the repository's existing runner conventions. ## Core Features & Use Cases - Live-app exploration before authoring: Drives the configured browser provider (open, snapshot, interact, assert, screenshot, close) to observe real element roles, labels, and flows, so tests use only verified selectors. - Shared test environment reuse: Attaches to the validated test-env.json descriptor written by ot-prepare-test-env instead of booting a second instance, with credential references kept out of model context. - Repo-native runner preservation: Mirrors existing Playwright, Cypress, or custom test layouts and naming conventions, and generates paired POSIX/PowerShell launchers for agent-browser scenarios. - Artifact-based failure analysis: Classifies every failure as product regression, test issue, or environment problem, with a mandatory per-test evidence and ownership table. - Use Case: After implementing a company-creation flow, ask the agent to test it — it attaches to the running environment, walks the flow in a real browser, writes a Playwright test using observed getByRole locators, verifies it passes, and reports coverage. ## Quick Start Ask the agent to create and run an integration test for a specific feature, for example: "Write an integration test for the login rate-limiting flow and run the existing suite."

Frequently Asked Questions about ot-integration-tests

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

FAQPage Schema
How do I write integration tests without guessing CSS selectors?▼

Explore the running application first using browser provider snapshot operations to capture actual element roles, labels, and text. Then author tests using only observed locators such as getByRole, getByLabel, and getByText in Playwright, never guessed CSS paths.

How to run Playwright tests against a shared test environment?▼

Check for the test-env.json descriptor written by the environment preparation skill, validate it (owning PID alive, readiness probe answers, fresh within TTL), then attach by reading its baseUrl, credentials references, and testRunner settings instead of booting a second instance.

Does this work with Cypress or only Playwright?▼

It works with whatever runner the repository already uses — Playwright, Cypress, WebdriverIO, or agent-browser scenario scripts. The discovery step finds existing runner configs and CI commands and mirrors their conventions rather than imposing a new framework.

Why do integration tests fail intermittently in CI?▼

Common causes are stale locators, brittle assertions, seeded-data dependencies, and shared-state collisions. The failure-analysis workflow inspects runner artifacts like screenshots, traces, and error contexts to classify each failure as a product regression, test issue, or environment problem.

Can tests run on Windows as well as macOS and Linux?▼

Yes. For agent-browser scenarios, paired native launchers are generated: a POSIX sh script and a native PowerShell script performing the same semantic actions. The PowerShell launcher never assumes sh, WSL, or Git Bash exists.

When should I not hardcode URLs or credentials in test files?▼

Never hardcode base URLs, entity IDs, or password values. Read the base URL from the runner config or environment descriptor, create fixtures at runtime, and reference credentials through environment variables loaded from the gitignored credentials file.