Dawn already has slash commands for predictable product actions — type /help to see what is available, use /whats_new to ask what changed recently, or /link in a private channel to connect a chat identity to your Dawn account. Those commands are useful because they are direct: they do not ask the model to interpret a broad request, they perform a known product action.

But a lot of Dawn work does not fit that shape. Teams repeat the same long prompts over and over: review this PR like a production code review, turn this ticket into an implementation plan, draft release notes from merged work, create a prototype that matches this project instead of a generic mockup. Those are not hardcoded product actions — they are reusable task patterns that the team carries in their heads and re-types every time.

Prompt Commands are for that pattern. A workspace can turn a repeatable Dawn workflow into a slash command with stored instructions behind it. The user types the command, adds a short brief, and Dawn runs the normal agent conversation with the command instructions already attached.

From Prompt Boilerplate to a Command

Without Prompt Commands, users carry a lot of prompt boilerplate in their heads. If someone wants a useful PR review, they need to say more than “review this” — they need to tell Dawn to focus on correctness, regressions, missing tests, security issues, API mismatches, rollout risk, and concrete file references. If someone wants a ticket plan, they need to ask Dawn to inspect the ticket, linked docs, recent PRs, relevant code, tests, and open questions. That repeated framing is exactly what belongs in a Prompt Command.

Instead of writing the long version every time, the user can type:

/pr-review https://github.com/example/app/pull/248

Or:

/ticket-plan ADO-1842

Or:

/prototype redesign the billing settings page using the existing admin style

Everything after the command name is treated as the concrete brief for that run. The durable instructions live in the command body, so the team does not have to remember the full prompt shape every time.

Commands Use the Same Dawn Context

A Prompt Command runs through the normal Dawn conversation path. The selected agent still decides which skills are assigned, which connected sources are available, what workspace memory it can use, and which tools are allowed. The command shapes the task; it does not widen the agent’s authority.

That matters because it means commands can build directly on the workspace context that is already in place. If a workspace has connected GitHub, Jira, Azure DevOps, Figma, Framer, Notion, Confluence, Drive, or OneDrive sources, a command can tell Dawn how to use that context for a specific kind of work. A PR review command can ask Dawn to inspect the diff and related code. A project brief command can ask Dawn to look across tickets, docs, PRs, memory, and design files. A prototype command can ask Dawn to use project terminology, visual patterns, and existing requirements before creating an HTML artifact. The command provides the workflow; the workspace still controls the context.

Global Commands Give Teams a Starting Point

Dawn now ships with a global command pack covering the work teams repeatedly ask it to do — PR summaries, PR descriptions, PR reviews, test plans, release notes, ticket summaries, ticket triage, ticket planning, project briefs, and HTML prototypes. These are ready to use as seeded defaults, so teams get a useful starting point without needing to author a command library on day one.

For example, /prototype is built for creating or revising standalone HTML artifacts from a short brief. It tells Dawn to use the current thread, workspace memory, connected sources, and assigned skills to ground the result in the actual project — different from asking for “a dashboard mockup” and hoping the model guesses the right product context. /pr-review is framed as a correctness review, not a general summary: it asks Dawn to look for real failure paths, cite files and lines when possible, avoid style-only comments, and add PR comments when the relevant tools are available.

The result is consistency. A team can teach Dawn how a task should be done once and then invoke it the same way every time.

Workspace Commands Are Editable

Global commands are read-only defaults. Workspaces can copy them into editable workspace commands when they want to customise behaviour, in the same shape Dawn already uses for skills — a global command gives the default, and a workspace command with the same slug overrides it for that workspace.

That is useful when the default is close but not quite specific enough. A team might copy /pr-review and add its own review rules. Another might customise /release-notes to match its customer-facing release format. A product team might copy /prototype and tell Dawn to follow its own design language, common layout patterns, and naming conventions.

Workspace commands can also be created from scratch. In Dawn Web, the Commands screen lets managers and owners define the command slug, name, description, brief hint, tags, and markdown body through the UI. Users author the command body as markdown while the structured command details stay in proper form fields, so authoring stays approachable — there is no frontmatter format to learn just to create a useful command.

Revisions Make Prompt Changes Safer

Prompt Commands are durable workspace assets, so they need history. Every save creates a revision; teams can inspect earlier versions, see how a command changed, and restore an older one when a prompt drifted in the wrong direction.

That matters because commands affect repeated work. A casual edit to a one-off prompt disappears after the conversation, but a command edit changes what everyone in the workspace gets the next time they invoke it. Revision history makes those changes visible and reversible.

Available Wherever Slash Commands Are Supported

Prompt Commands build on Dawn’s existing slash-command experience. When a user types /, supported Dawn clients show the available commands in the composer — hardcoded product commands such as /help and /whats_new still behave as product actions, and Prompt Commands appear alongside them as workspace-backed task presets.

The transcript keeps the literal slash invocation, so the thread still shows what the user typed. Behind the scenes, Dawn passes the command body and the raw brief into the run so the agent follows the stored workflow instead of trying to infer meaning from the command name alone. The command stays readable to people and explicit to the model.

Getting Started

Open Dawn Web and go to Commands. Start by browsing the global commands — if one already matches the work you want, use it directly from chat. If it is close but needs your team’s rules, copy it to the workspace and edit the workspace version.

Good first commands tend to be the ones your team already repeats manually:

  • a PR review format
  • a ticket triage checklist
  • a release note structure
  • a project brief template
  • an HTML prototype workflow

Once the command exists, invoke it with a short brief. Dawn keeps the long-form instructions in the command and uses the brief for the specific run. The convenience of slash commands stays, and the actual task framing moves into reusable, reviewable workspace content the whole team can build on. And when a conversation produces a better version of the command, Dawn can help update it directly from the thread.

The full reference and authoring guide are in the docs: