Skip to content
Toado Docs

Comments & mentions

Comments are how a ticket records its history. Every action that needs context (a fix proposal, a decision, a clarification) belongs in a comment.

Posting a comment

On the ticket detail page, the comment box sits at the bottom of the side panel. Type, then Cmd + Enter to submit.

Markdown is supported:

  • Headings (#, ##, ###)
  • Lists (- and 1. )
  • Links ([text](url))
  • Bold (**text**), italic (*text*)
  • Inline code (`code`) and fenced code blocks (```lang)
  • Blockquotes (> )

Images can be drag-and-dropped into the comment box. They upload to Toado and are inserted as markdown image references.

Mentions

Type @ to open a mention picker. Pick a teammate from your company. The mention renders as a clickable chip in the saved comment.

Mentioned users get notified per their notification preferences (see Notifications). The default is in-app plus email digest.

You can mention anyone in the company who has access to the ticket’s project. You cannot mention people outside the company.

Comments from MCP clients

Comments posted via the MCP add_comment tool look slightly different:

  • The author label is <user-name> (<token-label>), e.g. “Jason (claude-code on macbook)”.
  • A violet MCP badge sits next to the author.
  • The comment background has a faint violet tint.

This makes audit trails self-explanatory: a reviewer can tell at a glance which comments came from a human and which from an AI agent (and which agent token, when one user has multiple).

Editing and deleting

You can edit your own comments within 5 minutes of posting (typo window). After 5 minutes, comments are immutable to preserve the audit trail.

You can delete your own comment at any time. Deleted comments leave a placeholder “deleted by <author> at <time>” so the timeline is not confusing.

You cannot edit or delete other people’s comments. Owners can delete any comment in their company; this is intentional and rare.

Threading

Comments are not threaded in v1. They are a flat chronological list. If you need to reference a previous comment, link to it (every comment has a deep-link icon on hover).

Reactions

Each comment supports a small reaction set: thumbs up, thumbs down, eyes, party popper, heart. Reactions are lightweight signals (e.g. an agent posts a fix and teammates thumbs-up to acknowledge).

Comment patterns that work

  • Action receipts. When you (or an agent) do something (fix code, change column, assign), post a comment explaining what and why. The action by itself is not enough context for a reviewer six weeks later.
  • Clarifying questions. When the description is ambiguous, comment with the question and leave the ticket in place. Do not silently fix the wrong thing.
  • Triage decisions. “Out of scope, this is third-party code.” “Duplicate of t-xyz.” Helpful even when nobody asked.
  • Verification logs. When you re-run a fix to confirm it holds, comment with the result.

Where to next