Dawn’s global command pack now includes the everyday commands teams keep rebuilding by hand: PR reviews and descriptions, focused review postures for security, APIs, databases, frontend, performance, and observability, ticket summaries and plans, release notes, and project briefs. They are available from the slash command menu the moment a workspace is created, and any one of them can be copied into the workspace and tuned without rewriting it from scratch.
The point of the pack is not to replace prompt-writing. It is to make the common shapes of work — the ones a senior engineer or product manager already knows how to ask for — show up the same way for everyone, on every workspace, without depending on which teammate happens to remember the best wording.
Why a Pack and Not Better Prompts
Good Dawn prompts tend to become habits. Someone writes a useful PR review prompt, a teammate copies it, a third version adds security checks, and eventually the team has a small, scattered library of prompts living in chat history. That works for a while. It does not survive the next hire, the next workspace, or the moment the original author moves on.
The honest fix is to move the reusable wording out of chat history and into the product. Prompt commands gave teams a place to keep their own; the global pack gives every workspace a serviceable starting point on day one. None of the global commands aim to be the perfect review for every team — that is exactly the kind of opinion that should be tuned per workspace. They aim to be a credible default that gets the work done and gives teams something to react against.
The result is that a brand-new workspace can already ask for a focused PR security review, a ticket plan grounded in code, or a release note draft, without anyone having to write the prompt first. And once a team has an opinion about how those should look, the path to making them their own is one click away.
Pull Request Commands
The pull request workflow is where reusable commands earn their keep most quickly. A useful review is not “look at this PR” — it has a point of view, a posture, and a sense of what to weigh. The new pack covers the common shapes.
For everyday review work, /pr-summary produces a short read of what changed, why it matters, where the risk sits, and which files were touched. /pr-description drafts a real PR description with summary, testing, risk, and rollout sections, instead of the one-line title most authors leave behind on a busy day. /pr-review is the broad code review, the kind a teammate would do if they had time and the right context. /pr-test-plan turns the diff into practical coverage suggestions so the change does not ship with an empty test box, and /pr-risk-brief is for the moment before merging when someone asks “what could go wrong with this one?”
The focused review commands kick in when a broad review is not enough. /pr-security-review narrows the lens to authentication, tenancy, permissions, and secrets — the places where a generic review tends to skim. /pr-api-review keeps the review pointed at DTOs, contracts, versioning, and frontend/backend alignment, which is the failure mode most likely to slip past a single reviewer. /pr-db-review looks at schema migrations, indexes, query patterns, and data integrity. /pr-frontend-review weighs UI behaviour, accessibility, and the pieces that look obvious in a screenshot but break in practice. /pr-performance-review and /pr-observability-review round out the set: one for the change that should be measured before merging, the other for the change that should be visible after.
The point of having focused reviews as separate commands is that a focused review usually finds different issues than a broad one. Asking for a security review and then a database review is not redundant; it is two passes with different priorities. The goal is not to make every PR run every command. The goal is to make the right kind of review easy to ask for when the change deserves it.
Ticket Commands for Planning Real Work
Tickets and work items rarely arrive with everything they need. The description is short, the comments contain a half-resolved discussion, the linked design is one revision behind, and the customer report is buried in a Slack thread someone forgot to link. Turning that into an actionable plan takes time.
The new ticket commands give Dawn a consistent way to help. /ticket-summary is the right command when someone needs the ask, the current state, the blockers, the linked PRs, and the useful surrounding context in one place — the kind of summary you would want at the top of a planning meeting. /ticket-triage is for the moment when the next step is unclear: it asks Dawn to call out priority, severity, owner, missing information, and the concrete follow-up action, instead of leaving everyone to argue about it. /ticket-plan takes the next step further, turning the ticket into an implementation plan that is grounded in code, docs, and connected sources. /ticket-test-plan is the QA-shaped version, focused on the targeted coverage a change needs before it ships.
These commands are designed for the connected sources teams already use — Jira, Linear, Azure DevOps, GitHub, GitLab, Trello — and they only have access to whatever sources the selected agent does. The command does not invent visibility it does not have. What it does is give the agent the right shape of task once those sources are connected, so the same ticket reads the same way regardless of which teammate is asking.
Release Notes and Project Briefs
Not every command is tied to a single PR or ticket. Two commands in the new pack are aimed at broader team communication, where the content is a synthesis of many smaller pieces of work.
/release-notes turns merged PRs and completed tickets into something a customer, manager, or support teammate can actually read. The value is not that Dawn can list changes — anyone can copy a changelog. The value is the translation from engineering activity into user-facing language: what the team can now do, what improved, what changed in behaviour, and what no longer requires a workaround. A useful release note does not mirror the commit history. It explains the part the reader will care about and skips the part they will not.
/project-brief is the inverse shape: a current-state summary across a workspace, useful before a planning meeting, a handoff, or a status update. The command pulls together context from tickets, docs, PRs, design files, and memory pages so the team starts from a shared picture instead of another round of “where are we with this?”. It will not invent progress that is not in the workspace, which is the right behaviour — a project brief that quietly papers over a stalled area is worse than one that makes the gap obvious.
Commands Stay Editable
Every command in the pack is a starting point, not the final word. A workspace owner or manager can open a global command, copy it into their workspace, and adjust it for the team’s expectations.
That step matters more than it sounds. One team may want PR reviews to weigh tenancy boundaries and data migration risk above everything else. Another may care most about frontend accessibility and analytics coverage. The global command gives both teams something usable today; the workspace copy lets each team make the review actually theirs by next week. The team’s review culture stops living in private prompt notes and starts living in the workspace where the rest of the work happens.
The command editor keeps structured fields — name, description, brief hint, tags — separate from the body, so authors are not learning a file format just to ship a useful workflow. The body is plain instructions for the agent, which is the part that should be easy to read and easy to change.
How a Run Looks in Practice
The brief for any command goes after the command name. Everything before it is the reusable framing the team does not retype.
/pr-review https://github.com/example/app/pull/248/pr-security-review https://github.com/example/app/pull/249 focus on the new auth middleware/ticket-plan ADO-1842/release-notes last week's merged PRs for the billing project, written for support and account teamsThe reusable instructions live inside the command. The brief in the chat is the run-specific part: which PR, which ticket, which time window, which audience. That separation is what keeps the wording consistent without making every run identical.
Where the Pack Helps Most
The pack is at its best when a team has work that repeats and an opinion about how that work should look. PR review culture, ticket triage, release communication, project status — those are exactly the areas where a credible default plus a workspace-specific tuning beats either pure ad-hoc prompting or a heavyweight templating system.
It is at its weakest when the work is unique. A one-off architectural review, a single migration brief, an incident retro that only happens once a year — those still want a hand-written prompt, possibly turned into a workspace command if it is going to happen again. The pack is not trying to cover every possible request. It is covering the ones that already get asked every week.
Getting Started
Type / in any Dawn chat composer to browse the pack. Pick the command closest to the work in front of you, hand it the brief, and read what comes back. If the result is close but not quite right for your team, copy the command into the workspace and tune the wording. If it is exactly right, leave it alone — the global version will keep working, and any future updates to the pack land automatically.
The expanded command pack is about making good prompting less dependent on memory. The common workflows are now one slash command away, and the workspace can still shape them into the way your team actually works.