All guides › Skills and tools

Skill catalog: the qawalk skill, its references, and the tools we recommend next to it

What the qawalk skill makes an agent do, what each reference covers, and which third-party skills and tools fit alongside, each with its implications: what runs where, which data leaves the machine, when not to use it.

A skill is a set of rules an agent follows without being reminded. This is what the qawalk skill contains, what it implies, and what we put next to it.

The qawalk skill

The router SKILL.md states when to use it, what done means, what is allowed without asking (local and review environments, test data there, fixing scenario mechanics) and what needs a person (changing criteria, production, uploading). Details live in references:

• Acceptance (reference/acceptance.md): writing ACCEPTANCE.md and scenario.yml; one check per criterion; deterministic for countable things, semantic for judgement, manual for a reviewer; consent dialogs as the default first step. Implication: the plan is the source of truth, the agent never widens scope on its own.
• Execution (reference/execution.md): start, walk, capture, mail, the shared browser per environment and how agents, scripts and people share it. Implication: one Chrome profile per environment; a production run never shares cookies with local work.
• Evaluation (reference/evaluation.md): how deterministic results and the semantic evaluator combine, thresholds, reading needs_review, reporting without inventing. Implication: the evaluator sees a reduced outline, not the page; your key, your cost.
• Environments (reference/environments.md): what may be done where; production always read-only. Implication: the CLI blocks writes on production even if the agent tries.
• Collaboration (reference/collaboration.md): share, PR comment, feedback, inbox, mentions, verdicts, baselines, compare, replay, public runs, digest and Slack. Implication: the agent reads feedback before it continues.
• MCP (reference/mcp.md): reading runs, feedback, verdicts and the inbox as tools. Implication: read-only; publishing stays in the CLI.

Recommended alongside

• Playwright MCP (browser control for the agent): connect it to the CDP endpoint of qawalk browser start so agent-driven steps happen in the same profile as scripted ones. Implication: the agent sees page content locally; nothing goes to a third party.
• axe (accessibility rules): run it in a step script and store the result as an attachment until the a11y pack ships. Implication: local only.
• Lighthouse (performance): same pattern, one report per key page. Implication: noisy on shared runners; compare trends, not single numbers.
• Test-data seeding in your project: a prepare step for review and staging so scenarios create only what they need. Implication: keep it out of production, always.

Where the data goes

• Screenshots, HTML, e-mails: your machine and your QAwalk organization (Cloudflare storage, EU-law operator). Files are served from a separate origin under short-lived signed links.
• Semantic evaluation: a reduced text outline with e-mails and tokens masked to the evaluator you configured (default JEV by TypeSafe), only for semantic criteria.
• Nothing to Sinfin beyond what the service needs to show your canvas.

FAQ