Markdown Templates: 10 Ready-to-Use .md Files

These markdown templates are complete .md files you can copy, fill in, and save. The ten cover repository files (README, changelog, contributing guide), working documents (meeting notes, proposal, weekly report), records (blog post, ADR, resume), and GitHub issue and PR templates. Each one notes where to save it and which tools fill in the placeholders for you.

How to Use These Markdown Templates

Copy a block, paste it into the editor or your own app, and replace anything in angle brackets. Where a template uses {{date}} or {{title}}, that's a placeholder Obsidian or Hugo fills automatically; in a plain editor, type the value by hand. Every template here is plain CommonMark plus GFM task lists and tables, so it renders the same on GitHub, in Obsidian, and in our editor.

We kept every template short on purpose. A markdown template you can read in ten seconds gets used; a 200-line one gets ignored. If your team needs more sections, add them after the template has been in use for a month and you know which ones people skip.

README, CHANGELOG, and CONTRIBUTING Templates

1. README. Save as README.md in the repository root. The README Markdown guide covers badges, screenshots, and structure in depth, so this is the minimal version:

# <Project name>

<One sentence: what it does and who it is for.>

## Install

    npm install <package>

## Usage

    <one command or code sample>

## Contributing

See [CONTRIBUTING.md](CONTRIBUTING.md).

## License

<MIT | Apache-2.0>

2. CHANGELOG. Save as CHANGELOG.md. This follows the Keep a Changelog 1.1.0 format: an Unreleased section at the top, ISO dates, and six change types (Added, Changed, Deprecated, Removed, Fixed, Security).

# Changelog

## [Unreleased]

### Added
- <new feature>

## [1.1.0] - 2026-09-11

### Changed
- <changed behaviour>

### Fixed
- <bug fix>

[Unreleased]: https://github.com/<org>/<repo>/compare/v1.1.0...HEAD
[1.1.0]: https://github.com/<org>/<repo>/compare/v1.0.0...v1.1.0

3. CONTRIBUTING. Save as CONTRIBUTING.md in the root or .github/ folder, and GitHub links to it from the new-issue and new-PR pages.

# Contributing to <Project>

## Before you start
- Check open issues to avoid duplicate work.
- For large changes, open an issue first.

## Development setup
1. Fork and clone the repo.
2. Run `<install command>`.
3. Run `<test command>` and confirm it passes.

## Pull requests
- One change per PR.
- Add tests for new behaviour.
- Update CHANGELOG.md under Unreleased.

Meeting Notes, Proposal, and Weekly Report Templates

4. Meeting notes. Save in your notes folder as YYYY-MM-DD-<topic>.md. The task list at the end uses - [ ] syntax, which GitHub, Obsidian, and our editor render as checkboxes; see the Markdown checkbox guide for details.

# <Meeting title> - <YYYY-MM-DD>

**Attendees:** <names>
**Goal:** <one line>

## Agenda
1. <item>
2. <item>

## Notes
- <discussion point>

## Decisions
- <decision and who owns it>

## Action items
- [ ] <task> (@owner, due <date>)
- [ ] <task> (@owner, due <date>)

5. One-page proposal. Good for pitching a project internally. Keep it to one screen, and fill in the Risks section honestly; it is the part reviewers read first.

# Proposal: <title>

**Author:** <name> | **Date:** <YYYY-MM-DD> | **Status:** Draft

## Problem
<Two or three sentences on what hurts today.>

## Proposed solution
<What you want to build or change.>

## Scope
- In: <item>
- Out: <item>

## Cost and timeline
| Phase | Effort | Target |
|---|---|---|
| Design | <days> | <date> |
| Build | <days> | <date> |

## Risks
- <risk and mitigation>

6. Weekly report. Save as <YYYY>-W<week>.md. Three headings are enough; if it needs more, it's a document, not a report.

# Week <NN> report - <team or name>

## Done
- <shipped item>

## In progress
- <item> (<percent> done, blocked by <nothing | X>)

## Next week
- <planned item>

The meeting-notes template is loaded below with sample values. Edit it, then use the export button to download a PDF for anyone who wasn't in the room.

For a Word document instead, the Markdown to DOCX converter takes the same text.

Blog Post, ADR, and Resume Templates

7. Blog post with front matter. Static site generators read the YAML block at the top of the file. This one uses the keys Jekyll and Hugo both understand; the Markdown front matter guide explains the YAML rules and per-platform fields.

---
title: "<Post title>"
date: 2026-09-11
tags: [markdown, templates]
draft: true
---

<Opening paragraph that answers the reader's question.>

## <First section>

<Body.>

## <Second section>

<Body.>

8. Architecture decision record. Save as docs/adr/0001-<short-title>.md and number them in order. The five sections come from Michael Nygard's template, as collected in the architecture-decision-record repository.

# 1. <Decision title>

## Status
<Proposed | Accepted | Rejected | Deprecated | Superseded by 0002>

## Context
<The issue that motivates this decision.>

## Decision
<The change we are proposing or have made.>

## Consequences
<What becomes easier or harder because of this change.>

9. Resume. Save as resume.md, then export to PDF or DOCX for applications. Two columns and fancy layouts don't survive Markdown, so this template relies on headings and bold text only. Keep one bullet per result and put a number in each one; recruiters scan for numbers first.

# <Full name>

<City> | <email> | <linkedin or site>

## Summary
<Two sentences on what you do and what you're looking for.>

## Experience

**<Job title>, <Company>** (<start> to <end>)
- <Result with a number>
- <Result with a number>

## Skills
<Skill>, <skill>, <skill>

## Education
**<Degree>, <School>** (<year>)

GitHub Issue and Pull Request Templates

10. Issue and PR templates. GitHub reads issue templates from the .github/ISSUE_TEMPLATE/ folder on the default branch, and Markdown templates there need name and about keys in their front matter to count toward the community profile. title, labels, and assignees are optional. The GitHub templates documentation has the full rules.

---
name: Bug report
about: Report something that is broken
title: "[Bug]: "
labels: bug
assignees: ""
---

## What happened
<Describe the bug.>

## Steps to reproduce
1. <step>
2. <step>

## Expected behaviour
<What should have happened.>

## Environment
- Version: <x.y.z>
- OS: <Windows 11 | macOS 15 | Ubuntu 24.04>

The pull request template is a single file named PULL_REQUEST_TEMPLATE.md in the root, the docs/ folder, or .github/. It has no front matter; the body simply prefills the PR description.

## Summary
<One or two sentences.>

## Changes
- <change>

## Checklist
- [ ] Tests added or updated
- [ ] CHANGELOG.md updated
- [ ] Docs updated

Where Do Markdown Templates Live in Each Tool?

Templates are only useful if the tool can find them. Here's where each one looks:

Tool	Location	Placeholders
GitHub	.github/ISSUE_TEMPLATE/*.md, PULL_REQUEST_TEMPLATE.md	None; front matter sets title, labels, assignees
Obsidian (core Templates plugin)	Any folder you set under Settings, Core plugins, Templates	{{title}}, {{date}}, {{time}}, with optional format strings such as {{date:YYYY-MM-DD}}
Hugo	archetypes/default.md or archetypes/<type>.md	Go template variables such as .Date and .File.ContentBaseName, filled by hugo new content
VS Code	User snippets for the markdown language, or a .code-snippets file in the project	$1, $2 tabstops, $0 final cursor, variables like CURRENT_YEAR and TM_FILENAME_BASE
Jekyll	No template folder; copy a file into _posts/	Front matter keys layout, date, categories, tags

Obsidian's Templates plugin inserts a template into the active note and swaps {{date}} for today's date in YYYY-MM-DD format by default. Hugo's archetypes run when you type hugo new content posts/my-post.md, producing a file with title, date, and draft: true already set. VS Code's user snippets are the odd one out: you store the template as a JSON array of lines and trigger it by typing a prefix.

One limitation: Notion, Confluence, and Google Docs have their own template systems and do not read .md files. Paste the rendered output from the editor into those apps instead.

A related question is the markdown template for documentation pages. Docs generators such as MkDocs and Docusaurus don't ship a template folder either; the convention is a docs/_template.md file that contributors copy, with Overview, Install, Usage, Configuration, and Troubleshooting headings. Add it to CONTRIBUTING.md so new writers find it. The Markdown table of contents guide shows how to add a TOC block to longer pages built from that template.

Common Markdown Template Mistakes

Leaving placeholders in the final file. A <Project name> heading in a published README looks careless. Search for < before you commit, or use the editor's preview, where the angle brackets stand out.

Front matter that isn't first. Jekyll requires the YAML block to be the very first thing in the file. A blank line or a comment above --- turns it into a horizontal rule and plain text.

Tables in a resume template. Tables render well on screen but break in many PDF and DOCX exporters when cells wrap. The Markdown table guide explains the limits; for a resume, bold text and bullets are safer.

Markdown Templates FAQ

Ten files cover most of what a developer or writer creates in a week. The README and meeting notes get used daily, so start there. Add the other markdown templates as you need them, and keep each one short enough to read at a glance. Paste any of them into the editor, replace the placeholders, and export to PDF with the Markdown to PDF tool when someone needs a copy they can't edit.