om-prepare-test-env

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

2.6k|159|Updated Mar 8, 2021
One-click install
npx skills add https://github.com/go-musicfox/go-musicfox --skill om-prepare-test-env-go-musicfox
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: om-prepare-test-env
Source: https://github.com/go-musicfox/go-musicfox/tree/main/.agents/skills/om-prepare-test-env
Command: npx skills add https://github.com/go-musicfox/go-musicfox --skill om-prepare-test-env-go-musicfox

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Setting up a local environment for QA and integration testing is slow, error-prone, and repeated every time a fresh checkout or worktree needs a running app. This Skill discovers how a repository runs once, compiles that knowledge into committed entrypoint scripts, and makes every subsequent environment boot a single fast command. ## Core Features & Use Cases - One-time discovery, permanent scripts: Detects the project's stack, services, build chain, and launch command from the repo itself, then generates POSIX sh or PowerShell up/down scripts with locking, reuse checks, and build caching baked in. - Disposable, isolated environments: Provisions backing services as throwaway Docker containers bound to 127.0.0.1 on free ports, with fresh database migration and seeding per environment. - Shared test-env descriptor: Writes a test-env.json descriptor (base URL, services, credential references, browser provider state) that QA and integration-test skills attach to, so every consumer drives the same running instance. - Self-improving repair loop: Any failure or drift during a run is patched back into the scripts, proven by re-running them, and logged in a dated history header. - Use Case: A QA agent needs a running app to test a pull request. On first run the Skill discovers the stack, generates test-env-up.sh, verifies it cold and warm, and provisions the browser provider; every later run reuses the healthy environment in seconds. ## Quick Start Ask the agent to prepare a reusable test environment for this repository so QA and integration tests can attach to a running app.

Frequently Asked Questions about om-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 QA automation?

Run the skill once per repository: it discovers how the project runs, generates test-env-up and test-env-down scripts, and verifies them with a cold and warm boot. Every later run just executes the saved script and reuses the healthy environment in seconds.

How does the skill speed up repeated environment boots?

The generated script embeds a build cache keyed on source fingerprints, environment variables, and artifact presence, plus a reuse check with liveness and readiness probes. Warm runs skip rebuilds and re-provisioning entirely, returning in seconds.

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

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

Can it provision databases and other backing services for tests?

Yes. In ephemeral mode it starts each discovered service as a disposable Docker container bound to 127.0.0.1 on a free port, waits for readiness, then runs the repo's own migrate and seed commands. Services use throwaway names and volumes.

What happens when the generated environment script fails?

The skill enters repair mode: it diagnoses the failure, patches the script rather than hand-booting around it, proves the fix by re-running the script, and logs the change in a dated history header. After two failed repair attempts it records the blocker and falls back to an agent-driven flow.

Are credentials stored in the test environment descriptor?

No real secrets are stored. The descriptor carries credential references only; password values live in a gitignored env file the agent never reads, and only disposable demo values are permitted.