ot-prepare-test-env

Generates and maintains reusable cross-platform scripts that boot local test environments for QA.

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

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Setting up a local environment for tests and QA is slow, inconsistent across machines, and repeated every time an agent or developer needs a running app. This Skill compiles one-time discovery of how a project runs into committed launch scripts, so every subsequent run boots the same environment in seconds on macOS, Linux, WSL2, or Windows. ## Core Features & Use Cases - Entrypoint script generation: Discovers the repo's own run recipe (services, build chain, ports) and generates test-env-up.sh/test-env-down.sh (or PowerShell .ps1 flavors) with locking, reuse checks, build caching, and health waits baked in. - Browser provider provisioning: Ensures the configured browser provider (e.g. Playwright or agent-browser) is installed and verified through its .ai/browsers/<provider>.md descriptor during generation. - Shared environment descriptor: Writes .ai/qa/test-env.json with base URL, services, credential references, and platform so QA and integration-test skills attach to the same running instance. - Self-improving repair loop: Any failure or degradation is patched back into the scripts, proven by re-running them, and logged in a # history: header. - Use Case: A coding agent needs a running app to execute UI tests. On first run the Skill discovers the stack, generates and verifies the up/down scripts cold and warm; every later run just executes the script and reports the base URL. ## Quick Start Ask the agent to prepare the test environment for this repository so QA and integration-test skills have a running app to attach to.

Frequently Asked Questions about ot-prepare-test-env

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

FAQPage Schema
How do I set up a reusable local test environment for automated QA?▼

Run the skill once per repository: it discovers how your project runs from package scripts, compose files, and CI, then generates committed up/down scripts. Every later run just executes the script, which reuses a healthy environment or rebuilds only when sources changed.

How to speed up repeated test environment bootstraps?▼

The generated entrypoint embeds a build cache keyed on a fingerprint of source files, lockfiles, and build env vars. When the fingerprint matches and artifacts exist, install, codegen, and build steps are skipped, so warm boots complete in seconds.

Does it work on Windows, WSL2, and macOS?▼

Yes. It generates a POSIX sh entrypoint on macOS, Linux, WSL2, and Git Bash, and a PowerShell .ps1 entrypoint implementing the same contract on native Windows. Both flavors share the descriptor and build-cache state.

Can I use Playwright or another browser provider with the test environment?▼

Yes. During generation the skill ensures the configured browser provider through its .ai/browsers/<provider>.md descriptor, running its install and doctor operations. The --browser-provider flag overrides the configured provider, and --browser off skips provisioning.

What happens when the generated environment script fails?▼

The skill enters repair mode: it diagnoses the script output, patches the failing step, and proves the fix by re-running the script itself rather than hand-booting. Every repair is logged in the script's # history: header and the repo-local skill notes.

Will it tear down my own running dev server?▼

No. Teardown only stops what the repo's own up script started, scoped by the throwaway container names it created. A developer's long-running services are never touched, and the down script is safe to run twice.