Compozy QA Bootstrap
SkillWeb & browsingThis skill sets up an isolated local QA lab for Compozy and produces a manifest that later QA checks can build on. It handles the setup local QA depends on, including the daemon, workspace, providers, and playbooks. It is meant for local QA setup, not unit tests, planning-only work, or browser-only checks.
Available today. Use it from your connected AI after setup.
No other account needed.
Add the skill, then ask your AI to bootstrap a QA lab whenever you have local QA work that needs daemon, workspace, provider, or playbook setup. The manifest it produces is ready for the QA checks that follow.
Then ask your AI: use the Compozy QA Bootstrap skill
What your AI can do with it
- Set up an isolated local QA lab for Compozy
- Prepare the daemon, workspace, providers, and playbooks local QA needs
- Generate a manifest that downstream QA checks can use
- Recognize when a task is out of scope, such as unit tests or browser-only checks
What this skill tells your AI
The instructions your AI receives, as published by compozy/compozy in .agents/skills/eng/eng-qa-bootstrap/SKILL.md and read by ahel’s review.
Provision infrastructure and scratch evidence for one QA pass. Bootstrap does not prove runtime behavior; downstream QA owns journeys and verdicts.
Required Inputs
- scenario-slug (optional): short lab context; defaults to
release-candidate. - --playbook : required when called by
eng-real-scenario-qa; omitted for genericqa-executioninfrastructure. - --profile targeted --required-surface : use for a bounded non-agent journey; repeat the surface flag for every CLI/API/Web/runtime/provider plane in scope.
Procedure
Step 1: Create or Resume One Lab
- Resolve the scenario slug and, for
eng-real-scenario-qa, validate the playbook under.agents/skills/eng/eng-real-scenario-qa/references/playbooks/. - For a new pass, run the bootstrap helper (bootstrap, mutating):
python3 .agents/skills/eng/eng-qa-bootstrap/scripts/bootstrap-qa-env.py --scenario "<scenario-slug>" --repo-root . [--playbook "<ref>" | --profile targeted --required-surface "<surface>"] - Reuse only when continuing the same active QA session or loop with its exact manifest:
python3 .agents/skills/eng/eng-qa-bootstrap/scripts/bootstrap-qa-env.py --scenario "<scenario-slug>" --repo-root . [--playbook "<ref>"] --reuse-manifest "<manifest-path>" - Record the emitted
BOOTSTRAP_MANIFEST; do not reconstruct environment values manually.
Done when: one fresh or same-session lab has one readable manifest and no unrelated lab was reused.
Step 2: Verify the Handoff Contract
- Read
.agents/skills/eng/eng-qa-bootstrap/references/bootstrap-contract.mdin full. - Validate every required manifest field, env value, scratch-evidence file, provider-home policy, browser policy, audit command, and teardown command against that contract.
- When a playbook was supplied, also validate the materialized playbook, agents, open-task tree, knowledge files, required deliverables/collaboration, and populated charter.
- Treat scaffolding as empty evidence until downstream QA records real actions and the strict auditor passes.
Done when: manifest, env, paths, scenario contract, charter, playbook artifacts, and filesystem all describe the same isolated lab with no placeholders in a playbook run.
Step 3: Hand Off to Downstream QA
- Pass
qa-docs-path=docs/qatoqa-reportandqa-execution; keepQA_OUTPUT_PATHas lab-side scratch evidence only. - Launch providers, Web, browser, and config operations exactly from the manifest contract. Preserve operator home for
native_cli + home_policy=operator; use isolated provider homes for bound-secret or brokered lanes. - Export the manifest-derived
COMPOZY_WEB_API_PROXY_TARGETfor Web QA and serialize config writes against one isolated home. - Register every long-lived process immediately under
<QA_OUTPUT_PATH>/qa/pids/. - Require downstream QA to run the manifest's strict
AUDIT_COMMANDbefore a behavior-first verdict.
Done when: downstream skills consume the canonical manifest, durable findings land under docs/qa/, scratch evidence stays in the lab, and every owned process is registered.
Step 4: Preserve Continuation State
- Report the manifest path, lab root,
COMPOZY_HOME, base URL, dated run-report path, and reuse status. - For a continuing loop, append the exact machine-readable continuation block from the bootstrap contract.
Done when: the next continuation can identify the same lab from one exact manifest without discovery or guessing.
Step 5: Tear Down on Every Terminal Path
- On PASS, FAIL, BLOCKED, or abort, run the manifest's exact
TEARDOWN_COMMAND; only a confirmed continuation of the same loop may defer it. - The teardown must stop the daemon, tmux server, registered PIDs, lab-root processes, and lab-port listeners without touching unrelated labs.
- Cite
<QA_OUTPUT_PATH>/qa/teardown.jsonwith"clean": true. Survivors are a blocking failure. - Reserve
make qa-reapfor intentional stale-lab recovery across the machine, not normal cleanup of one active run.
Done when: the current lab's teardown evidence is clean and no process owned by this pass remains alive.
Error Handling
- Requested reuse fails health checks: use the fresh manifest emitted by the helper; do not revive stale state manually.
- Provider reports global config errors: compare the command's home policy with the manifest; isolated and operator-home lanes intentionally differ.
- Web reaches the wrong daemon: restart the Web process with the manifest-derived proxy target.
- Teardown reports survivors: inspect each
TEARDOWN_SURVIVOR, stop only processes owned by the current lab, and rerun the same targeted teardown.
Signals
- GitHub stars
- 3k
- Forks
- 177
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
eng-qa-bootstrap- Source
- github.com/compozy/compozy