A useful test plan is not a checklist. It is a read of the diff, the related areas of the system, the user-facing behaviour the change touches, and the things that have broken in this neighbourhood before. Most teams ship test plans that are a checklist anyway, because writing the read takes too long.
Dawn writes the read. The agent has the PR, the related tickets, the linked design, the relevant memory pages, and the connected source files. `/pr-test-plan` and `/ticket-test-plan` turn that into something a QA engineer can actually start from — and edit, instead of typing from scratch.
Pre-release pass, with help
Hand it to `/pr-test-plan`. The agent reads the diff and the related areas of the system, surfaces the user-facing behaviour to verify, calls out the regressions worth checking, and produces a plan that does not pretend the diff is smaller than it is.
Ask Dawn to read the customer report, the linked logs, the related code path, and the related tickets, and to draft a reproduction with steps and expected vs actual. You go from "I cannot reproduce this" to "I have three things to try".
Ask the agent for a release-pass plan: the merged tickets in the window, the user-facing changes, the historical hot spots, and the known-flaky areas. The pass starts from a real picture of what is in the build, not from last release's checklist.
Ask Dawn to walk back the recent changes that touched that area or its dependencies. The agent surfaces the candidates and the related tickets so you can narrow the bisect to a usable set.
From tickets to test plans
Coverage suggestions grounded in the actual diff or ticket — not a generic checklist.
Global command packThe "this area is fragile, run the manual case" knowledge that lives in QA heads gets written down once and applied to every plan after.
Memory pagesGitHub, GitLab, Azure DevOps, Jira, Linear — the agent reads the same source-of-truth the rest of the team does.
Connected sourcesA broad search across logs and tickets can run as a background task while you carry on with the rest of the test pass.
Background tasksReproduction recordings, generated test data, and HTML artifacts of test reports all live in one browseable surface, attached to the thread that produced them.
Files browserTry it
Test the PR
/pr-test-plan https://github.com/example/app/pull/249Test the ticket
/ticket-test-plan PROJ-1842Reproduce the bug
From this customer report, draft a reproduction with steps, expected, and actual — link the relevant code pathsPlan the pass
Build a release-pass plan for tomorrow's deploy: merged tickets in the window, user-facing changes, historical hot spotsWalk back the regression
Tell me what has changed in the past 30 days that could have caused a regression in the export PDF flowA QA-specific tip
A test checklist goes stale within a quarter. A memory page that says "this area depends on these three subsystems and has the following historical regressions" stays useful, because Dawn applies it to every new test plan automatically. Migrate the wisdom out of checklists and into memory.
Related reading
The product writeups behind the workflows on this page.
A ready-to-use library of PR review, ticket planning, release notes, and project brief commands.
How memory pages give the agent durable context the team would otherwise have to repeat.
Long-running work shows up as a task in the thread, ready to apply when it is done.
Browse, preview, and download the artifacts Dawn creates from one workspace surface.
Enter Dawn, connect your tools, and get your first grounded answer in minutes.
Live now. Built for real teams and real systems.