For Training
A ready-to-run session for engineers and QA staff. Roughly 45 minutes with a live pull request.
Business view
Learning objectives
By the end, a participant can:
- Explain why the QA agent was split into four actions.
- Dispatch each action from the Actions tab.
- Edit an AI-generated review or plan so the next stage uses their version.
- Read the results — issues, labels, summary tally — correctly, including the
two places it misleads.
- Say which actions can write to their branch, and choose accordingly.
The one sentence to open with
The AI still does all the work; you now get to correct it twice before it commits to anything.
The mental model
Draw this on the board and leave it up:
review ──► 🔍 comment ──► [ YOU EDIT ] ──┐
│
plan ◄─────────────────────────────────── ┘
│
└──► 🧪 comment ──► [ YOU EDIT ] ──┐
│
test ◄─────────────────────────────────┘
│
└──► issues + summary ──► fix ──► updates the same issues
Two edit gates. They sit on the two reasoning steps (what does this change do? what should we try?) and not on the two execution steps (run it, repair it). That is the design principle: humans correct judgement, machines produce evidence.
Session plan
Part 1 — Why (5 min)
Ask the room: "Last time the QA agent misunderstood a change, what did you do about it?" The honest answer used to be "re-ran it and hoped", because the first artifact you could touch was the test plan — already two reasoning steps downstream of the code. The AI's understanding was never visible.
That is the gap this closes. review surfaces the understanding, and it is editable.
Part 2 — Dispatch review (10 min)
Have everyone open a real PR on a branch with a live sandbox.
- Actions tab → Sandbox QA → Run workflow.
- Select the branch — this is the branch that gets reviewed. Getting this
wrong is the single most common mistake; the workflow runs on the ref you pick, not on a PR you have open in another tab.
- Action:
review. Scope: leaveall— it only affectstest, and
GitHub shows the dropdown regardless (.github/workflows/sandbox-qa.yml:37-44).
- Run it. Watch the job log — agent progress streams live.
When the comment appears, read it together. Ask: is any of this wrong?
Part 3 — Edit and hand off (10 min)
This is the core exercise. Do it slowly.
- Click Edit on the 🔍 comment.
- Point out the invisible first line:
<!-- sandbox-qa-review -->. **Rule:
never delete this.** It is how the workflow finds the comment (.github/workflows/sandbox-qa.yml:77). Delete it and the next run posts a duplicate instead of updating yours.
- Have each participant insert a distinctive sentinel sentence — something like
"IMPORTANT: also consider the VAT-exempt invoice path."
- Save. Dispatch
plan. - When the plan comment appears, find the story that came from the sentinel.
That moment — seeing your own sentence turn into a test story — is the lesson. Mechanically, the workflow read the current comment body off the PR and handed it to the agent (.github/workflows/sandbox-qa.yml:76-82).
Part 4 — Edit the plan, then test (10 min)
- Edit the 🧪 plan comment. Delete all but two or three stories — this keeps the
exercise short and proves the point.
- Dispatch
test. - When it finishes, show the three outputs together:
- Issues — one per story, titled
[QA-n] <emoji> <title> - Labels —
ai-automatedandpr-<number> - Summary comment — the tally
Count the issues. It should match the number of stories they left in the plan.
Part 5 — Reading results honestly (10 min)
Two traps. Teach them explicitly; they are not obvious.
Trap 1: closed ≠ passed. Issues close on PASS, FIXED, and SKIPPED (.github/workflows/sandbox-qa.yml:176). A story the agent never attempted looks exactly like one that succeeded.
Trust the tally, not the issue list. 12 stories: 9 ✅ · 2 ❌ · 0 🔧 · 1 ⏭️ — the ⏭️ is the only place skips show.
Trap 2: green ≠ tested. If the agent's stories.json is unparsable, the workflow logs a warning and finishes green with zero stories (.github/workflows/sandbox-qa.yml:156). A green run that tested nothing.
Then show fix: it updates the same issues in place with a **Re-test:** comment (:179-182) rather than filing new ones — and it is one of the two actions that commits to the branch.
The rules to hand out
Print these. They cover ~90% of the mistakes people make.
- Pick the right branch in the dispatch form. The action runs on the ref
you select.
- Never delete the
<!-- sandbox-qa-… -->marker when editing. - Edit forward, not sideways. Re-running a stage overwrites that stage's
own comment with new AI output. Edit review → dispatch plan. Do not edit review → dispatch review.
- Use
test, notfull-auto, after editing.full-autoregenerates
everything and ignores your edits (.github/workflows/sandbox-qa.yml:61).
review,plan,testnever commit.fixandfull-autodo.- Close old issues before re-testing.
testdoes not deduplicate — two
runs means two full sets of issues.
- Read the tally, not the checkmark.
- Long runs block everyone. One runner slot, up to a 5-hour timeout. Cancel
wedged runs.
Common questions from the room
"Can I skip review and go straight to plan?" Yes. plan will build on whatever review comment exists, or generate its own understanding if there is none — the fetch step just writes no file when the comment is absent (.github/workflows/sandbox-qa.yml:80). You lose the first correction gate.
"What if my branch has no PR yet?" It runs. The workflow logs "no open PR — using stored state only" and keeps results in the run's artifacts (.github/workflows/sandbox-qa.yml:72, :115). Nothing gets posted, because there is nowhere to post it.
"Where do old versions of the comments go?" Nowhere on the PR — each stage owns one comment that is overwritten (.github/workflows/sandbox-qa.yml:114-122). Previous versions are in the workflow run artifacts, kept 14 days.
"My review is enormous — is all of it used?" Comments are capped at 60 000 characters (.github/workflows/sandbox-qa.yml:130). Beyond that it is truncated with a footer, and it is the truncated text that plan receives.
"How do I re-run just the failures?" Dispatch test with scope: failed-only.