Good writing gives the reader a clear path through an idea. Components help when they have a specific job: a warning before a risky step, an optional explanation, or a question worth discussing. This sample shows the source first and the rendered result immediately afterward.

The examples describe an imaginary note-taking workflow. Adapt the words as well as the syntax. Begin with ordinary headings, paragraphs, lists, and links; add the components below when they make the explanation easier to use.

Emphasize a phrase, not a paragraph

Use bold for a central idea, italics for a qualification, and a highlight for a small detail that deserves a second look. The two highlight forms below have the same reading purpose.

markdown
Keep **one clear question** in view. Record *what you observed* before explaining it.
==A **specific** change== is more useful than :mark[a vague impression].

Keep one clear question in view. Record what you observed before explaining it.

A specific change is more useful than a vague impression.

Highlight markers stay on one line, directly beside their content. In code, ==literal text== remains literal.

Choose a callout by its meaning

These five callouts share the same Markdown container shape. Their labels tell the reader what kind of attention the information needs.

markdown
:::note[Context]
This notebook describes a small example, not a completed study.
:::
:::tip[Make the next step easy]
Finish a session with one question you can investigate tomorrow.
:::
:::important[Keep the original]
Preserve the source data before making a summary.
:::
:::warning[Check the destination]
A local link must point to published content before publication.
:::
:::caution[Review a destructive action]
Read the selected filenames before permanently removing anything.
:::

GitHub-style alerts are another convenient spelling for a short callout:

markdown
> [!TIP]
> Put the explanation next to the step that needs it.

Use callouts sparingly in a real article. Their meaning becomes easier to notice when most of the page remains ordinary prose.

Let optional detail fold away

A disclosure keeps a longer explanation available without making it a prerequisite for the next sentence. It works as a native expandable section even without JavaScript.

markdown
:::details[Why separate observations from explanations?]
An observation records what happened. An explanation proposes why.
- Observation: the example took three steps.
- Explanation: the shorter route may have reduced the work.
Keeping the two separate makes the proposal easier to test.
:::
Why separate observations from explanations?

An observation records what happened. An explanation proposes why.

  • Observation: the example took three steps.
  • Explanation: the shorter route may have reduced the work.

Keeping the two separate makes the proposal easier to test.

Present a procedure as steps

Use an ordered list inside steps. Each item should describe one action, with its purpose close by.

markdown
:::steps
1. **Ask.** Write a question that can be answered by an example.
2. **Try.** Change one thing and record the result.
3. **Reflect.** Explain what the result supports and what remains uncertain.
:::
  1. Ask. Write a question that can be answered by an example.
  2. Try. Change one thing and record the result.
  3. Reflect. Explain what the result supports and what remains uncertain.

A task list is useful for tracking preparation rather than explaining a sequence:

  • State the question.
  • Label illustrative data.
  • Replace the example with your own material.

Offer two useful views with tabs

Rich tabs contain ordinary Markdown, including lists, links, and math. The outside fence uses four colons because its panels use three. Keep each panel meaningful on its own; all panels remain available in the static fallback.

markdown
::::tabs
:::tab[Explanation]
Keep a session small enough to **finish and reflect on**.
:::
:::tab[Checklist]
- Choose one question.
- Record one example.
- Write one next step.
:::
::::

Explanation

Keep a session small enough to finish and reflect on.

Checklist

  • Choose one question.
  • Record one example.
  • Write one next step.

Try it: switch panels, then use the arrow keys while a tab has focus. Rich tabs are the right choice when the panel needs formatted text; a plain-text interactive tab widget is useful for shorter unformatted summaries.

Pair an authored question with an answer

Question and answer components are part of the article itself. They do not create a reader discussion thread.

markdown
:::question[Must every section use a component?]
Would this paragraph be clearer as plain prose?
:::
:::answer[Start with the sentence]
Usually, yes. Add a component only when its structure helps the reader do something.
:::

Must every section use a component?

Would this paragraph be clearer as plain prose?

Start with the sentence

Usually, yes. Add a component only when its structure helps the reader do something.

Keep small notation readable

Keyboard keys, abbreviations, subscripts, and superscripts have dedicated inline forms. Use semantic notation instead of changing font sizes by hand.

markdown
Press :kbd[Ctrl] + :kbd[F] to find a phrase. An :abbr[SVG]{title="Scalable Vector Graphics"}
illustration stays sharp when enlarged. Write H:sub[2]O or x:sup[2] for simple text notation.

Press Ctrl + F to find a phrase. An SVG illustration stays sharp when enlarged. Write H2O or x2 for simple text notation.

Use $...$ when the expression needs mathematical layout: .

Add a definition and a footnote

Definitions belong near a term's first use. A footnote holds a useful aside without interrupting the main argument.1

markdown
Observation
: A description of something noticed or recorded.
Model
: An explicit account used to explain a relationship or make a prediction.
A footnote keeps supporting detail nearby.[^sample-context]
[^sample-context]: This is an authored footnote, not a reader annotation.
Observation
A description of something noticed or recorded.
Model
An explicit account used to explain a relationship or make a prediction.

Invite a reader conversation

A discussion section can connect a particular question to Giscus. Give it a stable label and retain that label when revising the wording.

markdown
:::discussion[What makes a note useful later?]{#sample-useful-note comments="true"}
Which detail would you add so a future reader could repeat the example?
:::

What makes a note useful later?

Which detail would you add so a future reader could repeat the example?

Join this conversation
Open on GitHub

Open this section to connect to GitHub.

Once the article is published with discussions configured, readers can open its conversation. Private draft previews show the discussion's placement without posting anything to GitHub.

Readers can also use the article's right-edge annotation control to discuss an exact rendered line. Existing threads appear as badges and in the Annotations tabs of the outline and conversation panel. These reader-created annotations are separate from authored footnotes and Q&A.

Point to a useful next destination

A link card gives a destination a short description. It is still a normal link, so its target must exist.

markdown
::link-card[Explore the archive]{href="/archive/" description="Published posts and articles, arranged over time."}
Explore the archive

Published posts and articles, arranged over time.

When adapting this sample, begin with the paragraphs, then keep only the components that make those paragraphs easier to use.

Footnotes

  1. This is an authored footnote, not a reader annotation. On supported reader layouts, its marker also appears in the article's right margin. The linked endnote remains available on every layout. ↩