July 2023:
We've made several improvements in response to your feedback:
- The output will now render as a div instead of a blockquote.
- The text color has been changed to primary from the previous muted version.
- We've tightened our parsing rules to prevent conflicts with other Markdown or HTML on the allowed list.
Consequently, a line break following the title is now required.
- We've introduced a new alert type
IMPORTANT
.
- A new syntax,
[!NOTE]
, has been added, which will gradually replace the old one. However, the old syntax will continue to work for some time.
Note:
In Markdown files, a hard line break can be achieved with two spaces [!NOTE]
, a backslash [!NOTE]\
or html [!NOTE]<br>
An example of all three types (with two spaces after the ]
):
[!NOTE]
Highlights information that users should take into account, even when skimming.
[!IMPORTANT]
Crucial information necessary for users to succeed.
[!WARNING]
Critical content demanding immediate user attention due to potential risks.
Here is how they are displayed:

May 2022, original answer:
While not exactly an admonition, this is supported (beta tested) since May 2022, as reported by Diego Haz and described in discussion 16925
To better highlight and separate certain information from the rest in your documentation on GitHub, we now render a special and accessible note or warning blockquote in Markdown documents.
We are using the existing syntax for blockquote and bold text.
The first line must be exactly as shown below.
The first letter is case sensitive. The second line can contain your content.
This input:
> **Note**
> This is a note
> **Warning**
> This is a warning
Becomes:

Warning: the syntax might still evolve and is debated in the discussion. For instance, Brenton M. Wiernik comments:
In addition to syntax issues and semantic web problems raised by others, I am also concerned about this introducing a major incompatibility between GitHub-Flavored Markdown and pandoc markdown or CommonMark.
A large number of R developers write READMEs and other documentation in RMarkdown, which is generally processed using pandoc.
This change would mean that users would be unable to get consistent rendering with the same syntax when their package documentation is displayed on GitHub vs elsewhere.
Overloading the blockquote in this way creates an opaque difference in the meaning of syntax across markdown flavors that is very difficult to write around for developers.