You will make a usable meeting note as you read this lesson. No previous Markdown experience is needed. Keep the example open in Writer so you can change a line and see what happens.
Create a file you can find again
Markdown is plain text with a few characters that describe its structure. A line beginning with a hash can become a heading; a line beginning with a dash can become a list item. The source remains readable without a special editor. A Markdown preview interprets those marks and shows the formatted document.
Open Writer and start a document, or open an existing .md file. Save your practice file in a folder you recognize, using a name such as project-meeting.md. You can also open an existing file through the application's file controls if your operating system has not associated Markdown files with VeloWrite. Installation notes belong on the download page.
For this exercise, use a copy of any important existing file. Writer and Converter are free. You do not need a publishing subscription to learn the syntax, edit the source, or make a converted copy. The current product is a desktop application; older instructions that ask you to start in a browser editor no longer apply.
Give the document a shape
Begin with a title and a few sections. A useful title says what the note covers. The sections tell you where to add the next paragraph. Use one hash for the document title, two for the main sections, and three for a subsection. Keep a space between the hashes and the words.
# Project meeting
Notes from the project review.
## Decisions
Record what was agreed and why.
## Actions
Record the next steps.
## Open questions
Keep unresolved questions here.Check the preview after entering the headings. If a heading appears as ordinary text, look for a missing space or an unclosed code fence earlier in the file. Choose heading levels for their place in the document. Using a smaller heading simply to change the font size makes the outline harder to follow.
Separate paragraphs and mark important words
Leave a blank line between paragraphs. Pressing Enter once inside a paragraph may still produce one continuous paragraph in the rendered document. A blank line makes the separation clear in both the source and the preview.
The team reviewed the draft schedule.
The release date remains an open question.
Use **bold** for an important term and *emphasis* for a short phrase.
Use `project-meeting.md` when naming a file.Use formatting where it helps someone read. If every sentence contains bold words, none of them stands out. Backticks are useful for filenames, commands, and short pieces of code because punctuation inside them stays literal.
A quotation begins with >. Keep enough context around it to explain whose words you are quoting and why they belong in the note. A quote should not take the place of recording the actual decision.
> We need to review the export before sharing it.
The team agreed to check a sample PDF first.Choose a list and add useful links
Use bullets for items whose order does not matter. Use numbers for a procedure that someone should follow in sequence. Keep each item short enough to scan. If an item grows into an explanation with several paragraphs, consider giving it a section.
Before the next review:
- Update the introduction.
- Check the source links.
- List the remaining questions.
To review the output:
1. Save the Markdown source.
2. Convert a copy.
3. Open the generated file.A link uses square brackets for its label and parentheses for its address. Describe the destination in the label. Someone skimming “conversion guide” can decide whether it is useful; “click here” gives them little to work with.
Read the [conversion guide](https://velowrite.app/convert-a-document).Images use a similar form with an exclamation mark at the start. The label becomes a text description of the image. Image paths deserve a separate check when a document moves between folders; the intermediate lesson works through that problem.
Turn the draft into a useful meeting note
The earlier meeting-note guide used a simple distinction worth keeping: discussion, decisions, and actions need different places. A discussion explains what people considered. A decision records what they agreed. An action names something that still has to happen.
# Project meeting
Date: YYYY-MM-DD
Participants: Add names
## Discussion
What needed attention, and what options were considered?
## Decisions
- Record the agreed choice and its reason.
## Actions
- [ ] Owner: action, due date.
## Open questions
- What still needs an answer?Replace the prompts with actual notes before sharing. An action such as “look into exports” is difficult to follow up. Name the output to inspect, who will inspect it, and when they should report back. Leave an unresolved question in the last section rather than writing it as an agreement.
You can reuse this structure by keeping a blank Markdown template in your project folder and making a copy for each meeting. That is a file-management habit; it does not depend on cloud sync or a shared editing service.
Save, reopen, and read the result
Read the preview once from beginning to end. Check that the title and sections appear in the right order. Follow an important link. Confirm that the numbered procedure still reads as a sequence and that quotes do not accidentally include the paragraph after them.
Save the file and reopen it from its folder. This small check establishes where your source lives and whether you can return to it tomorrow. If you make a delivery copy, keep the Markdown source too. An exported PDF is useful to read, but the source is the file you will normally revise.
Try one final exercise: add a decision, give its follow-up action an owner, and put a reference link beside the explanation. If another person can work out what happened and what comes next without asking you, the note is doing its job.
Continue with the intermediate guide to add tables, keep images portable, and review a longer document. For application controls rather than syntax, use Edit a first document.