Executes written QA flow specs against a running Composer app via the agent debug port.
npx skills add https://github.com/dxos/dxos --skill running-qa-flows
Please help me install this Agent Skill. Skill: running-qa-flows Source: https://github.com/dxos/dxos/tree/main/.agents/skills/running-qa-flows Command: npx skills add https://github.com/dxos/dxos --skill running-qa-flows
Manually verifying that a plugin change works end to end in the real Composer application is slow and error-prone, and unit tests cannot cover live UI behavior. This Skill executes a written flow QA-n test plan from a .mdl spec against a running Composer instance, establishing preconditions, driving each step through the agent debug port, and reporting a per-step pass/fail table.
given, before, test, and after stages from a flow block in a PLUGIN.mdl or APP.mdl file and runs them in order, with --stage support for partial runs.moon run composer-app:serve-qa, connects through the debug port session, and invokes operations through the capability invoker with exact key matching.QA-n.m with observed versus expected values.## QA flow to confirm documents are created, placed, opened, and edited correctly in the real app before merging.Run the QA-1 flow from the plugin's PLUGIN.mdl against a fresh dev server and report the per-step pass/fail table.
High-intent search queries and answers about installing and using this skill.
Start a QA server with `moon run composer-app:serve-qa`, which sets DX_DEBUG_PORT and publishes a session to temp/debug-port.json. Then read the flow block from the .mdl spec, verify its given preconditions, and invoke each step through the debug port session.
A flow is a written test plan in the `## QA` section of a PLUGIN.mdl or APP.mdl file, defined in the qa.mdl dialect. It contains given preconditions plus before, test, and after step lists, where each step has do, invoke, expect, and assert fields.
Use running-qa-flows when executing a written QA plan with defined steps and assertions end to end. Use composer-debug for ad-hoc probing of a live page, since it defaults to read-only inspection rather than executing a mutating plan.
A step can falsely pass when judged by its invocation return value instead of its effect, or when leftover artifacts from a previous run satisfy an existence-shaped assert. Always verify the flow's artifacts are absent first and judge steps by database or DOM state.
Yes, the `--stage=before|test|after` option runs a single stage. A partial run is normal: before stands a fixture up, after tears one down, and test re-tests against an existing fixture, with leftovers reported so the next full run's given check catches them.
Calling space.db.remove deletes the object but leaves an open plank pointing at it, and the user cannot close a plank whose object no longer exists. The after stage runs through operations like space.removeObjects, which unlinks from the collection and closes open surfaces.
lprior-repoDefine design-by-contract constraints and Martin Fowler test plans for Rust projects.
jaisonerickReproduce QA-reported failures with failing tests and apply minimal code fixes.
jfriisjCapture Docker/Compose logs and container state into output artifacts.
npc-liveAutomate Clawfirm desktop UI tests via browser-agent with snapshots, clicks, and verifications.