All guides › By use case

Accepting a task with an AI agent, in the pull request

The agent walks the acceptance plan on local or review, QAwalk captures every screen and e-mail, checks the criteria and puts one canvas link into the PR. The reviewer accepts or returns it there.

The agent finished the task at 2:14 and the PR says "done". Nobody has opened the branch. QAwalk turns "done" into a canvas of what was actually built, with the criteria from the task checked one by one, and puts the link where the review happens.

The problem

Acceptance is slow because the person who could accept has to build the branch, click through it in two languages and remember what the task asked for. So we accept from the diff and screenshots in chat, and the second locale exists, probably.

What changes with QAwalk

The task gets an ACCEPTANCE.md: what each screen must achieve, in plain sentences. The agent turns it into a scenario, walks it, and the result is one canvas with every screen, the criteria with evidence, and a place to accept or return. The reviewer looks at the canvas, not at the diff.

How it works

1. Write the plan

   ACCEPTANCE.md next to the task, one line per screen and criterion. The skill's acceptance reference explains the shape; countable things get deterministic checks, judgement gets a question.

2. Walk on local or review

   qawalk start --scenario … --env local, then qawalk walk for scripted steps and qawalk capture for the ones the agent drives itself. Every step is captured the same way: desktop and mobile, HTML, console, e-mails.

3. Evaluate and share

   qawalk evaluate checks the criteria, qawalk share --pr uploads the run and keeps one comment per scenario on the pull request.

4. Accept or return

   the reviewer opens the canvas, approves steps or returns the run with a note. The agent reads the notes with qawalk feedback and fixes them in the next run; the PR comment updates itself.

Skills and prompts

Install the qawalk skill (npx qawalk init --agent claude) and ask in plain words. The skill knows when to walk, when to ask before touching production, and how to report.

Turn the description of TASK-123 into ACCEPTANCE.md and a scenario, then walk it on local and share the result into the PR.

Expected outcome: ACCEPTANCE.md and qa/scenario.yml in the task folder, a shared run, a PR comment with the summary line and the canvas link.

Read the feedback on the latest run of TASK-123, fix what was returned, and run it again.

Expected outcome: the agent lists the returned steps with the reviewer's notes, changes the code, shares a new run; the same PR comment now points at it.

What you get

• One canvas per run: screens, locales, criteria with evidence, who approved what.
• A PR comment that stays current instead of a thread of screenshots.
• Verdicts and notes readable by the agent, so the loop closes without a meeting.

FAQ

What it looks like

A real run of QAwalk on its own public pages, refreshed daily. This is the canvas your team gets.

More guides