om-integration-tests

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

1|Updated Apr 23, 2026
One-click install
npx skills add https://github.com/tkogut/agents-os-core --skill om-integration-tests-tkogut
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: om-integration-tests
Source: https://github.com/tkogut/agents-os-core/tree/main/global_skills/om-integration-tests
Command: npx skills add https://github.com/tkogut/agents-os-core --skill om-integration-tests-tkogut

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing integration and E2E tests usually fails because tests are authored against guessed selectors, invented URLs, or assumed environments. This Skill eliminates that guesswork by requiring the agent to explore the running application first, reuse a shared test environment, and follow the repository's existing test conventions. ## Core Features & Use Cases - Live-app exploration before authoring: Drives the configured browser provider (open, snapshot, interact, assert) to capture real selectors, flows, and validation messages before writing any test. - Shared test environment reuse: Attaches to the om-prepare-test-env descriptor at .ai/qa/test-env.json after validating PID, readiness probe, and freshness, avoiding duplicate environment bootstraps. - Repository-native conventions: Discovers existing runners (Playwright, Cypress, WebdriverIO), mirrors test layout and naming, and keeps timeouts/retries in the shared runner config. - Artifact-based failure analysis: Classifies every failure as product regression, test issue, or environment issue, with a mandatory per-test evidence table and ownership assignment. - Use Case: After implementing a company-creation flow, ask the agent to write integration tests; it attaches to the running test environment, walks the flow in the browser, authors a Playwright test using observed roles and labels, runs it, and reports results with evidence. ## Quick Start Ask the agent to write and run integration tests for the login flow using the om-integration-tests skill against the shared test environment.

Frequently Asked Questions about om-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 the browser provider's snapshot and interact operations to capture actual roles, labels, and text. Then author tests using only observed elements, such as Playwright's getByRole, getByLabel, and getByText locators.

How to run existing Playwright or Cypress test suites with this skill?▼

Use running-only mode: attach to the shared test environment descriptor, then execute the repository's own test command from package.json, Makefile, or CI. On failure, the skill applies mandatory per-test artifact analysis before reporting.

Does it work with both Playwright and agent-browser providers?▼

Yes. It reads the provider descriptor at .ai/browsers/<provider>.md and uses its named operations. For agent-browser it generates paired POSIX sh and PowerShell launchers; for Playwright it uses a minimal shared TypeScript config.

Why do my integration tests fail against a stale test environment?▼

The shared environment descriptor must be validated before reuse: owning PID alive, readiness probe answering, and no tracked source modified since startedAt. Stale descriptors are discarded and reprovisioned via om-prepare-test-env.

Can tests use seeded demo data or hardcoded record IDs?▼

No. Tests must create their own fixtures at runtime, preferably via API setup, select rows via stable text or role locators, and clean up everything in teardown. Hardcoded IDs and seeded data dependencies are explicitly prohibited.

When should I not use this skill for testing?▼

Avoid it when no runnable application can be discovered from the repository and the user cannot provide a start command, since the skill never invents environments or URLs. Unit-level logic tests without a running app are also out of scope.