Basic Syntax / Headings
Headings
Headings give a document its shape. In a README or onboarding guide, they should define the reading path before they define the look.
Syntax
Add number signs in front of a line. More signs mean a deeper level in the document outline:
# Project Overview
## Quick Start
### Requirements
### Local Development
## Deployment
### GitHub Pages
#### Troubleshooting
##### Cache Refresh
###### Temporary Workaround Preview
Project Overview
Quick Start
Requirements
Local Development
Cache Refresh
Temporary Workaround
Writing Tips
- Most pages should have a single H1 that tells readers what this page is for.
- Do not skip levels just for visual effect. TOCs, sidebars, and accessibility all depend on a stable hierarchy.
- Use headings that promise useful content, such as “Deployment” or “Known Issues,” instead of vague labels like “More.”
- If a section does not fit your current outline, rethink the structure before adding more emphasis to body text.
Alternative Syntax
You can also create H1 and H2 headings with underlines. It still appears in older Markdown files, but # syntax is clearer for long-lived docs.
Release Notes
Known Issues
Release Notes
===
Known Issues
--- For maintained docs, # headings are usually the better default because they are easier to scan and easier to turn into anchors.
Comments
Comments are currently unavailable.
Enable GitHub Discussions for this repository and complete the giscus configuration to turn comments on.